How AI agents pay: credentials, payment rails and settlement

On this page

Chapter 13 of The Hitchhiker's Guide to the Agentic Economy

Report hub · Previous: commerce protocols and checkout · In this chapter: nine payment states · route comparison · job example · payment record · Next: enterprise commercial relationships

Payment rails and commercial settlement

When an autonomous agent initiates a payment, it encounters two parallel financial systems operating under very different assumptions.

On one side, traditional payment networks are adapting human-centric rails for machine buyers. Visa's Trusted Agent Protocol and Intelligent Commerce framework introduce pass-through tokens, passkeys, and transaction risk signals for software agents. Mastercard’s Agent Pay for Machines specifies credentialing and network-level permission controls, while running controlled trials with CBA and Westpac cards in Australia (Mastercard Australian transactions). Stripe's shared payment tokens similarly bind access to a single seller, a stated dollar cap, and an expiration window, processing the transaction through standard merchant accounts (Stripe shared payment tokens).

The commercial advantage of these card-based approaches is immediate: they inherit decades of established merchant acceptance, chargeback processes, and automated feeds into enterprise general ledgers. The operational friction is cost and rigidity. Card interchange fees and human fraud-scoring models struggle with high-frequency, sub-dollar machine calls, leading to high transaction overhead and unpredictable false declines.

On the other side, native machine-payment protocols are building settlement directly into web requests. The x402 specification turns HTTP status 402 Payment Required into an automated challenge-and-response loop, settling requests over stablecoin networks like Base or Solana via exact and upto schemes (exact EVM scheme; upto Solana scheme; batch settlement). Similarly, the Machine Payments Protocol (MPP) establishes challenge and receipt conventions under an individual IETF Internet-Draft (IETF HTTP Payment draft).

These protocols solve request-time micro-payments with minimal latency and no prior account creation. But transferring digital value is only one step in commercial trade. For an enterprise finance team, an unauthenticated token transfer does not generate a tax-compliant invoice, match against an approved purchase order, or provide an enforceable remedy if the purchased API returned corrupted data.

The operational choice is not about protocol branding; it is about which party absorbs the risk when a transaction fails:

Key Takeaways

• Permission to buy, credential presentation, payment authorisation, initiation and settlement are separate events.
• Compare the complete route and the institutions behind it, not only the API or protocol at its front door.
• A success response must say what succeeded. An approved credential is not a charge; a processor acceptance is not settlement; settlement is not accepted work.
• Treat an ambiguous broadcast, delayed webhook or ledger mismatch as outcome_unknown. Reconcile the original attempt before creating another.
• Keep payment linked to the offer, order, delivery, acceptance, invoice and remedy through one Commercial Job Record.

The operational payment modes

Before selecting a payment protocol, an enterprise must clarify its commercial buying mode:

Commercial mode	Route to test first	Primary operational benefit	Critical requirement
Attended one-off purchase	Existing checkout with a one-time card, wallet credential or seller-scoped token	A person inspects the final seller, cart and amount; merchant and card systems retain familiar order and dispute paths	Exact approval, credential scope, seller charge, order, delivery and refund state
Bounded unattended purchase	Enforceable mandate or wallet policy plus the seller's accepted rail	Buyer enforces seller, purpose, amount, time and cumulative constraints before spend occurs	Policy decision, revocation, material-change handling and executed fields
First machine-to-machine call	x402 exact or MPP charge where both parties support a suitable method	A machine-readable 402 prices a bounded digital resource without prior account-first onboarding	Live quote, payment identifier, settlement, returned result and remedy
Variable or high-frequency service	Usage account, prepaid credit, x402 upto or batch settlement, or MPP authorisation	Bounded execution when final usage is unknown at request time or per-call settlement overhead is prohibitive	Auditable meter, ceiling, duplicate control, partial delivery and billing ledger
Repeat enterprise relationship	Account, contract, subscription or usage billing, invoice and agreed bank/card route	Procurement, tax, acceptance, credit, support and reconciliation survive across many jobs	Counterparty, contract, budget, order, invoice, acceptance, remedy and exit

