# How an agent pays without seeing your card

Tokenised and delegated payment: Stripe Shared Payment Tokens, ACP’s delegated payment, what Adyen’s and PayPal’s documents describe, Visa’s Trusted Agent Protocol and AP2’s mandates.

By Valerii Checha, 20 Oct 2026

An AI shopping agent that places an order also has to pay for it, with a card that belongs to the shopper. Stripe, ACP and Adyen document flows in which a token, not the card number, travels from the agent to the store. Visa's Trusted Agent Protocol lets a store check a signature on the agent's requests. The Agent Payments Protocol (AP2) uses signed records of what the user approved. This article goes through what each of those documents says, who handles the card details in four of the flows, what a store owner can ask their payment provider, and what the documents leave open.

Paying is the fifth wall in [the hub article](https://storewalk.ai/blog/why-agents-cant-buy). The step before it, getting through checkout, is the subject of [Why agents stall at checkout](https://storewalk.ai/blog/why-agents-stall-at-checkout), and [ACP explained](https://storewalk.ai/blog/acp-explained) goes further into the ACP endpoint used here.

Where we explain a term in plain words, the explanation is ours, not any specification's. Everything else comes from the documents linked in the text and listed under sources.

## Card numbers, tokens and delegation

A payment service provider (PSP) is the company that processes a store's card payments. ACP's draft [Payment Handlers RFC](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.payment_handlers.md) describes it as a "Service processing payment transactions (e.g., Stripe, Adyen)". PCI DSS is the card industry's security standard for systems that handle card numbers.

The same draft gives a reason to avoid passing card data: "Handlers SHOULD leverage tokenization to avoid passing PCI-sensitive data." Adyen requires an agent platform that sends it card numbers to "meet PCI DSS Level 1 compliance". AP2's specification warns that when a role in the payment is agentic, which we read as run by a language model, "the Agent itself is a potential attacker."

A token, in our words, is a stand-in value that a PSP accepts in place of the card details. Tokenisation is the act of swapping the card details for one. A network token is a substitute card number issued through the card network; ACP's released file defines its field as "Whether the number is a raw card number (fpan) or a network token". A vault token is ACP's name for what its delegated payment endpoint returns. Delegated payment, as we read ACP, means the card is handed to a PSP together with limits, and what comes back is a token that works only within them.

The title names what these designs aim for, and who touches the card on the way differs by document. In Adyen's ACP flow the shopper enters their payment details in the agent platform, which sends the card number or network token to Adyen. ACP's draft has the agent send the card to `delegate_payment` as a raw card number or a network token. In AP2 the Shopping Agent receives "a payment credential", and the specification is agnostic to the payment instrument. What the Stripe, ACP and Adyen documents have the agent pass to the store is a token, and Stripe's resolve step can return the raw card number (`fpan`) to the seller.

## Stripe Shared Payment Tokens

Stripe's [Shared Payment Tokens](https://docs.stripe.com/agentic-commerce/concepts/shared-payment-tokens) "grant sellers scoped access to customers' payment methods for agent-initiated purchases". They come under Stripe's preview terms, and every example sends `Stripe-Version: 2026-09-30.preview`. Stripe's [agentic commerce index](https://docs.stripe.com/agentic-commerce) says: "Availability, launch stage, and supported countries vary by integration."

The [agent page](https://docs.stripe.com/agentic-commerce/concepts/shared-payment-tokens.md?agent-seller=agent) tells the agent to "Use the Payment Element to securely collect payment details", a payment form Stripe provides, and to load Stripe.js from `js.stripe.com` "to remain PCI compliant". When the customer submits the form, the agent creates a PaymentMethod, then issues a token "using your customer's payment method and the seller's Stripe profile", with usage limits for currency, maximum amount and expiry. Per the seller page, "The agent sets the maximum amount to match the total amount of the transaction." The agent can also revoke a token it issued.

The [seller page](https://docs.stripe.com/agentic-commerce/concepts/shared-payment-tokens.md?agent-seller=seller) covers the other side. The seller pays with the token on a PaymentIntent, Stripe's object for one payment, and can look up "limited information about the underlying payment method, such as the card brand", the last four digits and the usage limits. A seller that uses another processor can instead resolve the token into network credentials and pass them to that processor; Stripe names the types `fpan`, `network_token`, `agentic_token` and `dpan`. "You can only resolve an SPT one time." If the seller has not given Stripe its PCI Attestation of Compliance, "Stripe must encrypt credentials that fall within PCI scope", using a public key whose private key the seller cannot access.

A Stripe Shared Payment Token (preview), message by message.

1. Customer → Agent: Submits PaymentMethod. In Stripe’s seller diagram the customer submits a payment method to the agent. Source: [Stripe docs: Shared Payment Tokens (preview)](https://docs.stripe.com/agentic-commerce/concepts/shared-payment-tokens.md?agent-seller=seller).
2. Agent → Stripe: Issues SharedPaymentToken. The agent issues the token with usage and expiration limits, setting the maximum amount to the transaction total. The examples send Stripe-Version: 2026-09-30.preview. Source: [Stripe docs: Shared Payment Tokens (preview)](https://docs.stripe.com/agentic-commerce/concepts/shared-payment-tokens.md?agent-seller=seller).
3. Agent → Seller: Sends SharedPaymentToken. The agent sends the token to the seller. Source: [Stripe docs: Shared Payment Tokens (preview)](https://docs.stripe.com/agentic-commerce/concepts/shared-payment-tokens.md?agent-seller=seller).
4. Seller → Stripe: PaymentIntent with the token. The seller creates a PaymentIntent with the token, paying with shared_payment_granted_token. Source: [Stripe docs: Shared Payment Tokens (preview)](https://docs.stripe.com/agentic-commerce/concepts/shared-payment-tokens.md?agent-seller=seller).
5. Stripe → Customer: Processes transaction. Stripe processes the transaction. Shared Payment Tokens are a Stripe preview. Source: [Stripe docs: Shared Payment Tokens (preview)](https://docs.stripe.com/agentic-commerce/concepts/shared-payment-tokens.md?agent-seller=seller).

With a third-party processor:

1. Seller → Stripe: POST …/granted_tokens/{id}/resolve. Instead of steps 4–5 of the main path, a seller using another processor resolves the token to network credentials (fpan, network_token, agentic_token or dpan) and submits them to that processor. A token can be resolved only once. Source: [Stripe docs: Shared Payment Tokens (preview)](https://docs.stripe.com/agentic-commerce/concepts/shared-payment-tokens.md?agent-seller=seller).

Neither Stripe page mentions ACP. ACP's draft, in turn, uses Stripe as its example PSP and calls the vault token an SPT.

## ACP delegated payment

ACP's released [Delegate Payment API](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/spec/2026-04-17/openapi/openapi.delegate_payment.yaml), version `2026-04-17`, defines one endpoint, `POST /agentic_commerce/delegate_payment`. It "Tokenizes a credential for controlled usage by the merchant's PSP per the **Allowance** constraints", and "Exactly one credential type is currently supported: **card**". The allowance has six required fields: a reason, a maximum amount in minor units (cents, for dollars), a currency, the checkout session, the merchant and an expiry. The reason is "currently only one_time". The [Delegate Payment RFC](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.delegate_payment.md), labelled Draft, says the token "MUST ONLY be usable within the provided Allowance" and "MUST become invalid at or after `allowance.expires_at`". The response is the vault token, with an id that begins `vt_`.

The released file calls the two sides client and server and does not say who sends the request. The Payment Handlers RFC, labelled Draft at version `2026-01-22`, does. Its credential vaulting example reads "Agent calls `delegate_payment` with the Seller's PSP (Stripe) using the merchant_id", then "PSP (Stripe) creates vault token (SPT) scoped to the Seller's merchant account", "Agent submits SPT to Seller" and "Seller unwraps and uses the SPT with their PSP (Stripe)". When a handler sets `requires_delegate_payment` to true, the "Agent **MUST** call `/agentic_commerce/delegate_payment` before checkout completion".

Each payment handler in a checkout session also carries `requires_pci_compliance`. The released [checkout file](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/spec/2026-04-17/openapi/openapi.agentic_checkout.yaml) describes it as "Whether this handler routes PCI DSS sensitive data". The draft recommends `false`, and says that if it is set to true, "Seller can route requests to PCI-compliant infrastructure". In our reading, the field says whether the handler itself carries card data; it does not say which parties see it. [ACP explained](https://storewalk.ai/blog/acp-explained) has a figure that tries a charge against an allowance.

## What payment providers' own documents describe

Adyen has a guide for agent platforms using [ACP](https://docs.adyen.com/online-payments/agentic-commerce/agent-platform/agentic-payments-acp) and one for those using [UCP](https://docs.adyen.com/online-payments/agentic-commerce/agent-platform/agentic-payments-ucp). The ACP page sums it up: "Adyen stores the credential and returns an ACP token that your agent passes to the merchant. The merchant uses the token to process the payment with Adyen." Its six steps start with "The shopper enters their payment details in your agent platform" and end with Adyen returning the payment result to the merchant's checkout application, as Adyen's diagram labels it. The agent platform must meet PCI DSS Level 1, pass Adyen's security review, and ask Adyen for "Access to Delegated Payment".

The UCP page has the same six steps with `POST /ucp/v1/handler/tokenize` and "a UCP token that is associated with the specific checkout session and merchant identifier". It asks for the security review and names no PCI DSS level. It adds: "Each merchant must independently authorize your platform to tokenize on their behalf." UCP's own [checkout capability](https://ucp.dev/latest/specification/shopping/checkout/) says the business "remains the Merchant of Record (MoR), and they don't need to become PCI DSS compliant to accept card payments through this Capability". The merchant of record is the party that sells to the buyer and answers for the sale. [UCP explained](https://storewalk.ai/blog/ucp-explained) covers that capability.

An agent payment through Adyen, with ACP and with UCP.

Adyen with ACP:

1. Shopper → Agent platform: Payment details. When the agent platform checks out with ACP. Step 1 on Adyen’s ACP page: the shopper enters their payment details in the agent platform. Source: [Adyen docs: agentic payments with ACP](https://docs.adyen.com/online-payments/agentic-commerce/agent-platform/agentic-payments-acp).
2. Agent platform → Adyen: POST /agentic_commerce/delegate_payment. The agent platform sends the card number or network token to Adyen. ACP’s own Payment Handlers RFC, a draft, describes the same delegation. Sources: [Adyen docs: agentic payments with ACP](https://docs.adyen.com/online-payments/agentic-commerce/agent-platform/agentic-payments-acp) and [ACP RFC: Payment Handlers (Draft, 2026-01-22)](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.payment_handlers.md).
3. Adyen → Agent platform: Merchant-scoped ACP token. Adyen validates the credentials and returns a merchant-scoped ACP token. Source: [Adyen docs: agentic payments with ACP](https://docs.adyen.com/online-payments/agentic-commerce/agent-platform/agentic-payments-acp).
4. Agent platform → Merchant: ACP token to checkout. The agent platform sends the ACP token to the merchant’s checkout application. Source: [Adyen docs: agentic payments with ACP](https://docs.adyen.com/online-payments/agentic-commerce/agent-platform/agentic-payments-acp).
5. Merchant → Adyen: /payments with the ACP token. The merchant’s checkout application makes a /payments request including the ACP token. Source: [Adyen docs: agentic payments with ACP](https://docs.adyen.com/online-payments/agentic-commerce/agent-platform/agentic-payments-acp).
6. Adyen → Merchant: Payment result. Adyen authorizes the payment and returns the payment result to the merchant’s checkout application. Source: [Adyen docs: agentic payments with ACP](https://docs.adyen.com/online-payments/agentic-commerce/agent-platform/agentic-payments-acp).

Adyen with UCP:

1. Shopper → Agent platform: Payment details. When the agent platform checks out with UCP. Adyen’s UCP page has the same six steps. Step 1: the shopper enters payment details. Source: [Adyen docs: agentic payments with UCP](https://docs.adyen.com/online-payments/agentic-commerce/agent-platform/agentic-payments-ucp).
2. Agent platform → Adyen: POST /ucp/v1/handler/tokenize. The agent platform sends the payment data to Adyen with this request, in place of delegate_payment. Source: [Adyen docs: agentic payments with UCP](https://docs.adyen.com/online-payments/agentic-commerce/agent-platform/agentic-payments-ucp).
3. Adyen → Agent platform: UCP token. Adyen returns a UCP token where the ACP flow returns an ACP token. Source: [Adyen docs: agentic payments with UCP](https://docs.adyen.com/online-payments/agentic-commerce/agent-platform/agentic-payments-ucp).
4. Agent platform → Merchant: UCP token to checkout. The agent platform sends the UCP token to the merchant’s checkout application. Source: [Adyen docs: agentic payments with UCP](https://docs.adyen.com/online-payments/agentic-commerce/agent-platform/agentic-payments-ucp).
5. Merchant → Adyen: /payments with the UCP token. The merchant makes a /payments request including the UCP token. Source: [Adyen docs: agentic payments with UCP](https://docs.adyen.com/online-payments/agentic-commerce/agent-platform/agentic-payments-ucp).
6. Adyen → Merchant: Payment result. Adyen authorizes the payment and returns the result to the merchant checkout application. Source: [Adyen docs: agentic payments with UCP](https://docs.adyen.com/online-payments/agentic-commerce/agent-platform/agentic-payments-ucp).

Adyen's [merchant page](https://docs.adyen.com/online-payments/agentic-commerce/merchant) lists separate guides: Agentic Feed API, Agentic Cart API, Google Agentic Commerce (for "payments initiated by Google AI Mode or Gemini") and Embedded Commerce. None of these three Adyen pages carries a beta, pilot or preview label.

PayPal's [Agent Ready overview](https://developer.paypal.com/agent-ready/overview) lists three paths. For ACP, "Delegated payment tokens through Braintree", where "Customers authorize PayPal as their payment method. Your app receives a delegated token to process transactions through Braintree." For UCP with Braintree, "Google returns a single-use payment token that you process through Braintree." For UCP with PayPal, "Google sends an encrypted Google Pay credential in the checkout session. You forward it to PayPal through the Orders v2 API for decryption and processing." PayPal's [agentic commerce page](https://developer.paypal.com/agentic-commerce-services/about) says Agent Ready "enables merchants to accept payments through AI assistants with minimal changes to their current payment setup."

## Visa's Trusted Agent Protocol

Visa describes its [Trusted Agent Protocol](https://developer.visa.com/docs/trusted-agent-protocol) as "a verifiable, cryptographic standard to help merchants differentiate legitimate agents from nefarious bots or web crawlers". What it defines is a set of signatures on the agent's requests. "A merchant's primary task is to validate this signature", the page says, meaning a signature the agent puts on its request. The [specifications page](https://developer.visa.com/docs/trusted-agent-protocol/trusted-agent-protocol-specifications) bases that header signature on RFC 9421, HTTP Message Signatures, "aligned with web-bot-auth", the IETF draft that [Bots, crawlers and agents](https://storewalk.ai/blog/bots-crawlers-agents) walks through. An HTTP message signature, in our words, is a signature over chosen parts of a request that the receiver can check with the sender's public key.

The agent signs at two points, the product page and the checkout page, and the tag says which: `agent-browser-auth` or `agent-payer-auth`. The figure shows Visa's two sample requests. The page publishes no version or status label.

A Visa Trusted Agent Protocol signature, field by field.

Visa’s sample requests, copied from its Trusted Agent Protocol specifications page. The samples also list empty Accept and User-Agent lines, left out here. Signature-Input is one header, split over several lines here for width.

Product page:

```http
URL: https://www.example.com/example-product
Signature-Input: sig2=("@authority" "@path");
  created=1735689600;
  keyid="poqkLGiymh_W0uP6PZFw-dvez3QJT5SolqXBCW38r0U";
  alg="Ed25519";
  expires=1735693200;
  nonce="e8N7S2MFd/qrd6T2R3tdfAuuANngKI7LFtKYI/vowzk4lAZYadIX6wW25MwG7DCT9RUKAJ0qVkU0mEeLElW1qg==";
  tag="agent-browser-auth"
Signature: sig2=:jdq0SqOwHdyHr9+r5jw3iYZH6aNGKijYp/EstF4RQTQdi5N5YYKrD+mCT1HA1nZDsi6nJKuHxUi/5Syp3rLWBA==:
```

Checkout:

```http
URL: https://www.example.com/checkout
Signature-Input: sig2=("@authority" "@path");
  created=1735689600;
  keyid="poqkLGiymh_W0uP6PZFw-dvez3QJT5SolqXBCW38r0U";
  alg="Ed25519";
  expires=1735693200;
  nonce="e8N7S2MFd/qrd6T2R3tdfAuuANngKI7LFtKYI/vowzk4lAZYadIX6wW25MwG7DCT9RUKAJ0qVkU0mEeLElW1qg==";
  tag="agent-payer-auth"
Signature: sig2=:jdq0SqOwHdyHr9+r5jw3iYZH6aNGKijYp/EstF4RQTQdi5N5YYKrD+mCT1HA1nZDsi6nJKuHxUi/5Syp3rLWBA==:
```

Its fields:

- Signature-Input. In our words: What was signed and with which settings, under the label sig2. The merchant rebuilds the signed text from this line. What the source says: Visa: “A Dictionary Structured Field containing the metadata of the message signature generated from components within the HTTP message”. Source: [Visa: Trusted Agent Protocol specifications](https://developer.visa.com/docs/trusted-agent-protocol/trusted-agent-protocol-specifications).
- "@authority". In our words: The site the request goes to, here www\.example.com. Signing it ties the signature to that site. What the source says: Visa: “The authority of the target URI for a request”. It is in Visa’s minimum list of fields. Source: [Visa: Trusted Agent Protocol specifications](https://developer.visa.com/docs/trusted-agent-protocol/trusted-agent-protocol-specifications).
- "@path". In our words: The page on that site, here /checkout or /example-product. Signing it ties the signature to that page as well. What the source says: Visa: “The absolute path portion of the target URI for a request”. Source: [Visa: Trusted Agent Protocol specifications](https://developer.visa.com/docs/trusted-agent-protocol/trusted-agent-protocol-specifications).
- created. In our words: When the agent signed, in seconds since the start of 1970 (UTC). What the source says: Visa: “The timestamp of when the message request was created”. The timestamps “should not be more than 8 minutes apart”. Source: [Visa: Trusted Agent Protocol specifications](https://developer.visa.com/docs/trusted-agent-protocol/trusted-agent-protocol-specifications).
- keyid. In our words: Which public key to check the signature with. The merchant fetches it, or uses a copy it kept. What the source says: Visa: “The identity of the public key that will be used to verify the signature. The Merchant may have cached the public key for the keyid.” “If the public key cannot be retrieved or the public key has expired, the message should be blocked”. Source: [Visa: Trusted Agent Protocol specifications](https://developer.visa.com/docs/trusted-agent-protocol/trusted-agent-protocol-specifications).
- alg. In our words: The signing algorithm. Visa’s samples use Ed25519. What the source says: Visa: “The algorithm used to generate/verify the signature”. Source: [Visa: Trusted Agent Protocol specifications](https://developer.visa.com/docs/trusted-agent-protocol/trusted-agent-protocol-specifications).
- expires. In our words: When the signature stops being valid. In Visa’s samples it is an hour after created, more than the 8 minutes its checks allow, so we read the values as illustrations. What the source says: Visa: “The timestamp of when the message request will no longer be valid”. The merchant’s checks block a message whose timestamps are more than 8 minutes apart. Source: [Visa: Trusted Agent Protocol specifications](https://developer.visa.com/docs/trusted-agent-protocol/trusted-agent-protocol-specifications).
- nonce. In our words: A value for this session. Seeing the same one twice within 8 minutes points to a replayed request. What the source says: Visa: “A session identifier. If there are multiple message signatures in the header, the session identifier should be the same nonce used in other message signatures.” Source: [Visa: Trusted Agent Protocol specifications](https://developer.visa.com/docs/trusted-agent-protocol/trusted-agent-protocol-specifications).
- tag. In our words: Which of the two moments Visa names this is: browsing a product page, or paying at checkout. What the source says: Visa: “Will contain the value of agent-browser-auth or agent-payer-auth based on the type of interaction”. Without either tag, “the message has not been signed by a trusted agent.” Source: [Visa: Trusted Agent Protocol specifications](https://developer.visa.com/docs/trusted-agent-protocol/trusted-agent-protocol-specifications).
- Signature. In our words: The signature itself, under the same label sig2. What the source says: Visa: “A Dictionary Structured Field containing a message signature generated from the signature context of the target message”. “If signature validation fails, the message should be blocked.” Source: [Visa: Trusted Agent Protocol specifications](https://developer.visa.com/docs/trusted-agent-protocol/trusted-agent-protocol-specifications).

Visa’s page publishes no version or status label. It bases this header signature on RFC 9421, HTTP Message Signatures. Source: [Visa: Trusted Agent Protocol specifications](https://developer.visa.com/docs/trusted-agent-protocol/trusted-agent-protocol-specifications).

Visa’s trust model names three signatures:

- An agent recognition signature in the message header, the one shown above, “provided both during the browsing and payment interactions”.
- A signed consumer or device identity in the request body, which “is provided during the browsing interaction and may be provided during the payment interaction”.
- A signed payment container in the request body, which “is intended to provide information related to the payment credentials”.

Visa lists checks “The Merchant should perform”: block the message if a required field is missing, if the timestamps are more than 8 minutes apart, if the nonce was seen in the last 8 minutes, if the key cannot be retrieved, or if the signature fails. The checks “can be performed independently by the Merchant or by a Site Protection Provider on behalf of the Merchant.” Source: [Visa: Trusted Agent Protocol specifications](https://developer.visa.com/docs/trusted-agent-protocol/trusted-agent-protocol-specifications).

The header signature is one of three. The other two travel in the request body: a signed consumer or device identity, and "A linked and signed payment container", which "is intended to provide information related to the payment credentials". Visa's checks for the merchant are listed under the figure. We could not reach Visa's developer page for Visa Intelligent Commerce or Mastercard's documentation for its agent payments on 2026-10-22, so this article describes neither.

## AP2: mandates with the user present and not present

The Agent Payments Protocol (AP2), which Google [donated to the FIDO Alliance](https://blog.google/products-and-platforms/platforms/google-pay/agent-payments-protocol-fido-alliance/), works with signed authorisations. Its [specification](https://ap2-protocol.org/ap2/specification/) is titled "Agentic Payment Protocol (v0.2)", with no draft or final label, and the GitHub release `v0.2.0` is dated 2026-04-28. "Mandates are the core means that AP2 uses to authorize agents." A mandate, in our words, is a signed record of what the user authorised, which another party can check. AP2 secures them as SD-JWTs, a signed credential format.

There are two. "The Checkout Mandate is provided by the Shopping Agent and verified by the Merchant." "The Payment Mandate is provided by the Shopping Agent and verified by the Credential Provider, Network, and Merchant Payment Processor." The Credential Provider is "the source of Payment Credentials for the purchase". "The Payment Mandate is bound to a particular Checkout using the cryptographic hash of the Checkout JWT", the checkout the merchant signed. A Trusted Surface, the screen where the user gives consent, "MUST be non-agentic", which we read as: no language model handles it.

With the user present, the user approves the closed checkout and its payment on the Trusted Surface. With the user not present, "The User sees and approves a set of constraints", and the agent "assembles and approves a closed Checkout and Payment Mandate on their behalf using these open Mandates". Those open mandates "MUST include the agent's public key as a `cnf` claim", which in our reading lets a verifier check that the closed mandate was signed by the agent the user approved. "Verifiers of Mandates *always* receive a closed Payment and Checkout Mandate, regardless of the mode."

AP2 v0.2 mandates, with the user present and not present.

Human present:

1. Merchant → Shopping Agent: Merchant-signed Checkout JWT. The merchant must give the shopping agent a merchant-signed JWT containing the checkout; Human Present starts once the agent has it. Source: [AP2 specification (v0.2)](https://ap2-protocol.org/ap2/specification/).
2. Shopping Agent → Trusted Surface: Mandate content to show and sign. The agent builds the Checkout and Payment Mandate content and passes it to a Trusted Surface for display to the user and signing. Source: [AP2 specification (v0.2)](https://ap2-protocol.org/ap2/specification/).
3. Shopping Agent → Credential Provider: Payment Mandate for verification. With the mandates signed, the agent forwards the Payment Mandate to the Credential Provider (and possibly the network). It is bound to the checkout by the hash of the Checkout JWT. Source: [AP2 specification (v0.2)](https://ap2-protocol.org/ap2/specification/).
4. Credential Provider → Shopping Agent: Payment credential. Upon successful verification the agent receives a payment credential. The spec has the Credential Provider (or, if applicable, the network) return it after receiving the Payment Mandate. Source: [AP2 specification (v0.2)](https://ap2-protocol.org/ap2/specification/).
5. Shopping Agent → Merchant: Credential + Checkout Mandate. The payment credential and the Checkout Mandate go to the merchant, which checks the checkout against the one it created. Source: [AP2 specification (v0.2)](https://ap2-protocol.org/ap2/specification/).
6. Merchant → Merchant Payment Processor: Initiate payment. For a merchant-initiated charge, the merchant initiates payment with its Merchant Payment Processor. If the payment method pushes funds, the merchant instead confirms the funds it received. Source: [AP2 specification (v0.2)](https://ap2-protocol.org/ap2/specification/).
7. Merchant → Shopping Agent: Checkout Receipt. Once it has accepted or rejected the Checkout Mandate, the merchant must return a Checkout Receipt. A Payment Receipt goes to the agent, the Credential Provider and, if applicable, the network. Source: [AP2 specification (v0.2)](https://ap2-protocol.org/ap2/specification/).

Human not present:

1. Shopping Agent → Trusted Surface: Open mandates to authorize. To act autonomously the agent creates open Checkout and Payment Mandate content, constraints the user approves, and has the Trusted Surface authorize it. Open mandates must carry the agent’s public key as a cnf claim. Source: [AP2 specification (v0.2)](https://ap2-protocol.org/ap2/specification/).
2. Shopping Agent → Credential Provider: Open + closed Payment Mandate. The agent must give verifiers both the user-signed open mandate and its closed one “as described in the Direct case”, which sends the Payment Mandate first. Its verifiers are the Credential Provider and, if applicable, the network and the Merchant Payment Processor. Source: [AP2 specification (v0.2)](https://ap2-protocol.org/ap2/specification/).
3. Shopping Agent → Merchant: Open + closed Checkout Mandate, which the agent may sign itself. Then, as in the Direct case, the Checkout Mandate goes to the merchant. The agent may sign the closed mandate with its own key instead of getting approval on a Trusted Surface; verifiers always receive closed mandates. Source: [AP2 specification (v0.2)](https://ap2-protocol.org/ap2/specification/).

"AP2 is agnostic to the particular payment instrument used", and it "operates as a security feature within a Commerce Protocol". It is "designed explicitly to be compatible with the Universal Commerce Protocol (UCP)". UCP's checkout page says the checkout "has to be finalized manually by the user through a trusted UI unless the AP2 Mandates extension is supported." The ACP documents we searched do not mention AP2, and the AP2 specification mentions neither ACP nor Stripe.

## Who handles the card details

Each document draws its own flow, with its own names for the parties. The figure puts four of them side by side and marks where a document says nothing.

Who handles the card details, flow by flow.

Stripe tokens. Stripe’s Shared Payment Tokens docs, agent and seller pages. Stripe offers them under preview terms, and the examples send Stripe-Version: 2026-09-30.preview. Sources: [Stripe docs: Shared Payment Tokens, seller (preview)](https://docs.stripe.com/agentic-commerce/concepts/shared-payment-tokens.md?agent-seller=seller) and [Stripe docs: Shared Payment Tokens, agent (preview)](https://docs.stripe.com/agentic-commerce/concepts/shared-payment-tokens.md?agent-seller=agent).

- Customer. Card details: Enters payment details in the agent’s form. Stripe’s agent page says to “Use the Payment Element to securely collect payment details”. What it sends or checks: Submits a payment method to the agent, the first arrow of Stripe’s diagram.
- Agent. Card details: Not stated whether the agent’s own systems see the card number. The page says to load Stripe.js from js.stripe.com “to remain PCI compliant” and, “When the customer submits your payment form, create a PaymentMethod”. What it sends or checks: Issues the token to the seller’s Stripe profile with a currency, a maximum amount and an expiry, and shares the token’s ID with the seller. “The agent sets the maximum amount to match the total amount of the transaction.”
- Seller. Card details: Can retrieve the card brand and last four digits. Resolving the token for another processor returns network credentials. Unless the seller has given Stripe its PCI Attestation of Compliance, Stripe encrypts those in PCI scope “with a public key whose corresponding private key you can’t access.” What it sends or checks: Pays with the token on a PaymentIntent, or resolves it for a third-party processor. “You can only resolve an SPT one time.”
- Stripe. Card details: When the seller confirms a PaymentIntent with the token, Stripe sets “a new PaymentMethod cloned from the customer’s original payment method.” What it sends or checks: Receives the agent’s request to issue the token, and processes the transaction.

ACP delegated payment. ACP’s Payment Handlers RFC, labelled Draft (2026-01-22), with the Delegate Payment API of the released 2026-04-17 spec. The released file does not say who calls the endpoint; the draft does. Sources: [ACP RFC: Payment Handlers (Draft, 2026-01-22)](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.payment_handlers.md), [ACP Delegate Payment API, 2026-04-17](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/spec/2026-04-17/openapi/openapi.delegate_payment.yaml) and [ACP RFC: Delegate Payment (Draft, 2025-09-29)](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.delegate_payment.md).

- Buyer. Card details: Not stated. The agent acquires the credential at step 4 of the draft’s flow “(via user input, wallet, etc.)”; step 1 is the agent’s POST /checkout_sessions. What it sends or checks: Not stated. No step of the draft’s flow comes from the buyer.
- Agent. Card details: Sends the credential with the allowance to delegate_payment, as a raw card number (fpan) or a network token. What it sends or checks: Receives the vault token and submits it to the seller as payment.
- Seller. Card details: Not stated directly. Each payment handler sets requires_pci_compliance, “Whether this handler processes PCI DSS sensitive data.” The draft recommends false: “Handlers SHOULD leverage tokenization to avoid passing PCI-sensitive data.” What it sends or checks: “Seller uses vault token with their PSP to charge payment”.
- PSP. Card details: Receives the credential: the draft’s example reads “Agent calls delegate_payment with the Seller’s PSP (Stripe) using the merchant_id”. What it sends or checks: Creates the vault token, scoped to the seller’s merchant account. The Delegate Payment RFC (Draft) says it “MUST ONLY be usable within the provided Allowance”.

Adyen with ACP. Adyen’s own guide for agent platforms that check out with ACP. The page carries no beta, pilot or preview label. Source: [Adyen docs: agentic payments with ACP](https://docs.adyen.com/online-payments/agentic-commerce/agent-platform/agentic-payments-acp).

- Shopper. Card details: Enters their payment details in the agent platform. What it sends or checks: Not stated. No later step comes from the shopper.
- Agent platform. Card details: Sends the card number or network token to Adyen. Adyen’s page says “your agent platform must meet PCI DSS Level 1 compliance” and pass Adyen’s security review. What it sends or checks: Receives a merchant-scoped ACP token and sends it to the merchant’s checkout application.
- Merchant. Card details: Not stated. In Adyen’s six steps the merchant’s checkout application receives the ACP token. What it sends or checks: Makes a /payments request with the ACP token and receives the payment result.
- Adyen. Card details: Validates the credentials. “Adyen stores the credential and returns an ACP token that your agent passes to the merchant.” What it sends or checks: Returns the ACP token to the agent platform, then authorizes the payment.

AP2, user present. The AP2 specification, titled “Agentic Payment Protocol (v0.2)”, in its Human Present mode. Sources: [AP2 specification](https://ap2-protocol.org/ap2/specification/) and [AP2 specification v0.2 (source file)](https://github.com/google-agentic-commerce/AP2/blob/main/docs/ap2/specification.md).

- User. Card details: Not stated. The mode starts once the agent has the merchant’s signed checkout. What it sends or checks: Sees the Checkout and Payment Mandate content on a Trusted Surface, a role that “MUST be non-agentic”, and signs it there.
- Shopping Agent. Card details: Receives a payment credential once the Payment Mandate is verified. “AP2 is agnostic to the particular payment instrument used”, so in our reading the spec leaves open whether that credential is a card number. What it sends or checks: Forwards the Payment Mandate to the Credential Provider, then passes the credential and the Checkout Mandate to the merchant.
- Merchant. Card details: Receives the payment credential with the Checkout Mandate, and initiates payment with its processor “if a Merchant-initiated charge”. What it sends or checks: Verifies the checkout against the one it created and returns a Checkout Receipt.
- Credential Provider. Card details: Is “the source of Payment Credentials for the purchase”. It scopes the credential and returns it after it receives the Payment Mandate. What it sends or checks: Verifies the Payment Mandate, possibly together with the network.
- Merchant Payment Processor. Card details: Checks “that the Payment Credential shared by the Credential Provider has been authorized to pay for this Checkout instance.” What it sends or checks: Verifies the Payment Mandate.

Each flow is one document’s own account, kept apart from the others. Not stated means we found nothing on it in that document, not that the party never receives the card details.

Stripe's pages have the agent collect payment details in its own form, built with Stripe's Payment Element. The agent's own access to the number is not stated, and the seller can see the card brand and last four digits, or network credentials if it resolves the token. In ACP's draft the agent sends the card to the seller's PSP, and the seller receives a vault token. In Adyen's ACP guide the agent platform sends the card number or network token to Adyen and the merchant's checkout application receives an ACP token; the guide does not say whether card data reaches the merchant. AP2 passes a payment credential to the agent and then to the merchant, and leaves its form open.

## What you can ask your payment provider

- Which agent payment flows it documents for merchants, and under which protocol. Adyen's ACP and UCP guides are written for agent platforms; its merchant guides are Agentic Feed API, Agentic Cart API, Google Agentic Commerce and Embedded Commerce. PayPal lists ACP through Braintree and two UCP paths through Google Pay.
- If your checkout speaks ACP: what your payment handler declares for `psp`, `requires_delegate_payment` and `requires_pci_compliance`, and whether your PSP answers `delegate_payment` itself.
- On Adyen with UCP: which agent platforms your merchant account has authorised to tokenise on your behalf, since each merchant must authorise each platform.
- On Stripe: whether you will pay with Shared Payment Tokens on PaymentIntents or resolve them for another processor, and, if you resolve them, whether Stripe holds your PCI Attestation of Compliance, which decides whether you receive the credentials encrypted.
- Whether your bot management or site protection provider can check Visa Trusted Agent Protocol signatures. Visa says the checks "can be performed independently by the Merchant or by a Site Protection Provider on behalf of the Merchant."
- If an agent platform offers AP2: which companies would act as Credential Provider and Merchant Payment Processor. The specification allows "a single entity to play multiple (or even all) of the roles".

## What is not settled

- Who calls `delegate_payment` is stated in a Draft RFC. The released Delegate Payment file does not say, and ACP as a whole "is currently in `beta`".
- Stripe's tokens are under preview terms, AP2 is at v0.2 with no draft or final label, and Visa's page has no version label.
- Several documents are silent on parts of the flow. Stripe's agent page does not say whether the agent's own systems see the card number, and Adyen's steps do not say whether card data reaches the merchant.
- The documents mostly do not refer to each other. Stripe's pages do not mention ACP or AP2, the ACP documents do not mention AP2, and AP2's specification does not mention ACP.

[The hub](https://storewalk.ai/blog/why-agents-cant-buy) sets out all five walls. [UCP vs ACP vs MCP vs AP2](https://storewalk.ai/blog/ucp-vs-acp-vs-mcp-vs-ap2) compares which part of a purchase each protocol defines.

## Sources

- [Stripe docs: Shared Payment Tokens (preview)](https://docs.stripe.com/agentic-commerce/concepts/shared-payment-tokens)
- [Stripe docs: Shared Payment Tokens, agent page](https://docs.stripe.com/agentic-commerce/concepts/shared-payment-tokens.md?agent-seller=agent)
- [Stripe docs: Shared Payment Tokens, seller page](https://docs.stripe.com/agentic-commerce/concepts/shared-payment-tokens.md?agent-seller=seller)
- [Stripe docs: Agentic commerce](https://docs.stripe.com/agentic-commerce)
- [ACP Delegate Payment API, 2026-04-17](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/spec/2026-04-17/openapi/openapi.delegate_payment.yaml)
- [Agentic Checkout API, 2026-04-17](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/spec/2026-04-17/openapi/openapi.agentic_checkout.yaml)
- [ACP RFC: Delegate Payment (Draft, 2025-09-29)](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.delegate_payment.md)
- [ACP RFC: Payment Handlers (Draft, 2026-01-22)](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.payment_handlers.md)
- [ACP repository and README](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol)
- [Adyen docs: Agentic payments integration with ACP checkout flow](https://docs.adyen.com/online-payments/agentic-commerce/agent-platform/agentic-payments-acp)
- [Adyen docs: Agentic payments integration with UCP](https://docs.adyen.com/online-payments/agentic-commerce/agent-platform/agentic-payments-ucp)
- [Adyen docs: Agentic commerce for merchants](https://docs.adyen.com/online-payments/agentic-commerce/merchant)
- [PayPal: Agent Ready overview](https://developer.paypal.com/agent-ready/overview)
- [PayPal: About agentic commerce services](https://developer.paypal.com/agentic-commerce-services/about)
- [UCP checkout capability](https://ucp.dev/latest/specification/shopping/checkout/)
- [Visa: Trusted Agent Protocol](https://developer.visa.com/docs/trusted-agent-protocol)
- [Visa: Trusted Agent Protocol specifications](https://developer.visa.com/docs/trusted-agent-protocol/trusted-agent-protocol-specifications)
- [AP2 specification (v0.2)](https://ap2-protocol.org/ap2/specification/)
- [AP2 specification, source file](https://github.com/google-agentic-commerce/AP2/blob/main/docs/ap2/specification.md)
- [AP2 releases on GitHub](https://github.com/google-agentic-commerce/AP2/releases)
- [Google: donating AP2 to the FIDO Alliance](https://blog.google/products-and-platforms/platforms/google-pay/agent-payments-protocol-fido-alliance/)

Last checked 22 Oct 2026