Sixty payment providers, one checkout.
Integrated, maintained, and scaled 60+ third-party payment provider APIs behind a single e-commerce checkout — transaction processing and fraud handling across multiple regions and regulatory regimes. Employer and client names withheld; specifics under NDA.
Every payment provider believes it is the standard.
Sixty of them means sixty auth schemes, sixty webhook formats, sixty failure vocabularies, and sixty ideas about idempotency — feeding one checkout that must never double-charge, silently fail, or leak a card number.
The work: make provider count an operational detail. Adding gateway #61 should be routine engineering, not a project.
Adapters at the edge, a state machine in the middle.
Checkout talks to an orders API. Orders run a fraud pipeline, then a payment orchestrator drives a transaction state machine. Every provider sits behind one adapter contract; webhooks are verified and reconciled back into the same machine. Sanitized diagram.
One adapter contract per provider
Each gateway implements one normalized interface; quirks live inside the adapter, never in checkout logic. That is what kept #60 as boring as #6.
State machine over status strings
Transactions move through explicit states with audited transitions. Reconciliation reads the machine, not provider payloads.
Idempotency keys everywhere
Retries and duplicate webhooks are absorbed, not double-processed. Fraud checks run as a pipeline stage ahead of capture, tuned per region.
Own the checkout UX end to end
Angular + Ionic mobile. Optimization work on the flow contributed to a measured 15% conversion-rate increase.
Volume figures belong to the client. The transferable claim: payment integrations at this count are an architecture problem, not a coding problem — and the adapter/state-machine shape above is what kept #60 as boring as #6.