The technical objective is not choosing the mechanism that looks most autonomous. It is choosing the route that executes the correct transaction once, reconciles into internal finance records, and preserves recourse when work fails.

For a low-volume Australian business starting without an agent-commerce stack, the practical baseline is an attended card purchase or an agreed invoice and bank-debit route with a qualified supplier. This minimizes custom wallet, custody, tax, and currency-conversion overhead. Native machine-payment protocols like x402 or MPP become advantageous when accountless, request-time settlement across machine APIs justifies the operational custody and ledger-reconciliation work.

A business needs nine payment states

Payment products use similar words for different events. A joined record needs explicit states:

1. Spend authority: A principal authorizes a specific agent, project, or task to spend up to a designated limit under defined conditions.
2. Credential issuance: An issuer creates a scoped token, virtual card, or signature key bound to that authorized limit.
3. Offer presentation: A merchant presents an itemized price, currency, payment terms, and delivery promise.
4. Payment authorization: The buyer’s issuer or wallet confirms funds are reserved and the transaction satisfies fraud and policy checks.
5. Execution initiation: The payment instruction is submitted to the clearing rail (e.g., card scheme, NPP/PayTo, or blockchain network).
6. Clearing / Asset transfer: The payment message traverses intermediate nodes or validators.
7. Settlement finality: Funds move irrevocably to the seller's account or on-chain address.
8. Tax and invoice matching: A formal tax invoice or receipt is issued and matched against the purchase order.
9. Reconciliation and remedy: The business confirms the delivered service matched the invoice, closing the accounting record or initiating dispute and refund procedures.

This institutional chain is why “rail” is too narrow a concept. A rail moves value. A protocol describes a challenge or receipt. A commercial payment route depends on funding, merchant acceptance, identity, risk controls, settlement, accounting, and recourse.

Route comparison across commercial layers

The following table evaluates current payment implementations across the complete commercial route:

Route	Authority and credential	Merchant acceptance and settlement	Recourse and repeat fit	Operating boundary
Card plus network or shared agent token	An issuer, scheme, wallet or provider creates a seller-, amount-, currency- or time-scoped credential; the underlying cardholder relationship remains relevant	Uses card merchant/acquirer acceptance and established processor, payout and ledger events	Card refund and dispute processes remain available under the underlying card and processor configuration; accounts and subscriptions sit beside the token	Visa and Mastercard agent programmes and Stripe shared payment tokens require participating providers, issuers, or merchants (Visa Intelligent Commerce; Visa Trusted Agent Protocol; Mastercard Agent Pay for Machines; Stripe shared payment tokens)
Buyer wallet or one-time virtual card	A customer approves a spend request and receives a short-lived credential	A virtual card uses standard online card acceptance; seller retains its own order and payment record	Useful for attended buying and familiar recourse; weak as a standing enterprise account	Stripe documents Link CLI with transaction-specific approval and limits; primarily configured for consumer checkouts rather than an enterprise procurement mandate (Stripe Link CLI; spend requests)
Bank or account-to-account payment	Account owner authorises a debit agreement, approves a transfer or grants a governed account role	Bank or real-time payment infrastructure moves fiat and supplies status/reference data	Built for repeat accounts and invoices; remedy depends on scheme, bank, contract and law	In Australia, PayTo documents one-off, ad hoc and recurring agreements that customers view and manage; a PayTo agreement governs debits, not an agent's authority to order or accept work (Australian Payments Plus, PayTo FAQs)
x402 over a stablecoin or other supported asset	The server returns a machine-readable requirement; the client signs a requirement binding fields such as amount, asset, network, recipient and expiry	A facilitator or server verifies and settles through the selected network; exact, up-to and batch schemes allocate timing differently	Reduces account setup for bounded digital calls; the core protocol does not supply card-network chargebacks, so refund or credit terms must be defined in the application layer	x402 v2 specifies the HTTP interaction; wallet funding, buyer policy, service quality, invoice generation and general remedy remain application responsibilities (x402 v2 specification; exact EVM scheme; upto Solana scheme)
Machine Payments Protocol	HTTP payment authentication carries a challenge, a method-specific credential and a receipt; methods can use different rails	Settlement and finality are method-defined, allowing card, Stripe or stablecoin methods to inherit different operations	Expresses charge, authorise and subscription intent patterns; business terms, invoice and acceptance remain application-level	The HTTP Payment authentication scheme is an active individual Internet-Draft; method support must be verified per implementation (IETF draft; MPP specifications)
Invoice plus card or bank collection	Contract, account, purchase order and finance approval determine what is payable	Processor or bank collects against an invoice; virtual accounts and references support matching	Designed for commercial credit, tax records, adjustments and repeat suppliers	An invoice marked paid is an accounting state, not proof that the agent was authorized or the service accepted (Stripe Invoicing; Stripe bank-transfer reconciliation; ATO eInvoicing)

