The four-party card model is usually drawn as a settlement loop: consumer, merchant, acquirer, issuer, with a network in the middle. For agentic payments, it is more useful to see it as a layered trust system.
Each participant asks a security question:
- Merchant: should this session be allowed to reach checkout?
- Acquirer: does this transaction fit the merchant and payment profile?
- Network: does this behavior fit broader card and merchant patterns?
- Issuer: should the cardholder’s account approve this payment?
Those questions were built around a human being present in real time. Agent payments break that assumption at the root.
Every layer reads a version of human presence. Agent payments rebuild those reads with cryptographic evidence.
The network no longer relies only on behavior. It compares the authorization message with a consumer-authorized instruction registered before checkout.
Layer 1: merchant and gateway
The gateway filters automated traffic before payment. CAPTCHAs, WAF rules, device fingerprints, mouse movement, residential IP reputation, and request velocity all exist to stop card testing and credential stuffing.
A legitimate shopping agent can have the same external shape as hostile automation: cloud origin, programmatic browsing, fast request timing, and no human motion signal. The fix is not a better CAPTCHA. The fix is changing the question from “does this look human?” to “did a registered agent sign this request?”
That is why TAP, Web Bot Auth, and AP2-style request evidence all converge on signed messages. Public-key signatures make the request attributable. Nonces and timestamps make it fresh. Body digests make tampering visible.
Layer 2: acquirer and processor
If the request reaches payment, the acquirer still sees a card-not-present authorization. The problem is that legacy payment messages were not designed to explain that a software agent is acting under prior consumer authorization.
The replacement is not a new rail. It is richer context around the same rail:
- tokenized credential instead of raw PAN exposure;
- registered agent identity;
- instruction, mandate, or policy reference;
- merchant, amount, category, and revocation context.
Public network documents do not currently give one universal ISO 8583 field map for agentic commerce. Any field-level diagram should be labeled as illustrative unless it comes from a published network specification.
Layer 3: network
The network sees cross-merchant behavior that no single merchant or issuer sees. That is valuable, but it also means machine-speed checkout can resemble the attack patterns those systems were built to catch.
The missing signal is prior intent. A legacy authorization does not, by itself, prove the consumer already authorized this merchant, amount, item, and agent.
Agentic payments add an evidence object before checkout: an instruction, mandate, or token-bound intent. When authorization happens, the payment stack can compare the live transaction against that evidence instead of relying only on behavioral inference.
Layer 4: issuer
The issuer is still the final authorization decision maker. In human checkout, ambiguous risk can trigger 3DS or banking-app step-up. In delegated commerce, live step-up is often the wrong fallback. If every useful agent purchase needs a real-time user challenge, the delegation failed.
The replacement is pre-authorized policy: amount caps, category limits, merchant constraints, velocity, expiration, token status, and revocation. Passkeys and other strong authenticators matter because they move authentication to enrollment or instruction time, where the consumer is actually present.
The issuer’s question changes from “is the cardholder here right now?” to “does this transaction fit a policy the cardholder already authorized?”
The four primitives
Where the VIC architecture post maps Visa’s three building blocks — VIC API, TAP, and DCAP — this post maps the four trust primitives any agent payment system has to rebuild, regardless of network or protocol. They are composable requirements, not a Visa-specific stack.
Cryptographic agent identity. A verifier accepts the request because an accountable agent signed it, not because it resembled a human session.
Agent-bound credential. A payment credential should be scoped to the agent and context that received it. A stolen token without the agent’s key or authorization context should not be sufficient.
Registered instruction or mandate. The payment system needs an object that says what the consumer authorized before checkout.
Pre-authorized spending policy. Issuers, wallets, or networks need deterministic rules that can be checked without waking the user at transaction time.
Those primitives are compositional. Identity without a scoped credential is not enough. A scoped credential without intent evidence is not enough. Intent evidence without issuer policy still collapses into step-up when risk rises.
Products differ in packaging. The architecture keeps converging on the same replacements.
The request is signed over method, authority, path, digest, timestamp, and nonce.
The credential only works when presented by the agent identity it was issued to.
The network compares the authorization message against the consumer-authorized instruction.
The issuer enforces deterministic rules created before the transaction.
Illustrative ISO 8583 mapping: entry context, additional data, and private-use fields can carry agent evidence downstream.
Token-first design. More of the binding lives in token metadata and edge verification.
Strong instruction evidence. Card credential binding depends on the payment method extension.
Excellent for internet-native settlement. Regulated card-style policy still needs companion identity and authorization layers.
What the rails do not have to change
The easiest mistake is to assume agent payments require new payment rails. They do not.
Card authorizations can still travel through merchant, acquirer, network, and issuer infrastructure. Clearing, settlement, refunds, disputes, and merchant acquiring remain the durable parts of the system. The new work is around proof: what the agent signed, what the consumer authorized, which credential was released, and what evidence remains after the order.
Stablecoin and HTTP-native protocols solve a different problem: internet-native payment and programmable settlement. That can be powerful for API calls and agent-to-agent commerce, but it does not automatically recreate issuer policy, consumer dispute handling, network tokenization, or chargeback evidence.
Enrollment and instruction carry the hard trust work. Authorization becomes evidence matching plus policy enforcement.
$500 limit, allowed MCCs, velocity, revocation rules.
VCN, Agentic Token, or payment-method extension.
Directory entry lets merchants verify future requests.
Merchant, amount, item, agent, expiration, policy context.
Integrity hash becomes the object later carried in the authorization.
RFC 9421 signature covers method, authority, path, digest, timestamp, nonce.
TAP SDK, Web Bot Auth at edge, or equivalent verification path.
The standard card rails stay in place. The message fields change.
Amount and merchant tampering fails before issuer routing.
Limit, category, velocity, token status, revocation. No 3DS fallback.
Still unsolved
Multi-agent delegation. If a planning agent delegates the purchase to a subagent, the evidence chain needs to show who held authority, who executed, and which policy applied.
Cross-network identity. A Visa-recognized agent and a Mastercard-recognized agent are not automatically the same principal. Shared directories are technically possible and commercially hard.
Dispute evidence. A chargeback file for an agent workflow needs richer proof than a normal ecommerce session: original instruction, agent request, merchant response, fulfillment, refund, revocation state, and user-visible consent.
PSD2 Strong Customer Authentication. Existing European SCA guidance predates autonomous checkout and does not yet give a clean, agent-specific answer for delegated card transactions.
Sources
- ISO 8583:1987 standard page
- Visa: What is agentic commerce?
- Visa: Trusted Agent Protocol announcement
- Visa Trusted Agent Protocol GitHub repository
- Mastercard Agent Pay launch
- RFC 9421: HTTP Message Signatures
- Web Bot Auth IETF draft
- Google Agent Payments Protocol
- x402 protocol
- FIDO Alliance Payments Working Group