One-off charges and subscriptions
Take a single payment or run a recurring plan, with trials, upgrades, downgrades and correct proration when someone changes plan mid-cycle.
Payments
Take money from day one.
Revenue is the only validation that counts, and it is very hard to collect from a prototype. Payments are wired in while the application is being built, not bolted on when you find your first customer.
Payments look simple until you meet the parts that are not: failed charges, retries, refunds, partial refunds, disputes, proration when someone upgrades mid-month, and the reconciliation that finance will ask for. We wire the processor in properly, which means the money movement is correct and the accounting behind it is too. Card data never touches your application — it goes straight to the processor, which keeps PCI scope where it belongs.
Off until you need it. Turning it on is a toggle — not a project, not a rebuild. See how capability arrives as you grow.
Providers
What we connect to
Available means built and running in production today. On request means we will build it for your application — it is not pre-built, and we will not imply otherwise.
Available
- StripeCards, subscriptions, invoices, Checkout, Connect for marketplace splits
- Stripe BillingPlans, trials, proration, dunning
On request
- Stripe TaxAutomatic sales tax calculation and filing data
- PayPal
- AdyenWhere enterprise procurement requires it
- MonerisCanadian card acquiring
- Interac e-TransferCanadian bank-to-bank
- EFT / pre-authorised debitRecurring Canadian direct debit
- AvalaraMulti-jurisdiction tax compliance
- ChargebeeWhere billing logic outgrows the processor
What you get
The part that is not just an API key
Invoices that reconcile
Generate, send and track invoices, with the reference data your accounting system needs to match a payment to a customer without anyone doing it by hand.
Failures handled, not ignored
Declined cards retried on a sensible schedule, dunning emails sent, and access suspended only when it should be. Most churn from failed payments is avoidable.
Marketplace splits
If your product sits between two sides, take payment from one, hold it, and pay out to the other with your cut retained.
PCI scope kept off your application
Card details go directly from the browser to the processor. Your application never sees or stores them, which is what keeps your compliance burden small.
Refunds, disputes and the audit trail
Full and partial refunds, chargeback evidence, and a record of every money movement with who authorised it.
For example
What this looks like in practice
A subscription product
Sign-up takes a card, a trial converts automatically, failed renewals are retried and chased, and finance gets a monthly revenue figure that ties out.
A marketplace
The buyer pays, the money is held, the seller is paid out on a schedule, and your commission is deducted automatically with a record of each split.
Field service invoicing
A job is marked complete on a phone and the invoice goes out the same minute, with payment collected on a link rather than chased for thirty days.