A payments API built like Lego

Problem

TransFi's volume grew from $20M to $150M+ a month across 40+ countries and 250+ payment methods. Every new business use case needs some mix of the same steps: identity checks, a quote, collecting funds, holding them, converting through stablecoins and paying out.

TODO(shubham): What was it like before the composable API? How long did a new use case take, and what kept breaking?

Constraints

• Local rails and stablecoin infrastructure behave very differently, but clients need one consistent API.
• Partners go down, slow down or run out of balance, so routing can't be hard-coded.

TODO(shubham): Other constraints: compliance, team size, timelines, backwards compatibility with existing clients.

What I built

A payments API built from small, reusable building blocks. Each block does one job. Blocks compose into end-to-end flows, and new business use cases are assembled from blocks that already exist instead of being built from scratch.

Building blocks

• KYC
• Quote
• Payin
• Wallet
• Stablecoin
• Payout

end-to-end flows

15

end-to-end flows

business use cases

10+

business use cases

verticals: FX, Ramp, Gaming

3

verticals: FX, Ramp, Gaming

• One API for payins and payouts, with standardized error codes, over both local rails and stablecoin infrastructure.
• Dynamic routing across partners, based on speed, downtime and balance availability.

TODO(shubham): How the blocks are defined, versioned and tested. One concrete example of a new use case assembled from existing blocks.

Outcome

• 15 end-to-end flows built from the shared blocks.
• 10+ business use cases supported.
• 3 verticals: FX, Ramp and Gaming.

TODO(shubham): Time to launch a new use case before and after, if you can share it.

What I'd do differently

TODO(shubham): What you'd change with hindsight.