Token-based loyalty program

Tokenization has become a core security technique in mobile and online payments. When a payment card is provisioned to a wallet or stored with a participating merchant, the primary card number need not be exposed to that device or merchant for every transaction. Instead, a substitute payment credential called a token is used. A token service provider (TSP) or payment network manages the mapping and associated cryptographic controls. If the device or merchant environment is compromised, the token can be restricted or replaced without exposing the underlying card number in the same way. During payment, the tokenized credential is routed through the normal payment ecosystem and validated according to the rules of the network and issuer. After tokenization, the payment still follows the normal authorization path. The merchant or gateway submits the tokenized payment credential through the acquiring side and payment network to the issuer. The issuer applies its authorization checks and returns an approval or decline through the same chain. Tokenization changes the credential that is exposed; it does not replace the payment network’s authorization and settlement functions.

Payment-card tokenization developed over time as the payments industry sought to reduce exposure of primary card credentials. It’s use expanded substantially with mobile wallets and network-token services in the 2010s, making tokenization a mainstream security technique for digital card payments.

What is a loyalty program

A merchant loyalty program is a marketing strategy designed to encourage repeat purchasing through points, discounts, cashback, status, or other benefits. Loyalty programs can identify members through a loyalty number, app, email address, phone number, or a co-branded payment credential. Some co-branded cards are regulated payment products and require identity verification by the issuer; ordinary loyalty memberships may require much less information. In either case, the program needs a persistent member reference that can be linked to qualifying purchases so rewards can be calculated. The architectural question is therefore not whether every loyalty program uses the same identifier, but whether the merchant needs to hold a direct personal identifier in order to recognize a returning customer and award benefits.

In either model, the merchant needs a way to associate a purchase with a loyalty member. That association may use a loyalty number, app, email address, phone number, or a co-branded payment credential. The point-of-sale system then records the qualifying purchase against the member’s loyalty account so that rewards can be calculated. The implementation varies by program, but the common feature is a persistent identifier that links transactions over time.

Data protection issues in loyalty programs

Identity-linked loyalty programs create an additional store of customer information that must be protected. Depending on the program, the database may combine contact details, membership identifiers, purchase history, preferences, and redemption activity. The wider consumer-data ecosystem illustrates the potential cost of concentrating identity-linked records. Equifax suffered a major data breach in 2017 that exposed sensitive information belonging to a very large number of people. Public reporting has estimated that the breach cost Equifax over $1.7 billion. The architectural question for loyalty is therefore straightforward: how much of that identity needs to be present in the loyalty system at all?

What is a token-based loyalty program

Although payment-card tokens were developed primarily to reduce exposure of card credentials, the underlying technology can support other privacy-preserving workflows. The token-based loyalty program (US12125054B2) applies the same tokenization principle to loyalty: it is designed to let payment cardholders participate in multiple participating merchant programs without acquiring a separate loyalty card for each program or disclosing an email address or cellphone number to every merchant. Customers purchase goods and services from multiple vendors who compete with each other. If the customer acquires a loyalty card from each of these vendors, it creates problems for the customer as well as the vendor.

The first problem is privacy exposure: every additional identity-linked loyalty account creates another place where customer information must be governed and protected. The customer may also have to manage another card, account, or app. A second limitation is scope: a merchant loyalty program usually sees only activity within its own store or partner network. Broader demand patterns may be commercially useful, but exposing one customer’s detailed purchases at unrelated merchants would create a new privacy problem. The Privacy Compliant eXtensible protocol (PCX) separates the merchant’s own loyalty view from later cross-merchant analytics that can be computed from permitted synthetic or cohort-level records.

PCX solves the two problems in stages. Phase I, described in our product development strategy, is designed to validate the privacy-preserving token and record architecture through a controlled prototype using simulated multi-merchant transactions and a reference integration rather than live production data. Phase II then moves to live partner integrations, controlled pilots, and broader commercial services. The PCX architecture is designed to let customers accumulate transaction records under a pseudonymous account reference, filed against a token-derived identifier rather than a name.

