Back to Blog
Engineering16 September 20267 min read · 1,472 words

Agentic Payments vs Standard Checkout: What Actually Changes

N7

No7 Engineering Team

Growth Architecture Unit

Engineering: Agentic Payments vs Standard Checkout: What Actually Changes (illustration)

Agentic payments allow software agents to execute financial transactions on your store within pre-authorised cryptographic constraints without a human completing checkout. Unlike standard automated checkouts, these rails verify buyer delegation, bind spend limits to the token, and shift authentication upstream before the order lands in your ledger.

What are agentic payments vs agentic commerce?

Agentic payments represent the actual financial transfer layer that authorises and settles funds when an autonomous AI agent acts on behalf of a shopper. The broader concept of agentic commerce covers the entire buying lifecycle, including product discovery, inventory querying, negotiation, and cart creation.

Understanding agentic payments vs agentic commerce requires separating search protocols from settlement mechanisms. While our earlier guide on agentic commerce protocols contrasts discovery and catalog standards like ACP and UCP, the payment layer requires its own distinct authorisation rails. An agent can discover a catalog item through an open endpoint, yet the financial transaction cannot complete until the payment network verifies that the human buyer explicitly delegated authority to that bot.

Standard browser checkouts rely on human-present authentication cues: session cookies, CAPTCHA challenges, and biometric device unlocks. When an agent purchases on a consumer's behalf, those assumptions fail. The industry response has yielded four distinct architectural rails attempting to resolve delegation, tokenisation, and liability.

How the four major payment rails operate

The four primary implementations competing for merchant checkout integration are Visa Intelligent Commerce, Mastercard Agent Pay, Stripe Agentic Commerce Suite, and Google Agent Payments Protocol (AP2). Each system approaches the transaction from a different position in the payments stack.

Card schemes attempt to protect the cardholder account by issuing restricted tokens directly from the network vault. Payment service providers build orchestration proxies that translate agent requests into existing merchant accounts. Technology platforms define protocol specifications that treat agents, merchants, and credential providers as distinct cryptographic actors.

Payment RailUnderlying MechanismMerchant Stack ImpactRollout Status
Intelligent Commerce (Visa)Agent-scoped tokens via Intelligent Commerce ConnectZero code change if connected to the Visa Acceptance PlatformPilot with select partners
Agent Pay (Mastercard)Network-level agent acceptance frameworkRouting updates via participating acquirersPilot phase
Stripe agentic paymentsShared Payment Tokens and /v1/agentic/checkoutsNew webhook endpoints and payment_records reportingPrivate preview
Google AP2Signed open and closed Payment MandatesMandate signature verification and public key resolutionOpen specification

Every rail tries to solve the identical dilemma: proving that a buyer authorised an autonomous machine to spend money within defined boundaries.

Mechanisms: from Shared Payment Tokens to signed mandates

The intelligent commerce framework from Visa approaches the problem through its network-level infrastructure. Through developer.visa.com, the card scheme details Intelligent Commerce Connect, which functions as a network-, protocol-, and token-vault-agnostic on-ramp for agent builders and merchants. Announced in an April 2026 pilot with 8 named partners including AWS and Highnote, the service provisions tokens bound directly to the agent runtime. These agentic tokens can only execute transactions matching the consumer's pre-configured merchant categories and spend boundaries.

In parallel, the network framework known as Agent Pay from Mastercard offers card-level rails for agent purchases. Merchants access this infrastructure through participating acquirers rather than bespoke frontend code.

Stripe approaches delegated buying through its Agentic Commerce Suite (ACS). When an agent finalizes an order, Stripe routes a Shared Payment Token (SPT) to the merchant confirmation hook. The SPT represents a cryptographically scoped grant of the customer's payment method issued directly to the merchant profile with explicit usage limits. Sellers who process through third-party processors resolve this grant into credentials and report the settlement back using the /v1/payment_records/report_payment endpoint documented on stripe.com. Under the hood, Stripe accepts credential types including agentic_token and dpan, handling the underlying network tokenisation on the seller's behalf.

Google AP2 takes a decentralized approach based on verifiable digital credentials. Documented through cloud.google.com, AP2 relies on two chained structures: an Open Payment Mandate and a Closed Payment Mandate. The Open Mandate captures the user's spending intent, defining budget limits, allowed payees, and authorised payment instruments while the agent browses. Once the cart is confirmed, the system signs a Closed Mandate bound to the exact line items, final price, and named merchant.

Who is the merchant of record and who bears liability?

In every current agentic payment specification, the merchant selling the physical goods remains the legal Merchant of Record (MoR). Neither the agent provider nor the protocol host takes inventory ownership or tax collection duties onto their balance sheet.

This structure has acute consequences for payment liability under regulations like the UK Payment Services Regulations and Revised Payment Services Directive (PSD2). Standard consumer transactions use 3-D Secure challenges that introduce roughly 2 to 5 seconds of latency into web sessions to confirm identity and shift chargeback liability to the card issuer. In delegated agent transactions, an interactive browser redirect challenge breaks autonomous checkout entirely.

