“Hey Mike, welcome back, can I get you your usual?” Most online businesses struggle to recreate that kind of familiarity you'd get from the owner of your local bar. Recognizing a returning customer is a pretty hard problem, but the upside of being able to do it is significant. Firstly, you can give a customer you like a genuinely great experience, and keep known bad actors out of your system.

The trouble is, there's not much to work with. A name can be typed differently each time. An email can change, or simply not be collected at guest checkout. A phone number might not be asked for at all.

Companies have always had to make do with a short list of imperfect, self-reported identifiers. Payment details have long been one of the few reliable ones, since at least the card number stays the same from one purchase to the next.

Except it increasingly doesn't. Network tokens, whether Merchant-Initiated Primary Account Number (MPAN) or Device-Initiated Primary Account Number (DPAN) as used by Apple Pay and Google Pay, now mean one card can appear as multiple different, unrelated credentials. The one identifier you could count on staying consistent has become just as fragmented as the rest.

One way you could solve it is by prediction. If you can't rely on a single stable identifier, you build a model that predicts whether two transactions probably came from the same person, using a range of data points: card number, email address, IP address, device ID, timing, spend pattern. Enough of these lining up starts to look like good evidence.

This can and does work to some extent. But you need to throw data science resources at the problem, which is quite a big ask.

An identifier you've probably never used, but is quietly becoming essential

There's a field that solves this more directly. It's called the Payment Account Reference, or PAR, and it's been steadily getting more useful as the number of ways to represent a single card has grown.

A PAR is an identifier tied to the underlying card account, not to any particular representation of that card. It's 29 characters, it can't be reverse-engineered back into a Primary Account Number (PAN), and it doesn't change even when the thing representing the card does. Whether the original card is reissued, the merchant creates a network token, or an Apple Pay token is generated, the PAR stays the same, because all of them trace back to one card at one issuer.

EMVCo introduced PAR in 2016, as an industry-wide fix for a problem tokenization itself was creating: the more the payments world moved toward tokenizing cards for good security reasons, the more merchants and processors lost the one thing they'd always used to recognize a returning card, the PAN itself. PAR was built to survive exactly what tokenization was designed to hide.

One of the clearest illustrations of why an identifier like this was needed comes from Transport for London (TFL). TFL is a contactless payment system where travelers tap in and out, with fares capped up to a certain amount each day irrespective of how much you travel. In this system, a traveler might tap a physical contactless card in the morning, which is logged as a PAN, and in the evening, use the same card via Google Pay on the way home, which generates a DPAN. Same person, same card, two credentials. It's a simple requirement and fundamental to fare capping, but a genuinely hard problem to solve without something like PAR.

[Image source: BBC]

The three use-cases where PAR adds a lot of value

Fraud: promo abuse and blocklist evasion

New-customer promotions and blocklists both rely on the same assumption, that a person will keep showing up with the same identifiers. Most opportunistic abusers will reuse the same email or physical address, so are easy to catch. Slightly more advanced people will mask their IP or device. And now they can do so with the underlying card too, using Apple Pay and Google Pay reprovisioning.

If a user deletes and re-adds a card to their digital wallet, a new DPAN is generated each time, even if it’s the same underlying card. This takes a user around 30 seconds and means that, to a merchant, it's a brand-new card credential belonging to a brand-new customer.

A PAR lookup will return the same PAR no matter how many times a new DPAN is created by Apple Pay or Google Pay reprovisioning. Completely blocking this attack vector that had previously been an unsolvable and expensive blind spot.

A single view of the customer, especially for loyalty

Rewarding customer loyalty often means your customer has to download and pay via your app, or scan a physical loyalty card. PAR can enable card-linked loyalty instead: pay with the same card, and be recognized without needing a separate app or loyalty credential.

Lifetime value calculations are other big winners of using PAR, especially across in-store and online payments. Multiple card credentials for the same card can break attempts to build a single customer profile. PAR helps you avoid that.

Payouts

Businesses in iGaming and money transfer are often required, as an anti-money-laundering control, to return a withdrawal to the same payment method a deposit came in on. That's simple when the two credentials match, but breaks down the moment someone deposits via a wallet and later withdraws to a manually entered card, or vice versa. A PAR lookup confirms both trace back to the same account even when the form has changed, replacing what would otherwise be a manual review with an instant check.

Getting your hands on PARs

What PAR ultimately offers is the difference between a payment record that just says "another Visa card ending in 1234" and one that can say "this customer, again," without ever needing to know who that customer actually is. It's a small, unglamorous field, but it may be the closest thing payments has to duct tape holding a consistent identity together across an increasingly fragmented set of ways to pay. The challenge is accessing the PAR, and it depends on which credential you're working with.

If a user enters card details manually, you wouldn’t receive the PAR. A PSP will occasionally return it post-authorization, but by then it's too late, since most use cases depend on knowing the PAR before you authorize.

MPANs are the exception. PAR is returned as part of generating the token, and that happens pre-authorization, so if you're already using merchant-initiated network tokens, you get PAR for free. This is what you get with Evervault Network Tokens.

DPANs are different. Apple Pay and Google Pay will share the DPAN itself during processing, but never the PAR, so there's no path to it through the wallet at any point.

That's the gap Evervault’s PAR Lookups closes. It's a standalone lookup, so instead of depending on what a PSP or wallet happens to share, you can resolve the PAR for a PAN, DPAN, or MPAN directly, whenever you need it in the transaction lifecycle. That's what makes the fraud, loyalty, and payout use cases above work across all three credential types.