Payment integration design
For teams choosing a gateway, wiring one into a platform, or trying to get a customer live on a payments API without a month of back-and-forth.
Who this is for
Every vendor deck says yes to everything. You need someone to run the candidates against your actual flows and tell you which one will still be working in a year.
The plugin docs and the API docs disagree, the webhook story is vague, and nobody has said out loud what happens to a refund after settlement.
Onboarding takes weeks of email, sandbox credentials that don’t verify, and a UAT phase that nobody owns. You’d like it to take days, and to have evidence at the end.
What I’ve done
Most recently I was the technical interface between developers and everyone outside the building at a global payments platform: evaluating every vendor API before the dev team touched it, writing the flow guides clients built from, and walking customers from the first demo to live traffic. Before that I co-founded a payments aggregator and built its frontend while co-designing the API, and spent two years at an MSP owning integrations from discovery through go-live.
I got tired of running UAT out of Postman tabs and spreadsheets, so I built UAT-Ops, a workbench that runs the whole onboarding cycle against real sandboxes and keeps the evidence. It’s what I use on engagements.
Three levels of involvement
Where the integration stands decides which one fits. Each is a step deeper than the last, and they can be taken one at a time.
Gateway or platform selection
Before you’ve chosen
A short, fixed-scope evaluation. I exercise each candidate against the flows you actually run — auth, edge cases, failure modes, webhook and settlement behavior, how faithful the sandbox is to production — and write down what I found.
You get A written recommendation with the reasons, and the test evidence behind it.
Integration architecture review
Chosen, not yet built
I read the plan and the flows before they’re committed to: boundaries, contracts, idempotency, webhook handling, refunds and settlement, what happens when the provider is down. The point is to find the expensive surprises while they’re still cheap.
You get Findings and a fix list, ordered by what it would cost to discover later.
Go-live readiness and UAT design
Built, not yet live
I define the acceptance flows, run them against the sandbox, and keep the results. The last mile of the integration gets an owner and a record, instead of a Postman tab and a memory.
You get A UAT plan, the executed runs, and a go/no-go you can show to whoever signs.
Each level is a fixed-scope project. Ongoing access is available as a retainer; the consulting overview has both models.
How I work
Payment problems show up at the top of the stack: a capture that fails, a chargeback nobody can trace, a customer stuck in onboarding for a month. The causes are almost always lower down, in how the work is organized, what’s written down, and whether the people involved are working from the same facts. I use a five-layer framework for this, and on payments engagements the pattern is consistent: the symptom is at the Signal layer, and the fix is in Operations, Infrastructure, or Clarity.
The Foundation Layer is the full argument.
Proof of method
- UAT-Ops
A workbench I built for exactly this work. Every provider call it makes is real and recorded; the case study has the numbers and a walkthrough.
- UAT is where integrations go to die
Why the last mile of a payment integration absorbs more schedule than the build, and what fixes it.
- How I evaluate a vendor API before the dev team touches it
The gate I put in front of a development team at a global payments platform, as a checklist.
Start a conversation
Tell me what you’re integrating and where it’s stuck. I’ll reply with whether one of the three shapes above fits, or what I’d suggest instead.