Under both AP2 and Stripe ACS, Strong Customer Authentication (SCA) must occur upstream at the moment the consumer delegates authority to the agent. When the agent presents a signed Closed Payment Mandate or a network-backed agentic_token, the credential carries the cryptographic proof of that upstream authentication. If the merchant processes the token using an acquirer that supports the relevant scheme indicators, liability for unauthorized transactions shifts back to the card issuer. However, if your gateway drops these agentic metadata fields during processing, the transaction falls back to an unauthenticated card-not-present charge, leaving your business exposed to first-party fraud disputes.

PCI DSS scope and fraud defence for machine traffic

Delegated agent checkouts do not expand your PCI DSS scope if implemented according to provider specifications. Because the agent delivers a scoped token (such as an SPT) or resolves credentials through an API proxy, raw Primary Account Numbers (PANs) never touch your application servers. Your systems remain in PCI DSS SAQ A or SAQ A-EP scope, identical to an embedded iframe or hosted fields integration.

The real operational risk lies in automated fraud defence. Conventional fraud heuristics penalize headless browsing fingerprints, missing mouse movements, datacenter IP ranges, and instantaneous form submissions. If you deploy strict bot mitigation rules on your checkout endpoints, you will systematically block genuine AI shopping agents.

On the custom headless integrations we built for high-volume UK retailers, decoupling payment orchestration from the cart session prevented session locking during external API callbacks. Defending against automated abuse requires evaluating cryptographically signed intent headers rather than crude IP reputation or browser canvas fingerprinting.

Legitimate agent traffic arrives with verifiable mandate signatures or authenticated tokens provided by registered enablers. Malicious scraping bots masquerading as agents fail cryptographic signature verification at the gateway boundary.

Platform readiness: Shopify, BigCommerce, and custom headless

Mainstream ecommerce platforms handle the vast majority of agentic plumbing natively through platform-level standards. As discussed in our analysis of GPT-5-5 and conversational storefronts, buyer discovery is moving into chat interfaces, but settlement still requires a hardened financial protocol.

Shopify exposes its catalog and checkout primitives via the Storefront MCP server and Universal Commerce Protocol (UCP) discovery standards. In our work auditing checkout extensibility across merchant stores, we typically see teams budget £15,000 to £60,000 for custom app development when attempting to replicate native provider behaviours unnecessarily. For stores on SaaS platforms, building custom token decoders is almost always a mistake.

Agentic Payment Integration Decision Matrix

Store ArchitectureRecommended Immediate ActionEngineering InvestmentPrimary Failure Mode
Shopify PlusPublish valid UCP discovery files and maintain structured product feedsNear zero custom codeOverzealous Cloudflare WAF blocking agent discovery crawls
BigCommerceEnable native wallet tokens and expose clean REST catalog APIsLow; configuration onlyStale webhook data causing stock allocation rejections
Custom HeadlessBuild reverse API hooks for Stripe ACS or ingest AP2 Payment MandatesHigh; roughly 4 to 8 weeks engineeringDropping tokenisation cryptograms during gateway authorisation

What to do next

Engineers handling agentic payments UK deployments must distinguish between live merchant infrastructure and US-centric proof-of-concept trials. Stripe ACS and Intelligent Commerce Connect from Visa remain in pilot and private preview phases, largely restricted to US corporate entities and selected enterprise beta partners. If your business operates primarily in the UK or EEA, no off-the-shelf processor allows you to flip a switch for autonomous, unsupervised settlements under local SCA requirements today.

Do not waste developer hours writing custom token parsers for experimental protocols that have not finalized their liability shift frameworks with British clearing banks. Your immediate priority is structured data hygiene: expose clean inventory levels, configure accurate shipping rate tables, and ensure your bot mitigation rules do not throttle authenticated discovery agents.

If you run a bespoke or headless commerce architecture and need to architect your checkout for delegated machine transactions without compromising your security perimeter, partner with our team through our ecommerce development services. We audit your API gateway, review token routing, and establish resilient authentication boundaries that keep your checkout compliant as agentic standards reach production scale.

Frequently Asked Questions

The questions buyers and engineers ask us most about this topic.

What are agentic payments?

Agentic payments are transactions initiated and completed by autonomous AI agents on behalf of a human buyer. Unlike standard checkouts, the agent uses cryptographically restricted payment credentials, pre-authorised spending mandates, or scoped network tokens to settle orders without requiring human form completion.

Are agentic payments live for UK merchants?

Most agentic payment rails remain in closed pilot or US-only preview stages. While protocols like Google AP2 and Stripe Agentic Commerce Suite publish open technical specifications, UK deployment depends on payment gateways and clearing banks establishing formal liability shift mechanisms under UK Strong Customer Authentication regulations.

Who is liable for fraud when an AI agent makes a purchase?

The merchant remains the Merchant of Record. If the transaction uses verified network tokens (such as Visa agentic tokens) or signed AP2 mandates that authenticate the consumer upstream, liability generally shifts to the card issuer. If processed as standard card-not-present data without delegation proof, the merchant bears chargeback risk.