SaaS
Remittance partner onboarding API
Built by Leandro Magbanua
Built the partner-facing API a Singapore remittance company uses to onboard payout partners, working from Manila on a team spread across three time zones.
Builder email verified
Verification
- Type
- Professional
- Category
- SaaS
- Published
- Jul 26, 2026
- Updated
- Jul 26, 2026
About this project
- The problem
The client — a remittance company headquartered in Singapore — onboarded payout partners through emailed spreadsheets and a compliance review that lived in someone's inbox, so bringing a new corridor live took six to eight weeks and nobody could say where any application actually stood. They wanted a proper partner API: submit documents, track status, get sandbox credentials, promote to production. I was contracted through a Manila vendor as part of their distributed platform team.
- My role
Backend developer, one of three on the partner platform squad, for about a year — the others were in Singapore and Warsaw, so my overlap hours were mornings and the handoff notes mattered as much as the code. A compliance officer on the client side was effectively a second product owner, since half the workflow existed to satisfy their obligations to the regulator.
- What I owned
I owned the onboarding state machine — the service that tracked a partner application through document submission, compliance review, sandbox, and production go-live — plus the webhook system that notified partners of status changes, and the sandbox environment's simulated payout responses. The API contract itself was a three-way negotiation I drafted and redrafted; the eventual OpenAPI spec went through eleven versions before the first partner integrated.
- Technical & product decisions
I pushed for idempotency keys on every state-changing endpoint from day one, having watched partners' integration code retry blindly on timeouts in a previous job — that decision made every 'we submitted twice' support ticket a non-event. Publishing state changes onto Kafka and deriving both webhooks and the internal review queue from the same stream, rather than dual-writing, came out of a design review argument I initially lost and then won a sprint later when the dual-write version dropped a notification in testing. The sandbox returning realistic failures — expired documents, rejected beneficiaries — rather than always succeeding was my hill; partners hated it in week one and thanked us at go-live.
- Constraints
The compliance workflow had to satisfy Singapore's regulatory expectations, which meant certain review steps could not be automated no matter how obvious the approval looked, and every screening decision needed an audit trail with a named human attached. One document-verification vendor's API returned inconsistent results between their sandbox and production and their support loop ran about a week per question, so we built a verification abstraction mostly to quarantine them behind an interface we controlled.
- Result & impact
New partner onboarding went from six-to-eight weeks to a median of nine days, with the remaining time being genuine compliance review rather than lost email. Twelve payout partners integrated against the API in the first year. The status webhook cut 'where is our application' emails to nearly nothing, which the client's operations lead called the best feature — a sentence I have thought about a lot, given how much harder the state machine was to build.