Payment tokenization for agents, in depth: network tokens, cryptograms and credentials bound to AP2 mandates

Three kinds of token

"Token" means three different things in agent payments, and mixing them up causes design errors.

A PSP token is a database key into your processor's vault. It removes card data from your systems but the processor still sends the real card number to the network. A network token goes further: it is a surrogate number from a dedicated range that the network itself understands, so the card number stays inside the network and issuer. The mandate-scoped credential is the agent-specific layer: whatever the underlying instrument, the credential the agent presents is valid only for the purchase a signed mandate describes. Visa Intelligent Commerce and Mastercard Agent Pay, both announced in April 2025, are the networks' own programs for agent credentials, built on network tokenization.

How network tokens work

Network tokenization is defined by the EMVCo Payment Tokenisation framework. Its parts:

• Token requestor. The party that asks for tokens: a wallet, a merchant, a processor or an agent platform's credential provider. It is registered with the network and identified by a token requestor ID that travels with each token.
• Token service provider (TSP). Usually run by the network. It verifies the card with the issuer before issuing (identification and verification, sometimes with a one-time passcode), mints the token and records the mapping.
• Token vault. The only store that maps token to card number, protected by keys in hardware security modules inside the network's own cardholder-data environment.
• Domain restriction controls. Rules attached to each token: which requestor, which channel, sometimes which merchant. A token presented outside its domain is declined at the network.
• Cryptogram. A value generated per transaction from key material bound to the token. The network validates it during authorization, so the token number alone is not enough to pay; a captured cryptogram cannot be replayed.
• Lifecycle. When an issuer reissues a card after expiry or loss, it updates the vault and the token keeps working. Suspending or deleting one token leaves the card and its other tokens intact.

There is also a Payment Account Reference, an identifier that links all tokens and the card number for one account without revealing the card number, so fraud and loyalty systems can recognise the same account across tokens. For an agent platform the key property is blast-radius control: a stolen card number works everywhere and its reissue breaks every stored credential, while a stolen token fails outside its domain and can be killed alone.

Where AP2 attaches the credential

AP2 is an open protocol, started by Google with payments partners in September 2025, for proving that an agent is authorized to pay. Its vocabulary has moved between releases. The first release described intent, cart and payment mandates. The current specification at ap2-protocol.org defines a Checkout Mandate and a Payment Mandate, each of which can be open, carrying constraints the user approved, or closed, describing one exact transaction and signed by the agent's key, whose public key the open mandate names in a cnf claim. The Payment Mandate exists in both versions and is where tokenization attaches.

The roles are the shopping agent, the merchant, the merchant payment processor, a trusted surface where the user gives consent, and the credential provider, which holds the user's payment instruments. The rules that matter here: the credential provider, and the network if it takes part, must receive and verify a Payment Mandate before returning a payment credential, and must check that a closed mandate satisfies every constraint of the open one. The closed Payment Mandate carries a checkout_hash that binds it to one specific checkout, and the merchant's processor must verify the credential is scoped to that checkout. One way the spec suggests doing that is to embed the closed Payment Mandate inside the credential itself.

Put together, the credential provider acts as the token requestor. The agent never holds a card number and often not even the token number; it holds a reference and the mandates, and receives a credential only after the provider has checked the signatures and constraints.

Worked example: a capped standing purchase

Take a concrete purchase. A shop owner lets an office-supplies agent restock the shop, up to $120 a month and only from merchants in the office-supplies category.

1. Enrollment. The owner adds a card in the credential provider's app. The provider, as token requestor, asks the network TSP for a token; the issuer verifies her, and the vault mints a token restricted to the provider's requestor ID and the e-commerce channel. The provider stores the token reference; the card number is now held only by the issuer and the vault.
2. Standing authorization. On the trusted surface the owner approves an open mandate: category office supplies, $120 per calendar month, expiry in twelve months, naming the agent's public key.
3. Checkout. The agent builds a $86.40 cart at a merchant, receives the merchant's checkout, and signs a closed Checkout Mandate and a closed Payment Mandate whose checkout_hash matches it.
4. Credential. The provider verifies both signatures, confirms the agent key matches the cnf in the open mandate, checks the merchant category and that $86.40 plus this month's prior spend stays under $120, then asks the TSP for a cryptogram for this amount and merchant.
5. Authorization. The merchant verifies the checkout hash, its processor verifies the credential's scope and submits token plus cryptogram. The network validates the cryptogram and domain, swaps in the card number and forwards to the issuer, which can see that an agent initiated the purchase under a user-approved mandate.