Traditional rails adapt to software buyers

Card networks, processors, wallets, and banks maintain institutional relationships built over decades: funded accounts, merchant acceptance, fraud controls, refunds, disputes, reporting, and customer service. Agent-specific credentials narrow how those rails are used without replacing them.

Visa's Trusted Agent Protocol and Intelligent Commerce specify agent recognition, pass-through tokens, passkeys, consumer instructions, and transaction risk signals. Mastercard's Agent Pay for Machines specifies credentialing and permission controls, corroborated by pilot commercial transactions in Australia (Mastercard Australian transactions).

Stripe's shared payment token restricts exposure by generating a grant tied to an authorized seller, amount, currency, and expiry, processed through the seller's standard Stripe checkout. This avoids raw credential exposure while preserving existing merchant account and payout rails.

The commercial pattern is clear: modern agent interfaces can operate above existing financial rails while the enterprise ERP and merchant payment gateways remain the authoritative system of record.

Request-time settlement via x402

The x402 protocol turns the standard HTTP 402 Payment Required status into a direct settlement mechanism. When an agent requests a protected resource without payment, the server returns the cost, accepted asset, network, recipient address, and expiry. The client signs the requirement and retries the request with a payment payload. A facilitator or on-chain contract verifies settlement and unlocks the response (x402 v2 specification).

The protocol's v2 specification separates transport-independent types from network and scheme bindings, defining three core flows:

• Authorization flow: Verify credentials, execute the resource, settle payment, return response.
• Upfront flow: Settle payment first, execute the resource, return response.
• Escrow flow: Commit an authorization hold or ceiling, execute the task, and settle final consumption.

Scheme variations allocate risk differently: exact fixes the transaction total; upto allows signing a maximum ceiling where the seller settles actual metered usage; and batch settlement exchanges commitments prior to on-chain redemption.

This architecture is effective for low-friction digital resource monetization: web scrapers, data feeds, and specialized LLM inference endpoints. It eliminates user accounts, API keys, and pre-negotiated contracts. However, because settlement on public blockchains is irrevocable, error recovery requires explicit application design: escrow holds, programmatic refunds, or reputation staking.

MPP: an authentication envelope across payment methods

The Machine Payments Protocol models payment as an extension of standard HTTP authentication: servers challenge requests with WWW-Authenticate: Payment, clients respond with Authorization: Payment, and servers return structured payment receipts. The specification models charge, authorize, and subscription intents across multiple underlying payment methods.

This provides a common interaction envelope while allowing merchants to support diverse settlement rails. However, "MPP support" does not specify the underlying clearing rail, finality timeline, or dispute rules; those depend on the specific method profile implemented. The related HTTP Payment authentication draft remains an active individual Internet-Draft rather than an approved IETF standard.

