How an agent pays without seeing your card

A payment service provider (PSP) is the company that processes a store's card payments. ACP's draft Payment Handlers RFC 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's 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 says: "Availability, launch stage, and supported countries vary by integration."

The agent page 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 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.

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

ACP's released Delegate Payment API, 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, 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 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 has a figure that tries a charge against an allowance.

Adyen has a guide for agent platforms using ACP and one for those using 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 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 covers that capability.

Adyen's merchant page 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 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 says Agent Ready "enables merchants to accept payments through AI assistants with minimal changes to their current payment setup."

Visa describes its 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 bases that header signature on RFC 9421, HTTP Message Signatures, "aligned with web-bot-auth", the IETF draft that Bots, crawlers and 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.

URL: https://www.example.com/example-productSignature-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==:

URL: https://www.example.com/checkoutSignature-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==:

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.

The Agent Payments Protocol (AP2), which Google donated to the FIDO Alliance, works with signed authorisations. Its 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 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.

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.

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.

• 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".

• 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 sets out all five walls. UCP vs ACP vs MCP vs AP2 compares which part of a purchase each protocol defines.