Many SaaS founders plan billing as a single task: "add Stripe." Then a customer upgrades mid-month, a card fails on renewal, and a buyer in Texas or Manchester asks for a tax invoice. This guide explains what a SaaS billing system has to do, which parts to buy, which parts you still have to build, and the tax and compliance questions US and UK founders tend to discover late.
It is general guidance, not tax, accounting or legal advice. Rules differ by state and country and change over time, so confirm your own position with a qualified adviser.
Quick answer
- Buy the billing engine. Recurring charges, proration, invoices, payment retries and card storage are solved problems. Building them yourself is rarely a good use of budget.
- Build the layer between billing and your product. Plan and feature access, usage metering, webhook handling and the in-app billing screens are specific to your product, and no provider does them for you.
- Decide early who the seller is. With a payment processor you are the merchant of record and own tax registration and filing. With a merchant of record provider, the provider sells to your customer and takes on those duties, in exchange for less control.
- Your pricing model sets the difficulty. Flat pricing is simple. Per seat adds proration. Usage based pricing adds a metering pipeline that must be accurate and auditable.
- Tax follows the customer, not your office. US states treat SaaS differently from each other, and the UK expects VAT on digital services sold to UK consumers even from overseas sellers.
Pricing models and what each one demands of the billing system
Billing providers support the common models out of the box. Stripe, for example, documents flat rate, per-seat, tiered and usage-based pricing. What differs is how much work lands on your side of the integration.
| Model | How the customer is charged | What the billing system must handle | Typical trouble spot |
|---|---|---|---|
| Flat rate | A fixed price per plan (for example Basic, Pro) | Plan catalog, renewals, plan changes | Old plans and prices that existing customers must keep |
| Per seat | Price multiplied by the number of users | Quantity changes during the period, proration, seat limits enforced in the app | Seat counts in your app and in the billing provider drifting apart |
| Tiered | Unit price changes with quantity or usage | Tier rules, clear invoice lines | Customers not understanding whether one rate applies to everything or only to units inside each tier |
| Usage based | Charge for measured consumption, often billed after the period | Event collection, aggregation, usage visibility for customers, credits and alerts | Lost, duplicated or late usage events, and disputed invoices |
Tiered pricing has two meanings. Either the whole quantity is charged at the rate of the tier reached (volume), or each band is charged at its own rate (graduated). The invoices differ, so state on your pricing page which one applies.
Usage based pricing is an engineering project. Your product has to record every billable event reliably and send it to the billing system. Stripe's documentation now recommends its Metronome platform for new usage-based integrations and notes that its older Billing Meters approach only reconciles usage at invoice time. That matters if you sell prepaid credits: the comparison page says that with the basic approach customers can exceed their balance during the cycle. If customers need a live usage figure or a hard spending cap, plan for that from the start.
The subscription lifecycle: where the real work is
Signing up a customer is the easy part. Most billing defects appear in the events that follow.
Trials
Decide whether a trial requires a card. A card-free trial lowers friction but means you must decide what happens when the trial ends with no payment method. Stripe's trial documentation lists three end behaviors: create an invoice (the subscription becomes past due if it cannot be paid), cancel, or pause. It also sends a "trial will end" event, three days before the end by default, which you can use to trigger a reminder email. Your application has to grant or remove access for each outcome.
Upgrades, downgrades and proration
Proration means charging or crediting a customer for part of a billing period after a change. Providers calculate it, but the defaults may surprise you. According to Stripe's proration guide:
- Prorations are calculated to the second by default.
- The default behavior creates proration items, but positive prorations are not billed immediately and negative prorations are not refunded automatically. You choose whether to invoice at once, wait for the next invoice, or disable proration.
- Usage-based charges are not prorated.
- You can preview the resulting invoice before applying a change, which lets you show the customer the exact amount first.
Decide the rules before development starts: does an upgrade charge today or at renewal, and does a downgrade apply now with a credit or at period end?
Failed payments and dunning
Dunning is the process of recovering a failed payment through retries and customer reminders. Cards expire, get replaced and hit limits, so some renewals fail for customers who never intended to leave. Stripe's Smart Retries documentation states a recommended default of 8 tries within 2 weeks and explains that some hard declines, such as a card reported lost or stolen, cannot be retried without a new payment method.
What the provider cannot decide for you is the access policy. When retries are exhausted, Stripe lets you cancel the subscription, mark it unpaid, leave it past due, or pause it. You decide whether a past-due customer keeps full access, gets read-only access, or is locked out, and for how long. A short grace period with clear in-app warnings is usually kinder to business customers than an abrupt lockout over an expired card.
Cancellations and refunds
Cancellation can be immediate or at the end of the paid period. Stripe's cancellation guide notes that cancellation through the API takes effect immediately by default, and that a credit owed after cancellation can sit on the customer's balance unless you issue a refund. Refund policy is yours to define.
A hosted portal removes a good deal of work. Stripe's customer portal lets customers update payment methods, change or cancel subscriptions, and download invoices. Check the documented limitations first: for subscriptions with multiple products or usage-based billing, customers can cancel in the portal but cannot update the subscription.
Build vs buy: the realistic options
Writing your own subscription engine on top of a raw payment API is possible, but it only pays off for unusual contracts that no provider can model. For most teams the real choice is how much of the selling relationship to hand over.
Payment processor vs merchant of record
A payment processor moves money from your customer to you. You are the seller, so you are the merchant of record: your name is on the transaction, and tax registration, tax filing, refunds and disputes are your responsibility, even where tools help. A merchant of record (MoR) provider is the legal seller to your customer. Paddle describes this model in its merchant of record explainer as a legal entity responsible for selling to the end customer and taking on liabilities such as sales tax, refunds and chargebacks, and its developer documentation says it calculates, collects and remits taxes on the seller's behalf.
| Question | Processor plus billing engine (for example Stripe Billing) | Merchant of record (for example Paddle, Stripe Managed Payments) |
|---|---|---|
| Who is the legal seller? | You | The provider |
| Who registers for and remits sales tax or VAT? | You, with tooling to calculate, monitor and help file | The provider |
| Subscription logic (proration, retries, invoices) | Provided | Provided |
| Control over checkout and payment flows | High | More limited |
| Best suited to | Teams that want control and can manage tax compliance | Small teams selling to many countries from day one |
Some details worth knowing:
- Tax tools do not move liability. Stripe's description of Stripe Tax is explicit about the split: you register, Stripe Tax calculates and collects, and you file and remit, optionally through Stripe or its filing partners. It also monitors where you may have obligations.
- Stripe has its own MoR product. Managed Payments makes Stripe the merchant of record for digital products including SaaS, handling indirect tax in more than 80 countries according to its documentation. It works with Checkout and Payment Links only and does not support Connect platforms, so check eligibility before planning around it.
- An MoR still needs integration. Paddle's documentation lists proration, trials, pauses, upgrades, invoicing and credit notes in its billing engine, but you still connect its events to access control in your product.
Fees differ between these options and change over time, so compare the providers' current pricing pages against your expected volume and countries.
What you build in every case
- Entitlements: the mapping from plan to features, limits and seats, checked by your application on every relevant request.
- Webhook handling: Stripe states that a subscription integration requires a webhook destination because most subscription activity happens asynchronously.
- Usage metering, if you charge by usage.
- In-app billing screens and admin tools for support staff: credits, extensions, manual plan changes, and an audit trail of who changed what.
What US and UK founders overlook
US sales tax on SaaS varies by state
There is no single US rule for SaaS. In South Dakota v. Wayfair (decided June 21, 2018), the Supreme Court overruled the physical presence rule, which allows states to require out-of-state sellers to collect sales tax once they pass an economic threshold. Those thresholds differ: the Streamlined Sales Tax Governing Board's remote seller state guidance shows that some states use a sales figure, some a transaction count, and some a combination.
Whether SaaS is taxable at all also depends on the state. Two examples from state tax authorities: the Texas Comptroller treats software as a service as a taxable data processing service, with 20 percent of the charge exempt, and New York's tax department states that a license to remotely access prewritten software sold to a purchaser in New York is subject to sales tax. Other states take different positions, and a non-US company selling into the US is not automatically outside these rules.
UK VAT on digital services
For UK-established businesses, VAT registration becomes compulsory when taxable turnover passes GBP 90,000 over the last 12 months. That threshold does not protect overseas sellers: the same GOV.UK page says a business based outside the UK must register if it supplies any goods or services to the UK, with no turnover threshold.
For sales to private consumers, HMRC's guidance on digital services says the place of supply is where the consumer usually lives, and that a business based outside the UK whose supplies are liable to UK VAT needs to register for UK VAT. Electronically supplied services in that guidance include software and web hosting, so consumer-facing SaaS will usually fall within it. Sales to UK VAT-registered businesses work differently: under the place of supply rules in VAT Notice 741A, the UK business customer generally accounts for the VAT itself through the reverse charge. Your billing system therefore needs to capture whether the buyer is a business, its VAT number, and evidence of location.
Card data and PCI DSS scope
PCI DSS applies to entities that store, process or transmit cardholder data. Using a provider reduces your obligations but does not remove them. Stripe's integration security guide calls PCI compliance a shared responsibility and says a business accepting payments must still attest to compliance annually. The practical rule: collect card details only through the provider's hosted checkout or hosted fields so that card numbers never touch your servers. Stripe's PCI guide associates those integrations with the lightest self-assessment questionnaire and direct handling of card data through the API with the heaviest. Never log, email or store full card numbers.
Strong customer authentication for UK payments
The FCA explains that strong customer authentication (SCA) rules have applied since 14 September 2019 to how payment providers verify that a person is permitted to make a payment. For card payments this is normally done through 3D Secure, where the customer's bank asks them to approve the payment.
Subscriptions are affected in two places. The first payment, made while the customer is present, may need authentication. Later renewals happen without the customer present; Stripe's SCA guide explains that a properly set up saved card lets these be treated as merchant-initiated transactions, but that exemptions are not guaranteed and a bank can still ask for authentication. Your product needs a path for that case: an email and an in-app prompt that bring the customer back to approve the payment. Teams used to US-only payments often skip this.
Invoices and revenue reporting
Business customers expect proper invoices. In the UK, VAT invoices must include your VAT number and show the VAT separately. Corrections should be made with credit notes, not by editing or deleting issued invoices.
Cash collected is also not the same as revenue. Under IFRS 15, issued together with the equivalent US standard (FASB Topic 606), revenue is recognized as the promised service is transferred to the customer. An annual plan paid upfront is therefore generally spread over the year instead of being counted in full on day one. Providers offer tooling for this, such as Stripe Revenue Recognition, but your accountant should decide the treatment.
For technical readers
- Treat the provider as the source of truth for billing state. Keep a local copy of status, plan and period end for access checks, update it from webhooks, and reconcile on a schedule.
- Verify webhook signatures and make handlers idempotent. Events can arrive more than once or out of order.
- Do not grant access from the checkout redirect alone. Confirm the subscription status first, and handle every status (incomplete, past due, unpaid, paused), not only active and canceled.
- Keep your own raw usage log so usage invoices can be explained and recomputed.
- Reference prices through configuration, not code, and test trial end, renewal and retry exhaustion in the provider's sandbox.
Frequently asked questions
Should a SaaS startup build its own billing system?
Almost never the core engine. Use a billing provider for recurring charges, proration, invoices and retries, and build only what is specific to your product: feature access, usage metering, webhook handling and billing screens.
What is the difference between a payment processor and a merchant of record?
A payment processor moves money while you remain the legal seller, responsible for tax registration, filing, refunds and disputes. A merchant of record is the legal seller to your customer and takes on those responsibilities, typically with less control over checkout and payment flows.
Do I have to charge sales tax on SaaS in the United States?
It depends on the state and on how much you sell there. Some states, such as Texas and New York, tax SaaS or remotely accessed software, and others do not. Since the Wayfair decision, a state can require collection from sellers with no physical presence once its threshold is passed.
Does a US company selling SaaS to UK customers need to charge VAT?
Often yes for consumer sales. GOV.UK guidance says digital services sold to UK consumers are taxed where the consumer lives, and businesses based outside the UK have no registration threshold. Sales to UK VAT-registered businesses are generally handled by the customer through the reverse charge. Confirm your position with an adviser.
Does using Stripe or Paddle make my SaaS PCI compliant?
It reduces your scope considerably if card details are entered only in the provider's hosted checkout or hosted fields. It does not remove your obligations: with a processor you still confirm compliance each year and must keep card data out of your servers, logs and support tools.
Conclusion and next step
Good SaaS billing comes from a few early decisions: a pricing model your team can actually meter, written rules for upgrades, failed payments and refunds, a clear choice between being the merchant of record or using one, and an early conversation with a tax adviser about the states and countries you sell into.
A useful next step is a one-page billing specification covering plans, lifecycle rules, target markets and preferred provider. If you plan to hand the build to an external team, our guide on how to outsource software development from the US or UK covers how to evaluate one. Entrant Technologies builds web applications and custom software, including Laravel-based SaaS products, and you can request a quote if you want a billing integration scoped.