Delegated authority sits above the payment rail

A technically valid payment credential proves that funds can be drawn. It does not establish that the corporate principal authorized the specific purchase, vendor, or outcome.

Unattended corporate purchasing requires an explicit mandate defining ten parameters:

1. Legal principal and corporate cost-center account.
2. Authorized agent workload and container instance.
3. Approved merchant identities, domains, and service categories.
4. Business task objective and required deliverable schema.
5. Per-transaction and cumulative spending limits.
6. Permitted currencies, stablecoin assets, and network fee caps.
7. Explicit start, expiration, and instant revocation timestamps.
8. Permitted price variance thresholds requiring re-authorization.
9. Data access and disclosure restrictions.
10. Designated human owners for exception reconciliation and dispute remediation.

Standards like AP2 v0.2 bind user intent to signed checkout and payment mandates for human-present and human-not-present execution. Similarly, Australian PayTo agreements govern account debit rules, while wallet spend policies establish financial ceilings. These mechanisms govern payment authority; they do not evaluate deliverable quality or confirm business acceptance.

Three payment routes for AE-JOB-001

The reference competitor briefing (AE-JOB-001) illustrates how commercial context dictates payment rail selection:

Route A: Attended card or wallet purchase

The agent obtains an itemized quote. An analyst reviews the supplier, task scope, and exact A$750 cost. A corporate wallet issues a merchant-scoped virtual card or shared payment token. The seller charges the credential via its standard processor, creating a confirmed order.

The system logs the approval digest, virtual card token, processor charge ID, and order receipt. The transaction is marked paid only after the processor confirms the capture; issuing a credential is not a payment event. This route suits initial supplier engagements, inheriting standard card dispute windows and fraud protections, but requiring human sign-off.

Route B: Contracted enterprise supplier with invoice matching

The enterprise pre-qualifies the research provider, negotiates master terms, and issues a purchase order. The agent commissions briefings within the contracted catalog and budget limits. Upon delivery, an internal analyst reviews the brief. The supplier issues a structured tax invoice, which accounts payable matches against the purchase order and delivery receipt before settling via direct bank debit.

In an Australian deployment, PayTo can automate pre-authorized account debits while Peppol exchanges machine-readable tax invoices directly between accounting platforms. This route requires upfront supplier onboarding, but supports commercial credit terms, statutory tax compliance, and volume discounts across recurring enterprise jobs.

Route C: Bounded machine purchase via x402 or MPP

The supplier exposes an automated competitor research API. The server returns an HTTP 402 challenge specifying cost (e.g., 25 USDC on Base), output schema, and deadline. A deterministic policy service verifies that the cost is within the A$25 research budget cap and the target domain is approved. The wallet signs the payment requirement. The agent retains the unique payment identifier across retries, receives the raw data, and triggers automated validation checks.

This route eliminates vendor onboarding overhead for low-value digital inputs. However, it requires corporate crypto wallet custody, tax accounting for digital asset disposals, and application-level refund logic if the endpoint returns corrupted data.

Evaluating route trade-offs

Commercial condition	Attended card / Virtual token	Contracted supplier & invoice	Request-time machine payment (x402/MPP)
First purchase from new vendor	Human analyst inspects exact charge; standard merchant fraud controls apply	Supplier onboarding overhead is disproportionate for one-off task	Frictionless, but counterparty identity and data quality require strict local verification
Recurring monthly engagement	Repeated manual approvals add unnecessary labor overhead	Ideal: master contract governs ongoing budgets, credit, and service levels	Requires managing continuous wallet balances or high-frequency micropayments
Variable metered execution	Requires pre-authorization holds and complex incremental capture logic	Ideal: metered consumption aggregates onto a monthly consolidated invoice	upto or batch schemes fit well if the seller's meter is auditable
Dispute and fraud protection	Scheme dispute rights, chargebacks, and corporate card insurance apply	Contractual dispute clauses, payment holds, and commercial arbitration apply	Irrevocable on-chain settlement; refunds require out-of-band bilateral resolution
Australian domestic compliance	Established card acquiring; GST itemization on receipts	PayTo direct debits and Peppol eInvoicing provide seamless domestic tax compliance	Asset conversion, capital gains/loss tracking, and lack of statutory tax invoicing

