Visa vs Mastercard token provisioning speed, and why 82% of failures trace to one cause

Over three months, across a handful of customers with similar traffic and regional footprint, we analyzed network token provisioning across Visa and Mastercard, spanning gaming, hospitality, retail, and public transportation, all operating internationally. 4.63 million requests were provisioned successfully, timed, and grouped into buckets by how long they took. Over the same time period we analyzed the error messages received and ranked them from most to least frequent.

How fast is fast enough for provisioning?

It depends entirely on where provisioning sits in the transaction. Save a card to a wallet or file it for later, and provisioning happens in the background, well before the initial authorization, so it doesn't really matter how long that takes. Initialize authorization directly after checkout instead, and the token has to be ready right then, in the middle of the transaction, so every millisecond is now customer-facing.

It also depends on what else is happening around it. A single online payment rarely involves provisioning alone: 3D Secure checks, a fraud screen, and routing through an orchestrator to a PSP or acquirer can all sit in the same flow, each adding its own processing time before the authorization completes. Network token provisioning is one step in that chain, not the whole chain, so the same 500–1000 ms that feels negligible in isolation is still added on top of everything else running in the background.

Across the dataset, Mastercard averaged 1,051 ms per request and Visa 984 ms, both weighted from bucketed timing data rather than raw logs. Both networks put the median request in the same 500–1000 ms bucket. Whether that number matters depends on the flow it sits in, not on the number itself.

Visa responds faster in the early stages of processing

39% of Visa requests completed inside the first 500 ms, more than any single Mastercard bucket. Visa's distribution tapers step by step from there: 22% land in the next 500 ms band, and 19% in the 1000–1500 ms band.

Mastercard's early volume is flatter, and its slow tail runs deeper

Mastercard's first three bands are more evenly spread, 29%, 26%, and 32%, with no single fast band pulling ahead the way Visa's 39% does. In fact the largest sits in the 1000–1500 ms band, so its early volume leans slightly slower rather than clustering up front.

That evenness disappears at the extreme end: 2.4% of Mastercard requests ran past 5000 ms, more than three times Visa's 0.7% share in that range. Visa has more requests past the 2000 ms mark overall (10.8% vs. 7.3%), but they cluster in the moderately-slow zone rather than the truly slow one.

The numbers side by side

Understanding Tokenization Error Groups

Across all processed requests between May–July 2026, excluding errors originating from our own token-requestor configuration, which we control and correct directly, the responses returned during tokenization fall naturally into five categories.

Consolidating dozens of individual scheme messages into these buckets makes it far easier to see where volume concentrates and which problems are worth prioritizing. The table ranks the categories from most to least frequent, and the notes underneath describe the practical meaning behind each one.

‍

Each of these messages describes a request that didn't complete at all, independent of how fast or slow it would have been.

‍
What each group means

Ineligible or restricted card/token

The card or token simply isn't permitted for the requested action, whether because of scheme rules, applied limits or an account-level block. Responses such as "Unsupported token" and "PAN Ineligible" are counted together here. Dominating the dataset, this bucket is about eligibility and card status rather than anything going wrong technically.

Invalid data or failed verification

Something about the submitted information doesn't check out, either the values themselves are malformed or the parameter set needed to validate the card is missing pieces. Most of these can be resolved upstream by cleaning and confirming the input before the request ever reaches the network.

Issuer / network decline

Here the request was actively turned down by the cardholder's bank or by the scheme itself. In practice the accompanying guidance is usually to reach out to the issuing bank to clear the block.

Temporary issue / issuer unavailable

These responses reflect a passing condition: the issuer timed out or the card is momentarily unusable. The takeaway is that the situation is transient and a later retry stands a good chance of succeeding.

Technical error or duplicate request

This covers internal exceptions, unspecified processing failures and requests that duplicate one already in progress. As the rarest category, it captures the occasional technical hiccup or concurrency collision.

The picture is heavily skewed: more than four out of five failures come down to a single issue, cards or tokens that simply aren't eligible or are restricted. That's good news in a way, because it means efforts to reduce tokenization failures don't need to be dispersed. Concentrating on eligibility and card-status checks before a request is sent would address the overwhelming majority of cases.

The next tier: invalid data and issuer declines together account for most of the remainder and are also largely preventable through cleaner input validation and clearer issuer guidance. The truly technical failures, by contrast, are vanishingly rare (well under 0.1%), which suggests the pipeline itself is healthy.

In short, the biggest wins here aren't technical fixes at all; they lie in catching ineligible cards earlier and tightening the quality of the data that goes in.

Bottom line: neither network is simply "faster." They differ in where their slow requests sit, and that only matters depending on your flow. On the failure side, the story is refreshingly simple: fix eligibility checks and input quality up front, and you remove the overwhelming majority of failed provisionings.

‍