A digital wallet is either a thin skin over a card you already have, or a balance in its own right — and the difference decides who carries the risk and earns the economics. Tokenization, HCE and push provisioning are the machinery underneath. In Africa, the device reality shapes everything.
A digital wallet stores payment credentials on a device so a user can pay without the physical card. But “wallet” covers two fundamentally different things, and conflating them is the most common error in the category. The architectural split — pass-through versus staged — decides who holds funds, who carries the risk, and where the money actually sits.
Pass-through wallets (Apple Pay, Google Pay, Samsung Pay) hold no money — they relay an existing card’s tokenised credential to the merchant. Staged wallets (M-Pesa, PayPal balance, many super-app wallets) hold a balance of their own and the payment happens in two stages: fund the wallet, then spend from it. One is a nicer way to use your card; the other is a parallel account.
A pass-through wallet never stores your real card number. At provisioning, the card scheme’s tokenization service replaces the PAN with a device-specific network token (a DPAN) bound to that phone. Every tap sends the token plus a one-time cryptogram — intercept it and it is useless on any other device, which is why a wallet tap is structurally safer than the plastic.
Where the token lives differs by platform:
| Mechanism | What it is | Used by |
|---|---|---|
| Secure Element (SE) | Tamper-resistant hardware chip holding the credential | Apple Pay, Samsung Pay |
| HCE | Host Card Emulation — credential held in software/cloud, OS-mediated NFC, no hardware SE needed | Google Pay, many bank apps |
| Network token (DPAN) | Scheme-issued surrogate PAN bound to the device | All OEM Pay wallets |
| Push provisioning | Issuer’s own app pushes a card into the OS wallet in a couple of taps | Bank apps → Apple/Google Pay |
Apple Pay uses the device’s hardware Secure Element and gates NFC access tightly; issuers integrate through Apple and typically pay Apple a slice. Samsung Pay also uses an SE. Google Pay took the different road that matters most for emerging markets: HCE, where the credential is held in software and the cloud rather than a hardware SE, so any Android phone with an NFC chip can tap — no special secure hardware required.
Push provisioning is the glue that makes adoption feel effortless: from inside their banking app a user taps “Add to Apple/Google Pay” and the issuer provisions a token straight into the OS wallet. The smoother this flow, the higher the wallet attach rate — a clumsy or absent push-provisioning integration is the quiet reason many issued cards never make it into a wallet at all.
Biometric/PIN on the phone satisfies cardholder verification — so the contactless card CVM tap limit effectively does not constrain a wallet tap.
Each device gets its own token. Lose the phone and the issuer kills that token without reissuing the physical card.
In pass-through, the underlying card and its risk stay with the issuer — the wallet is a presentation layer, not an account.
South Africa — like most of Africa — is an Android-majority market, skewed toward mid- and entry-range devices. That single fact reshapes wallet strategy. Apple Pay reaches the affluent iPhone minority; the mass market is Android, and the mass market’s phones do not all carry a usable hardware Secure Element. HCE is what makes tap-to-pay viable at scale here, because it does not depend on SE hardware — the credential lives in software and the cloud.
This is why bank-built HCE wallets and Google Pay (HCE-based) matter disproportionately in this region, and why an issuer’s mobile-wallet plan that assumes a Secure Element is quietly designing for the wealthy minority. The device reality, not the marketing, should drive the architecture. (For the mechanics, see the HCE explainer on the sibling site.)
Pass-through OEM wallets ride on card ownership — which a large share of the population does not have. The genuine mass-market wallet across much of Africa is the staged mobile-money balance (M-Pesa and its peers), which needs no card and no bank account. In emerging markets the most important wallet is usually the staged one, not the OEM Pay skin over a card.
Assuming hardware-SE wallets in a market where most phones are mid-range Android designs tap-to-pay for the minority. HCE exists precisely to avoid this.
If “Add to Apple/Google Pay” is not a two-tap flow inside the bank app, attach rates crater. Issued cards that never reach a wallet are lost engagement and lost tap volume.
They carry completely different fund-holding, e-money licensing and risk obligations. Treating a staged balance like a pass-through card skin invites a regulatory surprise.
Apple Pay and the schemes take their cut. Wallet economics that ignore the platform fee model can turn a “free” feature into a margin leak at volume.
Tokens must be suspended, resumed and deleted as cards are lost, reissued or expired. Issuers that do not manage the token lifecycle leave live credentials on dead cards.
Support pass-through OEM wallets (Apple/Google/Samsung Pay) for any card-issuing program — users expect it, the network tokenization makes taps safer, and a clean push-provisioning flow lifts engagement. This is table stakes, not a differentiator. Lean on HCE / Google Pay as the mass-market path in an Android-majority market: it does not need a Secure Element, so it actually reaches the devices your customers carry.
Build or partner on a staged wallet only with eyes open — holding a balance means e-money or banking obligations, float management and a far heavier compliance load than a pass-through skin. In genuinely under-banked segments a staged wallet may be the only wallet that reaches the customer, which can justify the burden; in a card-rich segment it rarely does.
Cost of being wrong: bet on hardware-SE wallets in an Android market and you ship a feature most of your base cannot use. Skimp on push provisioning and you fund a card nobody loads into their phone. Stand up a staged wallet without the licensing and float discipline and you are holding customer money under rules you did not plan for — the most expensive wrong turn in the category, because it is a regulatory problem, not a product one.