Settlement finality, retries and recourse across rails

The term settled carries distinct operational meanings across rails:

Rail classification	Verification required before treating value as settled	Deterministic retry protocol following timeout	Primary dispute and recourse mechanism
Payment card / Network token	Processor authorization and capture receipt; merchant bank payout occurs asynchronously	Query processor API using original payment intent ID before creating new charge	Merchant refund, followed by formal scheme chargeback through issuing bank
Bank account / Direct debit	Bank confirmation, reference match, and clearing ledger entry	Query bank API and internal virtual account ledger before re-initiating transfer	Contractual credit adjustment, bank recall request, or formal commercial arbitration
Stablecoin x402	Transaction hash confirmed by network validators or signed facilitator settlement receipt	Query payment identifier against chain or facilitator; never retry based solely on client timeout	Bilateral merchant refund; application-level escrow hold; zero native network chargebacks
MPP protocol method	Method-specific receipt confirmed by underlying processor (card, bank, or crypto rail)	Query method provider using logical task ID and idempotency key	Governed by the underlying rail and merchant terms of service

Credential custody requires strict operational isolation: private keys, full primary account numbers (PANs), and master bearer tokens must reside exclusively inside specialized HSMs or credential vaults. Ephemeral agent workloads should receive only short-lived, transaction-scoped tokens.

The Payment and Settlement Record

Production systems maintain an explicit operational record linking financial settlement to business delivery:

Payment and Settlement Record
  job_id and offer/order references
  payer principal and payee/seller identity
  authority or mandate reference and policy result
  credential type, issuer/provider, scope and expiry
  protocol, method, rail, asset/currency, network and version
  authorised amount, final amount, fees, tax/FX references
  logical payment_id and append-only attempt_ids
  processor/facilitator/bank/network responses and timestamps
  settlement reference, state and finality meaning
  invoice, balance transaction and ledger references
  delivery and acceptance references
  refund, credit, dispute, chargeback or reconciliation case
  current owner, next action and evidence checked time

Operational invariants

1. Every payment attempt must reference an accepted commercial offer and an active authority mandate.
2. Any material modification to seller identity, currency, network asset, or deliverable scope automatically invalidates prior payment authorization.
3. Every retry attempt must explicitly declare whether it polls a pending transaction, resumes an existing hold, or initiates a new payment.
4. credential_issued, payment_authorized, funds_settled, artifact_delivered, work_accepted, and ledger_reconciled represent distinct operational states that must not be conflated.
5. Private signing keys, raw card numbers, and master API tokens must never enter model prompts, context stores, or unencrypted trace logs.
6. Refunds, credit adjustments, and chargebacks append to the original job record without overwriting historical transaction logs.
7. A commercial job cannot transition to reconciled until finance matches the authority mandate, merchant order, payment receipt, tax invoice, and deliverable acceptance sign-off.

Ambiguous payment outcomes as first-class states

In distributed networks, transactions frequently terminate in ambiguous states: a client times out after a card processor captures funds; a stablecoin transaction broadcasts but remains unconfirmed in a mempool; an automated webhook is delayed; or a bank wire clears without a customer reference.

The x402 v2 specification designates settlement_pending as an explicit non-terminal status, allowing the client to poll settlement state using a transaction hash. The x402 payment-identifier extension provides a unique ID that survives retries across payment facilitators.

When network timeouts or status discrepancies occur, systems must enforce a strict reconciliation protocol:

