Network tokens vs PSP tokens: the same card, different replacement chains
When a card expires, one of these breaks. The other doesn't.
By Solomon Ajayi · Free to read, no signup
You save a user's card so they can buy with one click. You DON'T store the real PAN (16-digit card number), that would put you in PCI Level 1 scope and one breach away from the SEC. Instead you store a TOKEN. Two flavours: a PSP TOKEN (issued by your processor, Stripe, Paystack, and works only with that processor), or a NETWORK TOKEN (issued by Visa/Mastercard/Verve themselves, works across processors and AUTOMATICALLY UPDATES when the cardholder gets a new card). The ledger doesn't change much by token type; the user experience does. Failed payments due to expired cards are 5-10% of subscription churn for fintechs without network tokens.
This lesson is the rare one where the interesting decision lives entirely upstream of the ledger. To save a card for one-click purchases without holding the raw card number (which would drag you into the harshest PCI scope), you store a token that stands in for the real number. The accounting for a recurring charge is the same plain two-line entry no matter which kind of token you used. What differs is whether that charge succeeds at all.
There are two kinds of token, and the difference shows up when a card expires or gets reissued. A PSP token is minted by your processor and is glued to that processor; when the underlying card changes, the token goes stale and the next charge declines. A network token is minted by the card scheme itself and is silently remapped to the cardholder's newest card, so the charge keeps working without anyone lifting a finger. Same ledger entry, very different success rate.
The cost of getting this wrong is involuntary churn. When a recurring charge fails because the saved card expired, you do not just lose one payment, you risk losing the whole subscription while you chase the user to update their details. Card expirations and reissues drive a meaningful chunk of subscription churn, and network tokens reclaim most of it for the price of a few extra API calls at card-save time. Design the save flow network-token-first and fall back to a PSP token only when a card's BIN is not enrolled.
Worked example, step by step
User saves a card (network token: stored at the scheme)
User adds a card. You request a network token from Visa. Visa returns a token that represents the user's PAN. You store ONLY the token, never the PAN. Visa transparently keeps the token mapped to the user's latest active card, if their card is reissued (expiry, theft, breach), the token still works.
| Account | Debit | Credit |
|---|---|---|
| Auth Pending (1110) | ₦0.01 | |
| Auth Counterparty (2110) | ₦0.01 |
No journal entry for the token registration itself. Tokens are operational metadata, not money. (We omit a marker entry here, token storage is a side-table event, not a ledger event.)
Months later: user's card expires and is reissued
Cardholder's bank issues a new card. With NETWORK tokens, your processor refreshes silently, the next charge succeeds. With PSP tokens, the next charge fails (declined: invalid card). You then have to email the user, ask them to update payment, and risk losing them.
| Account | Debit | Credit |
|---|---|---|
| Auth Pending (1110) | ₦0.01 | |
| Auth Counterparty (2110) | ₦0.01 |
Still no journal entry. The point: SUCCESSFUL recurring charges land normally. FAILED ones cost you the entire subscription cycle. Lesson 13 (failed-transaction-release) covers the failure-path bookkeeping; the value here is the design choice of network token vs PSP token UPSTREAM of the ledger.
Recurring charge: ₦2,000 monthly subscription, succeeds via network token
Standard recurring charge. The network token auto-updated against the new card, the charge succeeded, the wallet credits with the subscription period's pre-paid value. (Subscription accounting itself is deferred revenue territory, lesson 10. Here we focus on the charge succeeding because tokenization was right.)
| Account | Debit | Credit |
|---|---|---|
| Bank Account (1200) | ₦2,000.00 | |
| User Wallet (2000) | ₦2,000.00 |
Bank Account UP ₦2,000 (debit, the funds settled to you via the card flow, simplified). User Wallet UP ₦2,000 (credit, they got the subscription period's value into their wallet as a placeholder for the service).
Takeaway
Network tokens are a free upgrade for any fintech running recurring charges. Migration cost: a few API calls during card-save. Benefit: 5-10pp reduction in involuntary churn from card expirations / reissues. The ledger doesn't change. The operational pain does. PSP tokens are a perfectly fine fallback when network tokens aren't available (some BINs aren't enrolled) but they should be the EXCEPTION, not the default. Build your card-save flow with network-token-first logic and PSP-token only on failure.
Practice this on a real ledger
Reading is half of it. Open this lesson in the lab to post the entries yourself against a real Postgres-backed double-entry ledger, with the validation on. Free, your sandbox is yours.