Token-based loyalty program

Tokenization has transformed mobile and online payments by allowing cardholders to pay without sharing their actual card numbers with merchants. When a cardholder adds a payment card to Apple Pay, for example, the phone stores a token called Device Account Number (DAN) in its Secure Element instead of storing the full card number. The DAN is issued by a token service provider (TSP), which securely maintains the link between the DAN and the card it represents. The benefit becomes clear if the device is lost or stolen. The cardholder’s full card number is not exposed because it is not stored on the device, and payments from that device can be suspended without cancelling the physical card. The token is also restricted to that device and used with a security code generated for each transaction, providing further protection against misuse.

During a payment, the merchant submits the token and transaction details through the existing payment system. The token allows the payment system to identify the correct card account, and the card issuer decides whether to approve the transaction. The response returns to the merchant through the usual channels, allowing the purchase to proceed without revealing the actual card number to the merchant.

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 an existing pseudonymous account reference, with registered payment identifiers providing a protected route to that account.

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 (US12125054B2 and US12749086B2), Australia (AU2019348201C1), and India (IN586118). The 2026 U.S. continuation, US12749086B2, extends the PoS-linked transaction-record workflow to contextual review forms tailored to the product or service and refined through reviewer choices. Related applications remain under examination 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, 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. At setup, Alice also designates a Customer Account Container (CAC) in customer-controlled storage for encrypted itemized records. PCX registers its delivery destination against her existing account.

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 encrypted 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 used by the platform’s protected resolver inside a Trusted Execution Environment (TEE).
4. ValiDeck keeps the token protected while registration is pending. It then notifies the issuer, which informs Alice that the token is available for registration.
5. Alice authorizes registration of the token to her existing account. Inside the TEE, the resolver establishes a protected lookup association with that account and its CAC delivery destination, then removes temporary readable token material.

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. This PCX-specific token flow requires participating payment institutions and agreed interfaces; Phase I simulates it.

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 protected token from the acquiring bank. The transaction record is linked with the protected token via an API call and transmitted to the platform.
5. The platform resolves the protected token to Alice’s pseudonymous account reference and delivers the encrypted customer record to her registered CAC 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 delivers the encrypted customer record to its registered CAC.

Ardus’s corresponding record remains under merchant control. The PCX Platform stores a separate synthetic record for permitted services, excluding customer identity, exact line-item details, exact prices, and exact timestamps. Restricted lookup associations are held separately, and the resolver retains no CTR copy after dispatch. Loyalty uses authorized transaction-derived representations; cross-merchant analytics uses synthetic records.

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, review-form, 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, a transaction-verified contextual review-form prototype, privacy controls, analytics based on synthetic records, and a reference connector for a target PoS environment. The review prototype will use authorized line-item attributes to select product- or service-specific questions and test refinement of future forms from reviewer choices. 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.