Universal Vaults Are Just the Beginning
Over the last two years, I've spoken with hundreds of product leaders running recurring revenue businesses.
The conversations usually revolve around the same topics: authorization rates, chargebacks, PSP migrations, token management, and the rising cost of payments.
Most teams understand the value of a universal vault.
Storing payment credentials independently of a gateway has become table stakes. Nobody wants millions of stored cards trapped inside a single PSP.
But here's what often gets missed:
Moving the card is easy. Preserving the transaction history behind the card is much harder.
When people think about recurring payments, they usually think about subscriptions.
In reality, recurring commerce includes installments, delayed charges, incremental authorizations, reauthorizations, resubmissions, and a variety of other merchant-initiated transaction types.
At a high level, card networks separate these transactions into two buckets:
Customer-Initiated Transactions (CITs) and Merchant-Initiated Transactions (MITs).
A CIT happens when the customer is actively present and authorizing a payment.
An MIT happens later, when the merchant initiates a charge using previously stored credentials.
That's where things get interesting.
For many MIT transactions, issuers don't evaluate the payment in isolation. They evaluate it in the context of the original customer interaction.
Data points such as Network Transaction IDs (NTIDs), 3DS authentication results, stored credential references, and scheme indicators help issuers understand that this isn't a random charge. It's part of an established payment relationship.
The challenge is that these data points often get fragmented across gateways, processors, vaults, and payment providers.
A universal vault solves part of the problem by making payment credentials portable.
A great vault goes further. It preserves the transaction context needed to support future merchant-initiated payments, even when routing decisions, processors, or gateways change underneath.
This becomes especially important during PSP migrations.
Many merchants focus on whether they can move the card.
The better question is:
Can you move the history that helps future transactions get approved?
Because losing a token is inconvenient.
Losing the transaction context behind millions of recurring payments can be expensive.
The best recurring payment programs don't just optimize how they store cards.
They optimize how they preserve the data that follows those cards throughout their lifecycle.
That's often the difference between a successful recurring payments strategy and one that's constantly fighting declines, disputes, and involuntary churn.
Question: If you migrated to a new PSP tomorrow, would you only move the card—or would you move the history that helps future transactions get approved?