Your Payment Vault Is the Best CRM You Own. You Just Don't Know It Yet.‍

When we bought our condo a few years ago, like everyone else who buys a home, we got insurance. Nothing fancy, just enough to cover us if we got flooded or someone stole all our records. It’s a simple monthly fee that just gets paid directly from my credit card. Easy. 

Then last year my bank flagged some suspicious activity on my card and issued me a new one. I spent a grim week updating my payment methods in a bunch of accounts but somewhere along the way, I just completely gapped out on the insurance. 

A few days later I got a short email saying my payment details had been refreshed and I was still covered, not to worry about it, everything is good. Goodness gracious, what a relief. 

I really love this kind of thing, these benefits that come with the modern world, stuff that happens behind the scenes that we would never even stop to think about the method behind it and just carry on feeling satisfied about doing business with a company that seems to care just a little bit. It’s rare, isn’t it? And it got me wondering about how that kind of thing could actually happen. 

I talked to five or six of the people who work in payments here, people who are deeply entrenched in this stuff, and one concept kept coming up: Payment Account References, or PAR. It turns out PAR is a big part of what made that insurance experience possible, and there's a good chance it's already sitting inside your vault doing nothing.

So let's get into what PAR actually is and how you can put it to work. 

What is PAR?

As much as I love golf, I’m sorry to say that, in this particular instance, PAR has nothing to do with hitting little white balls with sticks. 

A Payment Account Reference, or PAR, is a 29-character identifier assigned by the card networks to a cardholder's underlying payment account. 

It was introduced by EMVCo to solve a specific problem: the inability to connect transactions made on the same card across different channels without touching the card number itself, which is sensitive, changes when a card is reissued, and drags PCI scope in like a golden retriever that found a tennis ball in the bushes.

Unlike a card number, PAR is tied to the underlying account rather than the physical card, so it survives replacements, reissuances, billing updates, and situations like mine where a customer gets a new number because their old one turned up in a breach. 

PAR functions like a persistent customer ID that the card network issues and maintains, requiring nothing from your marketing infrastructure to stay alive. It simply follows the account. For customers who have stored a payment method with you, PAR is a more stable identifier than their email address, their device ID, or their login session, any of which can disappear without warning.

EMVCo designed this specifically so payment data could be used for cross-channel reconciliation without requiring access to sensitive card information. That's what the standard was built for.

How PAR compares to the identifiers your data team is already using

Customer identity infrastructure typically runs on a stack of four identifiers, and every one of them has a durability problem.

We’ve all changed our email address at some point in the past. Customers abandon them, use different ones for different services, or go through a personal rebranding somewhere around age 34 when they finally retire the Hotmail account they've had since middle school.

Device IDs rotate with operating system updates, app reinstalls, and new device purchases. Apple's App Tracking Transparency framework has reduced their utility for cross-app identity further, and there's no obvious reason to expect that to change any time soon..

Cookie-based cross-site tracking is already broken for a significant chunk of your audience. Safari and Firefox have blocked third-party cookies by default since 2020, and while Google reversed its Chrome deprecation plans in 2024, the direction of travel is clear enough that building a long-term identity strategy on cookies requires a particular kind of institutional optimism, like buying a nice umbrella and hoping it never rains.

Login sessions are accurate when they exist, but a lot of e-commerce and subscription transactions don't require a logged-in state. A returning customer buying through a saved card may never authenticate a session at all.

PAR isn't affected by any of the above because it was never tied to any of those identifiers in the first place. It's assigned to the payment account by the card network, and it stays with that account regardless of what device a customer is using, what email address they're on, or how long it's been since they logged in. 

The only thing that can change a customer's PAR value is the card network itself, and that's not something that happens from the customer's side. For the segment of your customer base that has stored a payment method with you, PAR gives you a thread that runs through the whole relationship. W. Capra confirms PAR can connect a customer's payment history across accounts without requiring any additional input from them.

Why the first-party data industry hasn't solved this

Customer Data Platforms (CDPs) and identity resolution platforms are built to unify data from systems designed to track behavior: web analytics, email, CRM records, app activity. And they do that very well.. The problem is that payment systems were built to process transactions, and the two systems just don’t talk to each other..

CDPs can ingest transaction data, but only as accurately as the identifiers underneath it. If the email address changed, the device is new, and the customer hasn't logged in for a year, the purchase history fragments across multiple records. The relationship exists, the CDP just can't see it as one.

