Money in, and a paper trail that survives an audit.
Checkout, subscriptions, invoicing and payouts, built so that the ledger and the bank agree at the end of the month without anybody reconciling them by hand.
- Idempotent
- no double charge on retry
- SCA & 3DS
- handled, not deferred
- Daily
- ledger reconciled to processor
Who this is for
You probably need this if…
01
Payments occasionally take twice
A retry, a double-click or a replayed webhook, and a customer is charged two hundred dollars where they should have been charged one.
02
Month end is a manual reconciliation
Somebody exports the processor report and matches it against your records by hand. It takes a full day and it is nobody's favourite day.
03
Failed payments are quietly lost
A card expires, the charge fails, nobody chases it, and a subscription ends without anyone at your company ever deciding that it should.
What this covers
The work, in detail.
7 capabilities
01
Checkout & payments
Card, wallet and bank payments, with the failure paths designed as carefully as the one where everything goes right.
02
Subscriptions & billing
Plans, proration, trials, upgrades and dunning. The edge cases are where subscription revenue actually leaks out of a business.
03
Invoicing & receipts
Generated, numbered, delivered and stored, in a sequence that an accountant will accept without asking you to explain the gaps.
04
Marketplace payouts
Split payments, connected accounts, holdbacks, and the compliance obligations that arrive the moment you move other people's money.
05
Tax & compliance
Sales tax and VAT calculated through a dedicated provider, because getting it wrong is a penalty rather than a bug report.
06
Reconciliation
Daily comparison of your ledger against the processor, producing the specific differences by name rather than a count of them.
07
Refunds & disputes
Chargeback evidence assembled automatically from the order record, rather than reconstructed by somebody under a seven-day deadline.
How we approach it
Positions we actually hold.
Opinions cost something to have. These are the ones we would argue for on your project, including where they make the work slower.
01
Every payment operation is idempotent
A retried request must never create a second charge. This is the single most common serious bug in payment code and it is entirely preventable.
02
The webhook is the source of truth
Not the browser redirect. Users close tabs and networks drop out. Order state is confirmed server side or it is not confirmed at all.
03
Never store card data
Tokenisation through the processor and hosted fields in the browser. Holding card numbers yourself is a liability with no corresponding upside.
04
Reconcile daily, not monthly
A discrepancy found the next morning still has a cause you can trace. The same discrepancy found at quarter end is archaeology.
Technology
What we work with.
Defaults, not requirements. If you already run something else and have a team who knows it, we work in yours.
- Processors
- Stripe, Adyen, Square, Authorize.net
- Billing
- Subscriptions, metering, proration, dunning
- Tax
- Stripe Tax, Avalara, TaxJar
- Controls
- Idempotency keys, signed webhooks, daily reconciliation
Where this shows up in delivery
- Sill carries billing and subscription handling in production, charging real customers every month.
- Dunning, proration and failed-payment recovery live in the platform rather than being reimplemented on each project.
- Daily reconciliation between processor reports and the ledger runs on builds we have shipped.
Bought as part of
This practice is never sold on its own. It is quoted inside one of the engagements above, as part of a single number.
Proof
Where we have actually done this.
Projects we designed, shipped and wrote up. Each one names the decision that was genuinely hard to get right.
Questions
What people ask about payments & commerce.
- Are you PCI compliant?
- The useful question is scope. We build so that card data never touches your servers, using hosted fields and tokenisation, which keeps you in the simplest SAQ category. Your acquirer confirms the specifics for your situation.
- Can you migrate us to a different processor?
- Usually. Most processors support importing tokenised cards from another provider, which avoids asking every customer to re-enter their details. It needs coordination between both sides and we scope it as its own piece of work.
- What about international payments?
- Multi-currency, local payment methods and regional requirements such as SCA. Which of those you actually need depends on where your customers are, and that is a week-one question.
- Do you calculate the tax yourselves?
- No, and nobody should. We integrate a dedicated tax provider. Rates change constantly across thousands of jurisdictions, and being wrong is a penalty rather than something you patch next sprint.
Related reading
Written on this, by us.
Data & Integration · 6 min read
Idempotency: The One Word That Stops You Charging Someone Twice
The most common serious bug in payment code is not fraud or a failed gateway. It is a retry that creates a second charge, and it is entirely preventable.
Data & Integration · 8 min read
What POS Integration Actually Costs a Multi-Location Restaurant
Online ordering that doesn't talk to your POS costs you ninety minutes a night and a food cost number you can't trust. Here's what the integration involves and what it's worth.
Tell us what you’re trying to build.
Describe the problem in your own words. We’ll come back within one business day with a scope, a number and a date.
Phone
+1 (407) 796-2376Reply time
One business day, from an engineer
Based in
Orlando, Florida · serving the United States
What happens next
- A reply within one business day, from an engineer
- A thirty-minute call, with no qualifying call before it
- A written scope and a fixed number, if it fits