bKash Tokenization Mock API
A behavior-faithful bKash tokenization mock that stood in for a sandbox we did not have, so two engineering teams built in parallel and Spotify’s hard launch slot held on time.
Spotify had a hard launch slot for bKash that wouldn’t move. The real production API realistically needed ~2 months, and integration is normally done against a vendor sandbox, but there wasn’t one in time. Until something existed to integrate against, Boku (the aggregator) couldn’t even start. That serial dependency pointed straight at the launch date.
Rather than wait, I specced and stood up a behavior-faithful mock of the exact agreed API and had Boku integrate against that instead of a sandbox: 5 core endpoints, ~40 status/error codes, idempotency, signed responses, async webhooks, and a hosted bKash-branded redirect simulator with deterministic outcomes. With it in place, both engineering tracks built simultaneously instead of in sequence.
Parallelize the dependency, protect the date.
A faithful mock collapses a serial dependency into a parallel one. Integration is normally done against a vendor sandbox, but there wasn’t one in time, and the launch slot wouldn’t move. A mock that behaved like production let Boku and Simpaisa build simultaneously and integrate against real behavior, not a PDF, months before the production system shipped.
Faithful enough to replace a sandbox.
A mock only stands in for a sandbox if it breaks where the real thing breaks: idempotency via a requestID header, signed responses with mock cryptography, asynchronous webhooks on realistic delay, and a redirect simulator that could force any of ~40 transaction-level outcomes on demand.
That fidelity, built over a Prisma/SQLite store for transactions, tokens, idempotency, webhooks and refunds, with Zod validation and an OpenAPI surface, is what let the partner trust their integration against it. Building the mock was the easy part; making it behave like production was the point.
The slot held, then the volume proved it.
Because the engineering tracks never had to wait on each other, the integration went live on Spotify’s hard slot. The partner had already validated every success path, every error code, and the full redirect-plus-webhook lifecycle against the mock.
Since launch it has processed 260K+ transactions, roughly $465K in billing volume, at a 75% first-attempt success rate. A later audit of that live data confirmed the integration is technically healthy: most repeat hits are automated retries or users re-authorizing payment, which points to a retaining base rather than churn.
Success rate by attempt type · audit of 260K live transactions
First tries and automatic retries succeed alike (~75%) — so it’s not an error loop. The dip on manual retries points to a wallet-balance gap, not the integration.