Software as a service platform development
in Toronto

Every online service needs a front door. The design of that door shapes everything behind it. A service can ask a new user to create a username and password from scratch, or let that person arrive through an account already in use elsewhere - a work email, an existing company login, a general-purpose identity provider. The second path is usually called single sign-on, and the decision is bigger than it looks.

A password a person invents just for one service tends to be weak, reused, or forgotten within weeks. Support tickets pile up around resets. An identity provider removes that layer entirely. The service trusts a token issued by a system the user already logged into, checks it against a public key, and lets the session begin. No password sits on the service at all. That also closes off weak-credential attacks.

The protocol underneath most of this is OAuth, paired with OpenID Connect for actual identity claims, not permission alone. The two get confused constantly. OAuth was built to grant access to a resource - letting one app read a calendar, say - not to prove who someone is. Treating an OAuth token as proof of identity, without the identity layer on top, is a common mistake in early builds.

Account linking is the part teams underestimate. A returning user might sign in through a different provider than the one used the first time - a personal account today, a company directory next month after a job change. Without a clear rule for matching accounts by verified email, a person quietly ends up with two accounts and two histories. Support untangles it later.

Session handling changes too. A login through an external identity provider still needs its own session on the service side, with its own expiry, refresh logic, and response to a user deactivated upstream. If the identity provider revokes access, the service should not wait for a long-lived session to expire on its own schedule.

Enterprise buyers often ask for SAML, layered on top of whatever consumer-facing login already exists. That is a separate integration, not a variant of the same code path. Supporting it well usually means a distinct login flow keyed to a company domain, tested against more than one identity provider before any contract depends on it.

None of this removes the case for a plain email and password option. Some have no employer account to borrow. Some organizations restrict what their identity systems can share externally. A service built around a single login method eventually turns away a customer who was ready to pay.

Building login this way costs more up front than a single form. It pays back later: fewer support tickets, fewer abandoned signups, and one clean record of who has access.

Flat pricing is easy to explain. It is also easy to get wrong. One tier for everyone means light users subsidize heavy ones, and heavy users eventually look for a cheaper option elsewhere. Usage-based billing ties the price to something the service actually measures - calls made, storage held, active seats, minutes of processing - so cost tracks value more closely.

The hard part rarely shows up in a sales deck. It is deciding what counts as a unit in the first place. A single request sounds simple. Then a retry, a follow-up notification, and a background job all touch the same action, and someone has to decide whether that counts as one billable event or three.

Metering cannot wait until month end. It has to happen close to where the work is done, not stitched together afterward from logs. A counter that lives inside the same code path as the feature it measures stays accurate when that feature changes. A counter maintained separately drifts, usually downward, and nobody notices until a customer disputes an invoice.

Overage handling needs a decision before launch, not during a support escalation. Some hard-stop the customer at the limit. That protects margin and irritates anyone mid-task. Others let usage run past the limit and bill for it later, which keeps people working but risks a surprise invoice. A visible running total, shown in the product, avoids most of that argument.

Plan changes mid-cycle are where billing logic tends to break first. A customer upgrades on day twelve of a monthly cycle. The clock does not pause. Does the new limit apply right away, or only from the next cycle. Is the price difference reduced to match the days remaining, or rounded to the nearest week. Whatever the answer, it must be the same every time, not a judgment call by whoever answers the ticket.

Free tiers complicate metering further. A free user still consumes real infrastructure - storage, compute, support time - even while paying nothing. A service that treats free usage as costless in its own accounting discovers the true cost only once usage grows large enough to matter.

Dunning, the polite name for chasing a failed payment, deserves its own logic. A single retry is not enough. A card can fail because it expired, because a bank flagged the charge, or because a limit was reached that will reset in a day. Each case needs a different message and schedule, not one generic failure email.

None of this is exciting work. It never shows up on a homepage. It also decides whether a growing service keeps its margin, or quietly loses it, one unmetered feature at a time.

A signup form for an online service sold to a buyer in Ontario is a contract, not a formality. Provincial consumer protection law treats an internet agreement as a real contract. It places clear obligations on the business running the checkout screen, and not solely on the person filling it in.

Before the buyer agrees to anything, the law expects certain terms disclosed clearly and up front: what is being bought, the price, the length of any commitment, and how to cancel. That timing matters. It cannot wait for a confirmation email sent after the charge has already gone through.

The buyer needs a real chance to review the order before it is final. A summary screen shows the choice. It can be accepted, declined, or corrected. A wrong plan or a wrong billing cycle should be fixable at that point, not after the card is charged. A checkout that locks in a purchase the instant a card number is entered, with no review step, fails that test.

Once the agreement is made, the consumer is entitled to a copy of it. That copy has to match what was disclosed earlier, not a marketing summary. In practice this means a confirmation with the price, the commitment period and the cancellation method in plain language, kept somewhere it can be found again, not sent once and forgotten.

When required disclosure is missing, or the pre-agreement review step was skipped, provincial law gives the consumer a way out. There is a right to cancel that would not otherwise apply. That exposure is larger than most marketing teams expect. A checkout built without legal review can create cancellation rights nobody planned for, tied to a gap nobody noticed at launch.

Separately, national competition law limits how a subscription price can be shown. This applies no matter what the checkout screen discloses about the contract itself. The full price has to be shown up front. No exceptions. It cannot be assembled at the last step from a base price plus fees appearing once payment is nearly done.

This practice, often called drip pricing, is not limited to hidden charges. A price advertised without a mandatory fee, then followed by that fee at the final screen, falls under the same rule. This holds even if the fee appears in small print earlier in the flow. The test is simple: was the early price ever a price a buyer could actually pay.

For a business selling a subscription service online to buyers in Ontario, one fix satisfies both rules. The order of steps matters. Show one true price before checkout begins. Let the buyer see and confirm the order before paying. Send a plain copy of what was agreed right after. None of that is complicated to build. It is easy to skip under a deadline, exactly when it tends to go missing.