Replacing Customer Identity with a Token on every Transaction Record
The pipeline
PCX links each transaction record to a pseudonym rather than to the person behind it, at the moment the record is created. The pipeline behind this transformation is the chain that carries each record from the point of sale into an account the customer controls on the PCX server platform, without exposing the customer’s identity along the way. A single purchase travels the chain twice. The request runs down the chain: Merchant → Acquiring Bank → Payment Network → Card Issuer to authorize the payment and retrieve the token linked to the card. The response runs back up, and one step further: Card Issuer → Payment Network → Acquiring Bank → Merchant → Server Platform carrying the authorization and the encrypted token so the platform can record the transaction against the customer’s account. Every capability named in the Concept page (loyalty, analytics, and search) runs on the records this pipeline produces. Tokenization, described next, is one component of it: the key that lets a record travel the chain and land in the right account while the customer’s identity stays decoupled from it.
Tokenization — the pipeline’s key
Tokenization is the process of converting meaningful data, such as the payment card number, into a random string of characters called a token that has no value if breached. Tokens reference the original data, but cannot be used to extract the information behind the token. They are widely used in the payment card industry to protect the primary account number (PAN) of cardholders from hacking or unauthorized use. Both Apple Pay and Google Pay use tokens to facilitate contactless (NFC) payment via mobile devices.
PCX repurposes this established mechanism for a different end: instead of protecting the card during payment, it uses the token as the durable, identity-decoupled key that links a customer’s purchases to an account they control, across merchants, without any merchant learning who they are.
Registering tokenized cards on ValiDeck
ValiDeck account holders request their payment card issuers to tokenize their payment card.
ValiDeck partner banks and card issuers tokenize payment cards issued by them and encrypt the token with the ValiDeck public key. The token is stored in the issuer database as a Key : Value pair with the matching card number.
Payment card issuers send the encrypted token to ValiDeck. The tokens can be decrypted only via the matching private key available at the ValiDeck platform.
ValiDeck decrypts the token and stores it in a queue. It then sends a notification of this to the issuer, which notifies the customer that the token is available for registration.
The customer registers the token into its account on the ValiDeck platform.
Registration happens once per card. The card number never leaves the issuer; only an encrypted token reaches the platform.
Recording tokenized card transactions
ValiDeck account holders are able to capture their transaction records/invoices online into their account. To save the transaction record into their account, they use their payment card like any ordinary person. The card can be tapped, swiped, or inserted into a payment cube.
ValiDeck partner businesses and service providers request their acquiring bank for an authorization of the transaction and 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.
Payment card issuers look up the customer account balance and authorize the transaction. The authorization is sent along with the linked token number to the payment network which forwards it to the acquiring bank. The token number is encrypted with the ValiDeck public key.
ValiDeck partner businesses and service providers receive 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 ValiDeck platform.
The ValiDeck system decrypts the token number and looks up the customer account containing the token number. Once the customer account is found, the transaction record is written into the ValiDeck database and linked to the customer account number.
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.
Recording non-card transactions
Not every transaction runs through a payment card reader. A customer’s app can present its platform account identifier directly (as a QR code, barcode, or NFC credential) which the PoS reads; or the PoS can print the transaction record as a QR code that the customer scans with the app. Either way, the platform receives the account identifier and the record, and appends the record to the same account. The underlying payment can be settled by cash, check, or e-transfer. The payment rail is independent of the capture. What links the record to the account is the account identifier the customer presents, exactly as the token does on the card path.
This second path is a deliberately claimed capability, not a side effect: it lets a customer build a complete, cross-merchant purchase history regardless of how they pay, and join a merchant’s loyalty program without surrendering identifying information.
What each party can see
In the capture pipeline as granted, every party in the system sees only what it holds by design, and no party but the customer holds enough to reconstruct the whole.
- The merchant sees the customer’s transactions within its own store and partner network, and uses them to compute loyalty credits. Anything beyond that (what the customer buys elsewhere) requires the customer’s consent.
- The bank or issuer knows that the customer spent, across market segments, but not what was bought: the transaction records are never shared with the bank.
- The PCX server platform holds the transaction detail against a token, but not the person behind the token: the bank is not required to reveal identity to the platform.
- The customer is the only party with the full picture, and the only one who can connect their records to their own identity. They can share their records with any party without revealing who they are.
This is why a purchase cannot be traced back to a named person by any single party. Reconnecting the two takes both halves, the platform’s transaction records and the bank’s identity records, which is why, in practice, it requires a court order compelling both.
Beyond capture — rewards without exposure
The capture pipeline described above is the granted foundation. New applications filed in the US and Europe in 2026 describe an architecture that goes further. Each record exists in three variants. The merchant holds a copy that contains the transaction details without any customer information. The customer holds a copy, encrypted with the customer’s public key. The platform holds a synthetic copy that is useful for analysis but cannot be traced back to the original transaction. Only the customer copy is complete and attributable.
The synthetic copy is what makes cross-merchant rewards possible. A brand can define a rewards policy that the platform applies across unaffiliated stores, and the brand receives only scoped eligibility indicators, never the underlying records or the person behind them. These applications are pending; their mechanism is set out in the filings and is not detailed here.