“The integration you’ll actually build is often the one with the least documentation.”
Stripe doesn’t work everywhere
Five products, four markets, and the recurring lesson that the payment partner is chosen by the market, not by the developer.
Across five products we integrated Stripe, PayPal, Apple and Google Pay, a national government payment gateway in West Africa, and a domestic gateway in Bosnia and Herzegovina.
The technical work varies less than you’d expect. What varies — and what determines whether a product can launch at all — is that the choice usually isn’t yours.
The problem
The constraint
What we did
Government fee collection through a national gateway, with PayPal for applicants abroad
A passport system also serves people outside the country, so the two payment paths were joined into one flow. The national gateway because the law requires it, PayPal because an applicant in London cannot reach it.
Two paths, one flowCross-border remittance on a licensed partner’s rails
The partner handled identity verification through card and bank checks; our system verified the instruments — SWIFT, IBAN, card networks. That division is worth naming, because it’s the usual and correct one: the identity of a payer is proven by the instrument they pay with, and the bank that issued it has already done that work.
The instrument proves the personMarketplace subscriptions and consumer payments
Stripe, PayPal, Apple and Google Pay, including recurring charges with distinct handling for success, failure and upcoming. This was the only one of the three cases where the choice was ours.
Three outcomes, three messages
Collecting a government fee goes through the system the state recognises, because the money must arrive where the law says it arrives. Fees, documentation and developer experience are not part of the conversation. Alongside it, PayPal for applicants outside the country — a passport system also serves the diaspora.
The result
- Payment integrations live across four markets
- Two of them with partners chosen by regulation rather than preference
What we’d do differently
Each integration was built where it was needed, against the shape of that product. By the third one it was clear that the same concerns kept recurring — idempotency, retry, reconciliation, webhook verification — and we never lifted them into anything reusable. Not because it wouldn’t have helped, but because each project ended before the pattern was obvious enough to act on.
- Stripe
- PayPal
- Apple Pay
- Google Pay
- national gateways
- Node.js