response missing or records disagree
  -> transition payment state to outcome_unknown
  -> query provider, network or bank ledger using stable payment_id
  -> if transaction committed: retrieve receipt and attach to job
  -> if transaction failed: log provider error code and close attempt
  -> if status remains uncertain: assign reconciliation owner and hold workflow
  -> create a new payment attempt only after duplicate charge risk is eliminated

Blindly retrying an unconfirmed payment after an HTTP timeout is a critical operational failure that regularly causes duplicate balance-sheet charges.

What current payment evidence establishes

Evaluating payment infrastructure requires matching evidence types to the operational claims they support:

Evidence source	What it establishes	Unresolved operational question
Card network protocol (Visa, Mastercard)	Specifications for agent-scoped tokens and fraud risk signals	Merchant acquiring adoption, sub-dollar transaction costs, and live Australian volume
Machine payment spec (x402, MPP)	HTTP challenge-response flows, payment payloads, and receipts	Statutory tax compliance, enterprise ERP integration, and automated dispute resolution
Merchant token API (Stripe Link / SPT)	Developer APIs for issuing scoped virtual tokens and spend requests	Enterprise procurement governance, multi-vendor interoperability, or B2B invoicing
Banking rails (PayTo, Peppol)	Enforceable real-time debit mandates and structured business document exchange	Autonomous agent decision authority, task deliverable quality, or cross-border clearing
On-chain transaction hash	Public verification that digital tokens transferred between addresses	Underlying commercial purpose, vendor identity, deliverable delivery, or tax compliance
Processor authorization receipt	Confirmation that funds were reserved on a card or credit line	Settlement finality, merchant fulfillment, or deliverable acceptance

The trajectory of agentic settlement

Payment infrastructure will not collapse into a single universal rail. Instead, the market is organizing into complementary operational channels:

• Low-value, high-frequency digital resources (web scraping, API calls, inference queries) will tilt toward native HTTP micropayments (x402, MPP) settling over stablecoins and fast layer-2 networks.
• Consumer purchases and mid-value business software subscriptions will leverage agent-specific network tokens issued by Visa, Mastercard, and Stripe, preserving established chargeback and fraud protections.
• Large recurring enterprise transactions will remain anchored to bank debit agreements (PayTo), master contracts, and structured eInvoicing (Peppol), using agent interfaces to automate order intake and three-way invoice matching.

Every payment transaction operates within a broader corporate supplier relationship. Chapter 14 examines enterprise commerce: supplier qualification, master service agreements, delivery acceptance, invoicing workflows, and ongoing relationship governance.

Sources and method

• Primary sources: Technical specifications, developer documentation, and API guides from Visa (Trusted Agent Protocol, Intelligent Commerce), Mastercard (Agent Pay for Machines), Stripe (Link CLI, Shared Payment Tokens, Invoicing), x402 Foundation (v2 specification, exact/upto schemes, payment-identifier extension), Tempoxyz (Machine Payments Protocol), IETF (HTTP Payment authentication draft), Australian Payments Plus (PayTo), and the Australian Taxation Office (eInvoicing) checked as of 13 September 2026.
• Analytical frameworks: The Nine Payment States Model, the Route Comparison Matrix, the Three-Route Architecture for AE-JOB-001, and the Payment and Settlement Record are original analytical structures developed to evaluate agent payment governance.
• Evidence boundaries: Specifications establish protocol mechanics, payload schemas, and declared features. Production transaction volume, merchant acceptance density, and unit economic margins require empirical validation on customer workloads.
• Institutional references: Australian regulatory and banking frameworks (PayTo, NPP, ATO eInvoicing) provide the domestic context for real-time payments and tax compliance.
• Editorial record: Published by Agentic Economy, Perth, Western Australia. Updates and corrections are logged via the editorial record.

Back to the report hub · Previous: commerce protocols and checkout · Next: enterprise commercial relationships.