bKash Tokenization Mock API
Spotify gave Boku a hard launch date for bKash, and hitting it meant both sides integrating at the same time. The catch: our real sandbox wouldn't be ready until the exact day Boku needed their integration finished. So I built a mock of the bKash API faithful enough to integrate against, and both teams built in parallel instead of in line. The slot held, and it has processed 260K+ transactions since.
The API structure and requirements for the bKash integration were already agreed with Boku and Spotify. The timeline was the problem. Even with my dev team stretched thin, the earliest we could ship a real sandbox landed on the same day Boku had estimated their own integration needed to be done. That left them no time to actually build against it. It was a straight serial dependency aimed right at Spotify's launch slot. Boku and Spotify were both worried we were going to miss the integration window and push the launch date.
My CPO came to me with the problem: we couldn't deliver the real thing in time and the timelines wouldn't meet. I took an all-nighter and built a working mock API MVP, then showed it to him the next day. We proposed it to Boku and said we could hand over mocks within a week. They agreed to integrate against it, which they told us was a first for their company. The mock copied the agreed API closely: five core endpoints, around 40 status and error codes, idempotency, signed responses, async webhooks, and a hosted bKash-style redirect simulator that could force any outcome on demand. With it in Boku's hands, both teams built at the same time instead of waiting on us.
Turn a waiting game into parallel work.
A faithful mock turns a serial dependency into a parallel one. Normally you integrate against the vendor's sandbox, but ours wasn't going to exist in time and the launch slot wasn't moving. My CPO brought me the problem with no clear way out. So I built the mock overnight, proved it worked, and we put it in front of Boku within the week.
Faithful enough to trust your integration to.
A mock only replaces a sandbox if it breaks in the same places the real thing does. So it had idempotency through a requestID header, signed responses with mock cryptography, asynchronous webhooks on realistic delays, and a redirect simulator that could force any of about 40 transaction outcomes on demand. It ran on a Prisma and SQLite store for transactions, tokens, idempotency, webhooks and refunds, with Zod validation and an OpenAPI surface. That fidelity is what let Boku trust their integration to it instead of a PDF.
The slot held, and the mock outlived its purpose.
Because neither team had to wait, the integration went live on Spotify's slot. Boku had already validated every success path, every error code, and the full redirect and webhook lifecycle against the mock.
Here's the part I didn't expect. When my engineering team finally delivered the real sandbox, it didn't match the spec as closely as the mock did. Boku ran their final testing against the sandbox, and my engineers had to rework it to line up with the behavior the mock had already locked in. The throwaway ended up being the reference. Since launch the integration has processed 260K+ transactions and around $465K in billing volume, at a 75% first-attempt success rate.
Success rate by attempt type · audit of 260K live transactions
First tries and automatic retries both land near 75%, so this isn’t an error loop. The dip shows up only on manual retries, which points to wallet balance.