Later the same month the agent tries a $50 order. The provider refuses before any network call: $86.40 plus $50 exceeds the cap. Next quarter the card is reissued after a breach elsewhere; the issuer updates the vault and the mandate keeps working without re-enrollment.

The credential provider's issue path

The credential provider's issue path is where the guarantees are enforced. The sketch below is illustrative Python: the verifier, ledger and TSP client stand for your own components and your network's real API, which this article does not reproduce.

def issue_credential(open_pm, closed_pm, checkout):
    # 1. Signatures: user signed the open mandate, agent signed the closed one.
    verify_user_signature(open_pm)
    if closed_pm.signer_key != open_pm.cnf_key:
        raise Denied("closed mandate not signed by the authorized agent")
    verify_signature(closed_pm, closed_pm.signer_key)

    # 2. Binding: the closed mandate must describe exactly this checkout.
    if closed_pm.checkout_hash != sha256(canonical(checkout)):
        raise Denied("checkout_hash mismatch")

    # 3. Constraints from the open mandate, checked against server-side state.
    c = open_pm.constraints
    if now() > c.expires_at or open_pm.id in revoked_mandates():
        raise Denied("mandate expired or revoked")
    if checkout.merchant_category not in c.categories:
        raise Denied("merchant outside mandate scope")
    with ledger.lock(open_pm.id):                      # serialize concurrent purchases
        spent = ledger.spent_this_period(open_pm.id)
        if spent + checkout.total > c.period_cap:
            raise Denied("period cap exceeded")
        # 4. Network: cryptogram bound to amount and merchant, idempotent on checkout id.
        crypto = tsp.request_cryptogram(token_ref=open_pm.instrument_ref,
                                        amount=checkout.total,
                                        merchant_id=checkout.merchant_id,
                                        idempotency_key=checkout.id)
        ledger.reserve(open_pm.id, checkout.id, checkout.total)
    return ScopedCredential(token=crypto.token, cryptogram=crypto.value,
                            payment_mandate=closed_pm)     # closed mandate travels inside

Note the lock around the cap check and the reservation: two parallel agent tasks must not both pass a $120 cap with $100 orders. Reserve on issue, release when the authorization fails or expires, and settle on capture. Retries reuse the checkout id so a network timeout does not produce two charges; see idempotency for agent payments.

Lifecycle: keeping tokens and mandates in step

Map mandate state and token state explicitly, because each side can change the other.

Revocation should take effect at the credential provider first, because that check runs before any network call. Token suspension is the second layer, for credentials already issued. Keep the open and closed mandates and the issued credential's identifiers with the order: they are your evidence if the purchase is disputed.

Failure modes

Operations, compliance and trade-offs

Track provisioning success rate by issuer, authorization approval rate for tokenized versus other transactions, decline reasons (domain, cryptogram, issuer risk), the delay between a lifecycle notification and your state change, and credential issuance denials by reason. A spike in cap denials can mean a looping agent; a spike in cryptogram failures usually means a retry path is reusing old values.

On compliance: a system that never stores, processes or transmits card numbers can fall outside much of PCI DSS scope, but tokenization does not remove scope by itself; the scoping decision belongs to your assessor. PCI scope reduction covers the boundary design. Trade-offs: network tokens need per-network integration and issuer support, which varies; single-use virtual card numbers work everywhere cards do but carry less agent context; PSP tokens are simplest but lock you to one processor. Many platforms combine them. Liability rules for agent purchases are still settling, so read 3-D Secure and liability shift before assuming who pays for fraud.

What to do next

Use this list to plan or audit an agent payment integration:

1. Prove no card number reaches the agent runtime: grep prompts, transcripts and traces for card-number patterns.
2. Make the credential provider the token requestor and record the token reference, never the number.
3. Verify signatures, the agent key against cnf, the checkout_hash and every constraint before requesting a cryptogram.
4. Serialize cap checks per mandate and reserve on issue.
5. Use the checkout id as the idempotency key for every network call.
6. Wire issuer lifecycle notifications to mandate state and alert on lag.
7. Remove any fallback to raw card data.
8. Confirm which AP2 version your partners implement, since mandate names changed between releases.