Simpaisa × Safepay

Cards Tokenization & Direct Charge API

A single merchant API that collapses Safepay’s nine-step card-tokenization stack into one call, so returning customers at Yango and Temu pay card-on-file, unlocking $251K+ in monthly volume.

Role / Product Manager · operator integration, API design & PRDYear / 2026Status / Live in production · Yango & Temu onboarded

A glossy black credit card etched with lime circuitry, fed by one clean conduit out of a dimmed tangle of operator machinery, extruding into a single faceted lime card-on-file token.

$251K+/moNEW VOLUME · YANGO & TEMU

71%FIRST-ATTEMPT SUCCESS RATE

The problem

Simpaisa processed every card payment as a one-time transaction. Returning customers re-entered their full card details and cleared a 3DS challenge on every single purchase, a first-time tax paid on every repeat order. For merchants whose model is repeat revenue, like Yango (ride-hailing) and Temu (marketplace), that friction bled conversion on every transaction, and Simpaisa had no card-on-file mechanism to stop it. The only way to add one ran through Safepay, whose tokenization stack (CyberSource underneath, a frontend Atoms SDK, Cardinal 3DS, four distinct flows) was far too raw to hand a merchant.

What I did

I owned both halves of the architecture. Inward, I mapped Safepay’s four flows end to end (raw-card capture, token-initiated charge with and without 3DS, and zero-amount tokenization), including the secure-gateway hop for raw PANs, the Atoms handshake, and the wallet lookup that returns the reusable token. Outward, I collapsed all of it into one merchant endpoint: a single POST where four parameters (payment_type, source.type, amount, and 3ds.enabled) route five capabilities, and merchants hold only opaque references (a c_token, a Simpaisa cref_, a UUID tracker_id), never a raw card or a Safepay primitive.

Safepay × CyberSourceCard-on-file tokenization3DS / Atoms SDKZero-amount authAPI abstraction designPCI DSS

THE INSIGHT

Returning customers paid the first-time tax on every purchase.

The friction was not the checkout. It was that every checkout was a first checkout. With one-time-only payments, a returning customer re-entered their card and re-cleared 3DS for the hundredth ride or the tenth order, exactly as they had for the first.

For Yango and Temu, whose economics rest entirely on repeat purchase, that tax landed on every transaction. The fix was not a better form. It was card-on-file: store the card once, then charge it on a single call.

THE ARCHITECTURE

Hide the operator, expose the capability.

Safepay’s tokenization is capable but unapologetically raw: four flows keyed on different entry modes, a frontend SDK running device fingerprinting and the 3DS challenge, a separate hop through Simpaisa’s secure gateway for raw card numbers, and a zoo of tokens (customer, tracker, request, card, payment-method) threaded through nine steps. No merchant should have to learn that to save a card.

So the merchant API exposes none of it. One POST /cards/payments routes all five capabilities off four parameters. The riskiest, frictionless non-3DS charging, sits behind a per-merchant flag that requires a risk review before it switches on. Sequential transaction IDs became opaque UUID tracker_ids; a missed webhook cannot lose a token because the Inquiry API returns it as a second channel; and the same customer never spawns a duplicate record. The complexity did not disappear. I absorbed it so merchants would not have to.

One request shape · four parameters · five capabilities

C1Pay + tokenizepayment_typetokenizationsource.typecardamount> 03ds.enabledtrueresolves toCharge now, save the card

C2Save without chargepayment_typetokenizationsource.typecardamount0.003ds.enabledtrueresolves toZero-auth, card on file

C3Charge a saved cardpayment_typedirectchargesource.typec_tokenamount> 03ds.enabledtrueresolves to3DS repeat charge

C4One-call chargepayment_typedirectchargesource.typec_tokenamount> 03ds.enabledfalseresolves toSynchronous · no redirect

C5List / delete cardspayment_type—source.type—amount—3ds.enabled—resolves toPOST /cards/tokens

Four parameters disambiguate every flow — the merchant sends one request shape and Simpaisa routes it. C4, the frictionless one-call charge, ships behind a per-merchant risk flag before it switches on.

OUTCOME

Two flagship merchants, live on card-on-file.

Yango and Temu both onboarded onto the new flows, unlocking $251K+ in monthly payment volume at a 71% first-attempt success rate, with PCI DSS certification carried through to completion. Returning customers now check out in a single call (no re-entry, no redirect, no challenge), and Simpaisa has the card-on-file primitive its merchants need to build subscriptions and one-tap repeat checkout on top of.

What the merchant never sees

Operator integrationSafepay × CyberSource · I mapped it

4 flows9 steps6 token typesraw PANs via secure gatewayfrontend Atoms SDKCardinal 3DS handshake

Merchant APISimpaisa Cards · what they call

1 endpoint4 parameters3 opaque refs0 raw card data

9 steps → 1 callthe operator’s complexity, absorbed — not passed downstream

$251K+/monew payment volume unlocked

71%first-attempt success rate

2flagship merchants live — Yango & Temu

Keep exploring

Simpaisa × Spotify / BokubKash Tokenization Mock APIA 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.sastaticket.pkCybersource Pending-Transaction FixTraced a 22% pending-transaction rate to a button that never disabled, then shipped the fix that eliminated it.