PCX separates transaction capture from loyalty enrollment. A customer can accumulate transaction records from a participating merchant without joining that merchant’s loyalty program. Until the customer enrolls, those records remain associated with the customer’s private PCX account, do not contribute to that merchant’s rewards, and do not give the merchant a customer-linked view of those records. Enrollment is a separate, consented action that links the customer’s PCX account and the merchant’s PCX account for the bounded purpose of that merchant’s loyalty program. The table below illustrates the intended cross-merchant record history. In later controlled deployments, defined customer permissions and synthetic or cohort-level outputs can support broader analytics without giving a merchant unrestricted access to an individual customer’s unrelated purchases.

How token-based loyalty program works

Tokenization allows both merchants and customers to benefit from the security and reliability of the digital infrastructure supporting payment card tokens. The token-based loyalty program uses tokens to link a customer transaction record with the payment card used for the transaction. ValiDeck has filed patent protection for this technology in six jurisdictions: Canada, USA, Europe, India, China, and Australia. The invention is granted in the United States (US 12,125,054 B2), Australia (AU 2019348201 C1), and India (IN 586118). Prosecution continues in Canada, Europe, and China.

To illustrate the intended operating model, imagine a customer named Alice who wants to enroll in the Ardus merchant loyalty program. Ardus is a fictitious boutique design shop that sells home-use products such as bed sheets, table linen, curtains, and sofa upholstery. In this example, Ardus uses a PCX-enabled point-of-sale (PoS) integration that can transmit line-item transaction records pseudonymously to the PCX Platform. The sequence below describes the architecture; the Phase I prototype is intended to validate it in a controlled environment before live partner deployment.

Alice uses the following sequence to enroll in the Ardus loyalty program and earn rewards under the PCX design.

1. Creating a PCX account

1. Alice initiates account creation on her phone via the ValiDeck app. The phone generates a public/private key pair locally. The private key remains on the device, while the public key is prepared for attestation.
2. The phone sends the public key to her payment card issuer and requests attestation. No customer identifier is shared with ValiDeck at this step.
3. The issuer attests the public key against the customer record it already holds and returns the attested key to the phone. The issuer carries its verification forward as an attestation on the key, rather than sharing the underlying identity data.
4. The phone submits the attested key to ValiDeck and proves possession of the matching private key. No email address, phone number, or payment card detail reaches the platform at this step.
5. ValiDeck creates the pseudonymous customer account and confirms that payment cards can now be registered into it. From this point onward, the Alice accesses the account using the private key held on her phone.

Account creation happens once. The card-registration steps that follow assume an account and pseudonymous identifier already exist.

2. Registering a payment token

1. Alice requests her payment card issuer to tokenize her payment card.
2. The card issuing bank tokenizes the payment card and encrypts the token with the platform’s public key. The token is then stored in the issuer database as a Key:Value pair with the matching card number.
3. The card issuing bank sends the encrypted token to ValiDeck. The tokens can be decrypted only via the matching private key available on the platform.
4. ValiDeck decrypts the token and stores it in a queue. It then notifies the issuer, which informs Alice that the token is available for registration.
5. Alice registers the token into her personal account on the platform.

Registration happens once per card. The card number never leaves the issuer; only an encrypted token reaches the PCX Platform.

3. Joining the Ardus loyalty program

Alice signs up for the Ardus loyalty program through Ardus’s portal. Ardus has already created its merchant account on the PCX Platform, and Alice’s PCX account was created in Step 1. When Alice consents to join the program, PCX links the two accounts for the bounded purpose of the Ardus loyalty relationship. Alice does not need an Ardus-specific loyalty card or need to provide Ardus with an email address or telephone number, because the identity basis for her PCX account was established once through her attested public key.

If Alice buys from Ardus without joining its loyalty program, PCX can still associate those transaction records with Alice’s own pseudonymous account. The purchases do not accumulate toward Ardus rewards, and Ardus does not learn that those records are connected to Alice’s PCX account. After enrollment, qualifying Ardus transactions can contribute to rewards, and Ardus can recognize Alice’s purchasing behavior within its own program while her underlying identity and unrelated transaction records remain protected.

4. Linking qualifying transactions

