Payments & acquiring
Getting paid, built properly into your product — including all the parts that only show up after go-live.
Payments look like a solved problem from the outside. Add a provider SDK, take a card, done. The reality is that the happy path is perhaps a fifth of the work, and everything expensive lives in the other four-fifths: a customer whose card is charged while your server times out, a refund that has to reverse a partially-fulfilled order, a webhook delivered twice, a month-end reconciliation where the provider's total and yours disagree by eleven euros and nobody knows why.
I integrate payment processing and acquiring into products so customers can pay you the way they expect — securely, and without surprises at checkout. I have shipped it in a subscription product selling plans and single documents, in a streaming platform I architected from a blank page where every play draws down a prepaid balance, and as bank acquiring fitted into an existing CRM another team had built, which had no concept of a payment that is registered but not yet resolved. Which means I have debugged the interesting failures rather than only read about them.
I am an engineer, not a payments licence. I integrate the providers and acquirers you contract with, and I build the parts of your system that have to be correct around them.
What you get
Checkout that works on real devices
Web and mobile flows integrated with your provider, including the states people actually hit: declines, timeouts, back buttons and lost connections mid-payment.
Correct money handling
Idempotency, retries that cannot double-charge, and a transaction record that is the source of truth. Money code gets written defensively, because a bug here has a cost measured in currency.
Refunds, partial refunds and cancellations
The flows that get skipped in the first version and then get built under pressure with an angry customer waiting. Better to have them from the start.
Reconciliation you can trust
Your ledger against the provider's settlement, with differences surfaced rather than discovered by an accountant in the following quarter.
How it works
- 01
Establish the model
One-off, subscription, marketplace or split payouts — each implies a different architecture and a different set of legal and provider constraints. Getting this wrong is expensive to undo.
- 02
Integrate against the sandbox properly
Every state the provider can return, including the ones their happy-path documentation does not lead with.
- 03
Build the unhappy paths
Duplicate webhooks, timeouts, partial fulfilment, chargebacks. This is the part that separates a payment integration from a payment demo.
- 04
Go live with reconciliation on day one
Because the first month is exactly when you need to be able to prove the numbers.
Typically built with
Where I have done this
E-PL
Remote pre-trip medical checks over a Bluetooth breathalyzer, electronic waybills with qualified signatures, and the shop and delivery pipeline that puts the hardware in the driver's hand.
Read more →Benzigo
The customer-facing app with card payment for invoices, and a fleet of autonomous bots that carry out fuel-card operations on the provider's own platform.
Read more →fjalla
A streaming platform that pays artists per play — architected and written from nothing, then grown with a team.
Read more →Cinemusic
A royalty-cleared music licensing platform for television and post-production — where I owned the commercial side: payments, subscriptions and the catalogue people search.
Read more →Common questions
Which payment providers do you work with?
Whichever you contract with. Provider choice is driven by your market, your business model and the rates you negotiate — not by which SDK an engineer prefers. The integration work is broadly similar across them, and I will flag early if a provider you are considering is a poor fit for how you actually sell.
Do you handle PCI compliance?
The standard approach is to never let card data touch your servers — hosted fields or the provider's own checkout — which keeps you in the lightest compliance tier. I build it that way by default. Formal certification is between you, your provider and, at higher tiers, an assessor; I make sure the architecture does not make it harder than it needs to be.
Can you add payments to a product we already have?
Yes, and that is the usual case. The main question is whether your existing order and state model can express partially-paid, refunded and disputed states, or whether it assumes every order is simply "paid". If it is the latter, that is the real work, and I would rather find it before we start than after.
What about subscriptions and recurring billing?
Supported, and worth treating as its own project rather than as a checkbox. Dunning, failed renewals, plan changes mid-cycle and proration are where subscription systems actually get complicated, and none of it is visible in a first demo.
Have a project like this?
Tell me what the system has to do and what it has to talk to. You get a straight answer about scope, sequence and what I would build first — before any commitment.
Start a conversation