The ROI problem with personalization investment isn't really a tools problem. Behavioral data collected from unstable identifiers just doesn't hold together over time. Customer histories fragment, LTV models undercount relationships that have been running for years, and loyalty attribution gets noisy enough that the data stops telling you anything useful. The identifier that would anchor all of it is already in your system, assigned by the card network, just sitting there, waiting for yout to use it.

What you can actually do with PAR once you have access to it

PAR is useful in four specific ways, and each one maps to something your data team is probably already working on.

Cross-channel recognition without PII. A customer buys in-store with a physical card, then comes back online using Apple Pay, then completes a purchase through your mobile app with a saved card. Under most identity architectures, those are three separate records. With PAR, they resolve to one underlying account without requiring an email address, a login, or any personally identifiable information. The U.S. Payments Forum confirms PAR can identify whether a transaction originates from an existing customer without any other inputs. The customer is recognized across the full journey.

Loyalty attribution that doesn't depend on card presentation. Loyalty programs break down when a customer makes a purchase without presenting their membership card or logging in. PAR ties the transaction to the underlying card account, which can then be matched to the loyalty membership. Purchases that would otherwise go unattributed become visible and rewardable without requiring the customer to do anything differently.

Fraud detection that follows the account. A fraudster who keeps getting new cards to sidestep a block generates a new card number each time, but the same PAR value. Behavioral patterns spanning multiple card numbers become visible when you can connect activity to the underlying account. It's like realizing the person leaving footprints all over your garden is the same person regardless of how many times they change their shoes.

LTV calculations that survive card churn. A customer with a five-year relationship whose card has been replaced twice looks like two or three different people under a PAN-based data model. Under a PAR-based model, the history is continuous and the LTV calculation reflects the real relationship rather than a series of strangers who happen to share a shipping address.

Subscription businesses have a particularly clean use case here. A subscriber whose card has been replaced, whose email has changed, and whose device is new is still the same PAR value they were on day one. The subscription identity holds together even when everything else about the account has shifted, and payment tokenization is the infrastructure layer that makes it possible.

The structural problem: you can only access PAR if you own the vault

All of the above is only accessible to you if you control your token storage layer. That's the catch, and it's worth sitting with for a second.

To query PAR values, you need either PCI Level 1 compliance or a third-party tokenization platform that can make those queries on your behalf. If your payment tokens live inside a processor-owned vault, you're dependent on that processor to surface PAR data to you, through their APIs, on their terms, with their limitations. Basis Theory has documented this constraint directly: without an independent vault, PAR access is gated behind your processor's willingness to expose it.

When you own the token storage layer, you control the PAR lookup, the data model, and how PAR values connect to your CRM, your analytics platform, and your loyalty infrastructure. Your marketing and data teams get keys to a database they didn't know existed and Bob is your proverbial uncle. 

PAR is also generally treated as personal data within the payments industry, and some use cases, especially those involving cross-merchant profiling or marketing activation, may require cardholder consent depending on jurisdiction. 

Managing that consent requires visibility into which customers have stored payment methods, under what terms, and where. That visibility is only practical when you own the token storage layer. When the data sits inside a processor's vault, consent management across it becomes operationally messy and commercially constrained.

How to make the case across your organization

The payments team pitch for vault independence has always been about routing flexibility and avoiding processor lock-in. Those are real arguments. They might not ring true with a CDO who's trying to solve a customer identity problem and has never had a reason to think about network tokenization or what happens to stored credentials when you switch processors.

Lead with the identity problem instead. Your payment vault is the only system in your stack that contains a durable, non-sensitive, network-issued identifier that follows your highest-value customers across every channel and every card they'll ever use. 

If that identifier lives inside a processor's vault, you can't use it for anything beyond processing payments. If it lives in an independent vault you control, it becomes the anchor of your first-party identity strategy. That's a customer data argument, and it tends to get a different room interested more than "we should own our tokens."

Start with a concrete use case. Loyalty attribution or LTV modeling are both good candidates. Show what the analysis looks like with and without PAR-based identity resolution. The delta in model accuracy is usually enough to make vault ownership a shared priority rather than a payments-team-only request.

Every stored payment method is already a potential PAR value

Every customer who saved a payment method in your vault is already generating the most stable customer identity signal you have access to. Companies investing heavily in CDPs and identity resolution tooling while leaving their vault inside a processor-owned system are solving the visible half of the problem and ignoring the part that would make the rest of it work. It's a bit like spending a fortune restoring a classic car and leaving the engine out.

Owning your vault doesn't require starting over. You just need to get a handle on what you currently have access to and what you're giving up by leaving token storage inside a processor's infrastructure. The teams that do that audit find the answer changes how they think about the payments roadmap, who needs to be involved, and what it's actually worth to own.