The following sequence illustrates the operating model protected by the foundation patent and used as the basis for the Phase I reference implementation.

1. After joining the Ardus loyalty program, Alice purchases some products at Ardus and initiates a payment at the store.
2. The Ardus point of sale (PoS) requests their acquiring bank to authorize the transaction and share the token number linked to the card. The acquiring bank forwards this request to the payment network, which subsequently passes it to the payment card issuer.
3. The card issuer applies its normal authorization checks and returns the authorization response together with the linked token through the payment network and acquiring side. The token intended for PCX is protected so that only the platform can resolve it.
4. The Ardus PoS receives the transaction authorization and the token number from the acquiring bank. The transaction record is linked with the token number via an API call and transmitted to the platform.
5. The platform resolves the protected token to Alice’s pseudonymous account reference and stores the transaction record under that reference without requiring Alice’s direct identity.

A transaction record can reach the platform in two ways — via a tokenized card, or sans any card. Both converge on the same step: the platform resolves the customer account and appends the record to it.

5. Earning rewards

Because Alice has joined the Ardus loyalty program, reward logic can now operate against the bounded, pseudonymous loyalty relationship between Alice’s PCX account and Ardus’s merchant account. Ardus can award rewards for qualifying purchases and understand Alice’s purchasing behavior within its own program so it can provide more relevant offers, without receiving her name, email address, telephone number, or access to her transactions with other merchants. Phase I will test the underlying token, record, loyalty, and multi-merchant analytics flows with simulated transactions and a reference integration. Phase II will move to live partner integrations and controlled pilots, including broader reward and analytics services where the required permissions and record decomposition are in place.

What phase I delivers, and what comes in phase II

Phase I builds and validates the core reference implementation: attested-key and pseudonym logic, simulated token issuance, a multi-merchant PoS simulator, line-item CTR ingestion, loyalty processing, privacy controls, analytics, and a reference connector for a target PoS environment. The Phase I outcome is an independently reviewable prototype, not a live production rollout using commercial customer data.

Phase II commercializes and expands that foundation through live partner integrations, controlled pilots, and broader loyalty, review, search, and analytics services. Cross-merchant or sponsor-blind rewards can be computed from synthetic or aggregated records so that a sponsor does not need to see or single out the customer. Patents protecting the core token pipeline have been granted in the United States, Australia, and India; newer privacy-preserving record architectures are the subject of applications filed in the United States and Europe in 2026 and remain pending.

Benefits of the token-based loyalty program

The token-based loyalty program is intended as a reference application of PCX: privacy-first data infrastructure connecting customers, merchants, payment participants, and oversight functions under defined roles and permissions.

For customers, it removes the need to create a new identity profile, acquire a merchant-specific loyalty card, or share personal contact details each time a customer joins a participating merchant’s loyalty program. The customer still chooses and consents to each merchant relationship, but the underlying PCX account is created only once. A pseudonymous ValiDeck ID is designed to support participation across multiple programs while keeping disclosure under defined customer permissions. The architecture is intended to support compliance with applicable data-protection requirements, including GDPR obligations where relevant.

For merchants, it is designed to provide an interoperable loyalty framework that can integrate with existing payment and PoS environments. Once a customer joins the merchant’s loyalty program, the merchant can recognize that pseudonymous customer’s qualifying activity within its own program, award rewards, and use that derived bounded information to make offers more relevant. Permitted cohort-level insights can also help merchants refine products, pricing, and supply-chain operations without requiring access to direct customer identifiers or unrelated customer-level transaction histories.

For payment participants, the architecture creates potential roles in token services, attestation, standardized interfaces, and privacy-preserving analytics. Any commercial benefit would depend on adoption, integration economics, and the applicable regulatory model.

For regulators and supervisory bodies, the proposed Governance Layer is intended to support jurisdiction-specific oversight while preserving interoperability among participating implementations. Each authorized authority would exercise the oversight available under its legal mandate, supported by standardized audit evidence and configurable jurisdictional rules. The objective is to improve accountability and cross-border compatibility without creating a single unrestricted view of customer activity.

Collectively, the model treats loyalty as one application of shared privacy-first infrastructure rather than as another identity-collection silo.