Payment integrations where Stripe was not always an option

In a Western SaaS product, choosing a payment provider means comparing fees, developer experience and features. In other markets there is often nothing to choose.

A government fee in Nigeria is collected through the system the state recognizes, because the law says where that money must arrive. A cross-border remittance product runs on a licensed partner, because without the license there is no product. In neither case does a better developer experience come into the decision.

A practical consequence that people underestimate is that the integration you end up building is often the one with the least documentation, the smallest community and no answers on Stack Overflow.

Government fee collection through a national gateway. PayPal ran alongside it for applicants outside the country, since a passport system also serves people abroad. Both payment options feed into the same flow.

Cross-border remittances through a licensed partner. The partner verified the payer's identity through card and bank checks, and our system verified the payment instruments: SWIFT, IBAN and card networks. This split is the usual one and the correct one, because a payer's identity is proven by the instrument they pay with, and the bank that issued it has already done that check.

Marketplace subscriptions and consumer payments. I built these on Stripe, PayPal, Apple Pay and Google Pay, including recurring charges with separate handling for a successful charge, a failed one and an upcoming one.

• Payment integrations in production in four markets
• Two of them use partners chosen by regulation

I built each integration where it was needed, around the shape of that one product. By the third one it was clear that the same concerns kept coming back: idempotency, retries, reconciliation and webhook verification. I never turned them into anything reusable. It would have helped, but each project ended before the pattern was clear enough for me to act on.