2026 JAN
01 · CAPTURED
Buyer enters card on hosted checkout.
PAN captured on a Vonpay-hosted surface — never reaches your servers.
4242 4242 4242 3492
// TOKENIZATION & VAULTING
Don't leave approvals
on the table.
Network tokens approve at higher trust than raw PAN. The vault is what makes them durable — but the revenue lift is what makes them matter.
VAULT · ONE TOKEN
ACTIVE SINCE 2026TOKEN REFERENCEvt_4242···78cT
UNDERLYING•••• 9981
WAS•••• 3492
CHARGES TO DATE$1,872
REISSUES SURVIVED2
// HOW THE LIFT COMPOUNDS
One token. Three years of higher approval rates.
Issuers approve network tokens at higher trust than raw PAN — every charge against this saved credential prices and approves better. And when the underlying card reissues, the token rotates without you chasing the customer. The lift compounds.
2026 JAN
02 · TOKENIZED
Network token issued by Visa.
Cryptographically bound to your merchant + the cardholder. The PAN is gone from your environment.
vt_4242···78cT
2026 FEB
03 · FIRST CHARGE
MIT subscription charge succeeds.
Token reused without merchant-side PAN handling. Stored-credential framing carries through.
$49.00 · approved
2027 NOV
04 · REISSUED
Customer's card reissues.
Old PAN expires. Bank issues replacement. Without a network token: hard decline cascade starts.
••3492 → ••9981
2027 NOV
05 · AUTO-UPDATED
Token survives. Same reference.
Visa Token Service rotates the underlying PAN behind the same token. Zero merchant action. Zero downtime.
vt_4242···78cT
2028+
06 · STILL CHARGING
Renewal cycle uninterrupted.
Subscription continues across reissues. Recurring revenue isn't lost to issuer events outside your control.
$1,872 lifetime
−15%Recurring decline rateAuto-rotated tokens vs. raw PAN on file.
+4.7–6.2%Authorization rate liftNetwork tokens approve at higher trust at the issuer.
SAQ-AFrom day oneThe vault carries Level 1; your env stays out of scope.
// HOW A CARD-ON-FILE IS CREATED
The reusable token is minted at the moment of the first charge.
On the embedded checkout, the charge-and-save flow vaults a reusable card-on-file token in the same step it charges the card — one submit, not two. Because the charge already happened, don't also run a separate server-side charge for that session, or you'll bill the buyer twice.
One submit
Submit charges the card and mints the reusable token together. Don't fire a second server-side charge for the same session.
Identified buyer required
Vaulting a reusable token requires an identified buyer on the session. A guest checkout with no buyer charges once and saves nothing.
Confirm before you fulfill
The client-side result is a UX signal, not settlement. Confirm the charge server-side via the webhook before you fulfill the order.
// WHERE THIS CONNECTS
The vault is the storage layer. The other two cover what happens to the card before and around it.
Routing enginePayment orchestration
How vault tokens get charged across multiple acquirers, with real-time failover.
Read more Compliance posturePCI complianceThe audit-scope math that follows from never touching PAN.
Read more Operator guideRecurring payment processingThe four failure modes of subscription billing — and how network tokens fix two of them on day one.
Read more// MAXIMIZE YOUR REVENUE
Every decline is revenue you already earned.
Network tokens approve at higher trust than raw PAN. Stop leaving authorized transactions on the table because the issuer didn't recognize what you stored.