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

Our view

There is no default “agentic payment rail”. Cards, bank payments, wallets and stablecoins move value under different rules. Shared payment tokens, network agent tokens and one-time cards constrain credentials in different ways. x402 and the Machine Payments Protocol make payment requests machine-readable, but neither turns a payment into a complete commercial relationship.

The useful decision is a route through five requirements: the buyer's authority, merchant acceptance, settlement evidence, finance reconciliation and an appropriate remedy when the job fails. A technically elegant route can still be commercially wrong if the buyer cannot fund it, the seller cannot accept it, finance cannot reconcile it or the customer has no realistic recourse.

Key Takeaways

• Permission to buy, credential presentation, payment authorisation, initiation and settlement are separate events.
• The complete payment route includes 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.
• Ambiguous broadcasts, delayed webhooks and ledger mismatches create an outcome_unknown state until the original attempt is reconciled.
• Payment records remain distinct from the offer, order, delivery, acceptance, invoice and remedy records around the same job.

This chapter compares official specifications, scheme material, provider documentation and government sources checked on 13 September 2026. Product availability, preview status, network coverage and draft specifications can change. No account was created, wallet funded, credential issued or payment executed for this research.

Sources and scope

Agentic Economy compared the documented function and boundary of each route. A specification establishes specified behaviour. Provider documentation establishes documented supply. A launch, partner list or provider-reported transaction establishes a reported event, not independent adoption. This chapter does not rank providers, estimate market share or claim that one route is suitable for every jurisdiction. About Agentic Economy explains the publication. Corrections can be submitted through the contact page.

No single agentic payment rail is emerging

Payment infrastructure is developing along two paths. Card networks, wallets and payment processors are extending existing rails with agent recognition, transaction-scoped credentials and richer intent signals. Machine-payment protocols such as x402 and MPP are creating request-time payment interactions for APIs and digital services, often using stablecoins or provider-specific methods.

Mastercard calls Agent Pay its “initial steps in redefining commerce in the AI era” (Mastercard, "Mastercard unveils Agent Pay"). Those steps build on network tokenisation rather than replacing the card system. Visa is taking a parallel path through agent recognition, passkeys and transaction signals. The payment networks are treating the agent as a new actor on established rails.

Enterprise commerce continues to use accounts, invoices, bank payments, cards and existing billing systems. These routes already support recurring relationships, credit, tax records and reconciliation. The newer agentic layers make software-initiated payment easier, but they do not replace the institutions that accept, settle and remedy a transaction.

Our view is that the market will support several routes. Cards and account-based payments will absorb agent features; x402 and MPP will develop around accountless and machine-native services; enterprise commerce will continue to favour contracted relationships and established finance systems.

A business needs nine payment states

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

For this guide, payment rail is the network or account system that moves value, such as a card network, bank transfer system or blockchain. Payment protocol is the message pattern that carries a request, credential or receipt. Payment credential is the scoped instrument presented to a seller, processor, bank or network. Settlement means the point at which the method says the seller has received final or usable value; that meaning varies by method.

State	Question	Evidence	What it does not prove
1. Commercial intent	What did the buyer mean to buy, from whom and why?	Accepted offer, cart or scope and job_id	That the buyer was allowed to buy it
2. Delegated authority	Which principal allowed which agent to spend under what limits?	Policy decision, approval, mandate or purchase order	That a usable credential exists
3. Credential	What can be presented to the seller or payment system?	Scoped token, one-time card, wallet signature, bank mandate or account authority	That a charge was attempted or accepted
4. Payment authorisation	Did the relevant issuer, wallet, bank or policy system accept the proposed payment?	Authorisation or verification result	Final movement of value or delivery
5. Initiation	Was a particular transfer or charge submitted once?	Attempt ID, idempotency key and timestamp	Clearing, confirmation or finality
6. Clearing or transfer	Which network or processor carried the instruction and with what status?	Network, processor or on-chain reference	That seller and buyer ledgers agree
7. Settlement	When did the seller obtain final or usable value under this method?	Settlement, payout, confirmation or bank event	That the promised work was accepted
8. Ledger and invoice	How did buyer and seller account for the amount, fees, tax and credit?	Balance transaction, invoice, credit note and internal entries	That every external event matched automatically
9. Reconciliation or remedy	Do the records agree, or what correction remains open?	Matched record, exception case, refund, dispute, chargeback or credit	That the wider relationship will repeat

The owner can differ at every layer. The buyer owns its purpose and policy. A wallet or credential provider may own issuance. An issuer, bank, processor, facilitator or blockchain records payment events. Seller and buyer finance systems own their ledgers. Operations owns delivery and acceptance. Support, a network, a bank, an arbitrator or a court may own part of the remedy.

That institutional chain is why “rail” is too narrow. A rail moves value. A protocol can describe a challenge, credential or receipt. A commercial payment route also depends on funding, acceptance, identity, risk controls, settlement, accounting and recourse.

Compare complete routes, not protocol labels

The table below records current documented supply. It is not a claim of equal maturity, availability or adoption.

Route	Authority and credential	Merchant acceptance and settlement	Recourse and repeat fit	Current 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 may remain available under the underlying card and processor configuration; accounts and subscriptions can sit beside the token	Visa and Mastercard agent programmes and Stripe shared payment tokens require participating providers, issuers, merchants or previews; availability is not universal (Visa Intelligent Commerce; Visa Trusted Agent Protocol; Mastercard Agent Pay for Machines; Stripe SPT detail)
Buyer wallet or one-time virtual card	A customer approves a spend request and receives a short-lived credential	A virtual card can use ordinary 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 for US consumers, with transaction-specific approval and limits; that is not an Australian consumer route or a general 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	Can support 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 can 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	Can reduce account setup for bounded digital calls; the core protocol does not supply card-network chargeback, so refund or credit terms must be defined separately	x402 v2 specifies the interaction, but wallet funding, buyer policy, service quality, invoice and general remedy remain outside core (x402 v2 specification; exact EVM scheme; upto EVM scheme; batch-settlement 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, so a card, Stripe or stablecoin method can inherit different operations	Can express charge, authorise and subscription intent patterns; business plan, invoice and acceptance stay application-level	The HTTP Payment authentication scheme is an active individual Internet-Draft with no formal IETF standing at this cutoff; method support must be pinned and tested (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 can support matching	Can support credit, tax records, adjustments and repeat suppliers	An invoice marked paid is an accounting/payment state, not proof that the agent was authorised or the service accepted (Stripe Invoicing; Stripe bank-transfer reconciliation; ATO eInvoicing)

Existing rails do not become obsolete when the buyer is software

Card networks, processors, wallets and banks carry relationships accumulated over decades: funded accounts, merchant acceptance, risk controls, refunds, disputes, reporting and customer support. Agent-specific credentials can narrow how those rails are used without replacing them.

Visa's current Trusted Agent Protocol and Intelligent Commerce material describes agent recognition, pass-through tokens, passkeys, consumer instructions and transaction signals, while warning that products are still being developed or deployed and may not be available in every market. Mastercard's Agent Pay for Machines material describes credentialing, permissioning and network controls; Mastercard separately reports a controlled Australian trial. Those sources establish programme design and reported events, not an independent denominator for production use.

Stripe's shared payment token is deliberately scoped. Its documentation describes a grant tied to a seller, amount, currency and expiry, used by the seller through existing Stripe payment processing. That reduces raw credential exposure. It does not encode a purchase order, continuing contract, service level or acceptance test.

The pattern is commercially important: a new agent interface can sit above familiar rails while the existing seller and finance systems remain authoritative. The agent does not need a new currency merely because it is software.

x402 is useful because it is narrow

x402 turns HTTP 402 Payment Required into a request-time payment exchange. A server returns one or more payment requirements. A client checks the resource URL and the requirement's amount, asset, network, recipient and expiry; signs a selected requirement; and retries. A facilitator or server verifies and settles. The successful response can carry settlement information and the resource (x402 v2 specification).

That is well suited to a bounded API, data, compute or tool call where creating an account costs more than the transaction. The protocol's v2 specification separates transport-independent types from network and scheme bindings. It also distinguishes payment flows:

• Authorisation flow: verify, perform the resource, settle, respond. The seller may perform work before final settlement.
• Upfront flow: settle, perform the resource, respond. The buyer may pay before knowing whether the resource completes.
• Escrow flow: commit a deposit or ceiling, perform work, then settle the final amount.

The schemes also change the risk. exact fixes the amount. upto lets the buyer sign a ceiling and the seller settle an amount at or below it, which makes the seller's meter material. Batch settlement can exchange commitments before final redemption, which means access granted and final movement of value are separate events.

x402 does not automatically provide the funded wallet, buyer policy, catalogue, legal counterparty, tax calculation, invoice, service acceptance, refund policy or chargeback. Its narrowness is not a defect. It is a reason to locate it correctly in the stack.

MPP is an envelope across methods, not one rail

The Machine Payments Protocol uses the familiar HTTP authentication pattern: a server returns WWW-Authenticate: Payment, the client fulfils a method and retries with Authorization: Payment, and the server returns a payment receipt. Its specifications describe charge, authorise and subscription intents and method profiles for different payment systems.

That abstraction can let machine clients use a common interaction while sellers retain different settlement methods. It also means “MPP support” does not answer which credential, processor, finality, refund or dispute rules apply. The method profile and its implementation are part of the claim.

At the research cutoff, the related HTTP Payment authentication document was an active individual Internet-Draft, not an approved IETF standard. Describing it as open or on the IETF track should not be shortened to “IETF standard”.

Delegated authority sits above the payment method

A valid credential proves that some credential can be used under its technical rules. It does not prove that the principal intended this supplier, purpose or result.

An unattended buyer needs a policy or mandate that can answer at least:

• which legal or account principal owns the budget;
• which agent or workload may propose the purchase;
• permitted supplier, domain, category and geography;
• purpose and required output;
• per-purchase and cumulative amount limits;
• currency, asset, network and fee limits;
• start, expiry and revocation;
• whether quantity, price, tax, shipping, recipient or delivery changes require approval;
• which data may be disclosed; and
• who can stop, reconcile and remedy the job.

AP2 v0.2 specifies signed intent, checkout and payment mandates for human-present and constrained human-not-present commerce. It can help bind represented buyer intent to a checkout and payment. It does not provide the catalogue, checkout API, payment rail, contract or dispute institution. A PayTo agreement can authorise debits under visible terms. It does not decide whether an agent should place or accept the underlying order. A wallet spend policy can cap value. It does not judge whether the delivered result met the buyer's promise.

The right composition is authority above credential, credential above payment attempt, and payment evidence linked back to the authorised job.

Three payment routes for AE-JOB-001

AE-JOB-001 is the guide's synthetic example: a Perth advisory firm asks an agent to commission one competitor briefing from an external supplier. The output must cover five named competitors, cite approved sources, arrive within one business day and pass analyst review. It is illustrative, not a real purchase or quoted market price.

The same job can use several payment routes. The commercial relationship changes which route is sensible.

Route A: attended card or wallet purchase

The agent obtains a current offer and final checkout. A person reviews the supplier, scope and exact amount. A wallet issues a seller-scoped shared payment token or one-time virtual card. The seller charges through its ordinary processor and creates an order.

Retain the approval digest, credential reference, seller charge, processor attempt, order, delivery and any refund or dispute reference. Do not mark the job paid when the credential is approved or issued. Stripe's Link documentation, for example, separates a spend request's approval from a successful merchant transaction.

This route fits a first purchase when human review is proportionate and the seller accepts the chosen provider. It inherits card reach and recourse, but also issuer declines, authentication, seller enablement and geographic product limits.

Route B: contracted account with invoice and bank or card collection

The buyer first qualifies the supplier, agrees terms and creates an account or purchase order. The agent orders a briefing within the approved catalogue and budget. The supplier records delivery; the analyst accepts or rejects it; the supplier issues a structured invoice; finance matches the invoice to the job and payment.

For an Australian relationship, PayTo could govern authorised account debits and Peppol could carry structured order or invoice documents where both parties use participating systems. Neither is the agent's authority to order, and neither makes payment equal acceptance. The contract and job record supply those links.

This route requires supplier and account onboarding. It can support credit, negotiated terms, tax records, service levels and exceptions across repeat purchases; whether that produces better economics is a fact to test with accepted-job and cost records.

Route C: bounded machine purchase using x402 or MPP

The supplier exposes a versioned digital briefing service. The runtime response states the amount, method, output schema, expiry and resource. A deterministic policy service—not the language model—checks the supplier, route, amount, recipient, cumulative budget and data boundary. The wallet signs or presents a narrowly scoped credential. The client retains one payment identifier across retries, obtains settlement evidence, receives the report and runs the acceptance test.

This route is a hypothesis for reducing account setup on a first call, not an observed friction result. It can instead add wallet funding, custody, asset conversion, tax/FX, seller-acceptance and remedy work. A stablecoin method does not inherit card-network chargeback by default; remedy depends on the asset, provider and contract. An MPP method may inherit card or Stripe operations, but only if that method and seller integration are actually enabled. Neither route creates an enterprise relationship by itself.

The route decision

Job condition	Attended card/wallet	Contract and invoice	Machine payment
First purchase from unknown supplier	Human can inspect exact purchase; provider and merchant controls apply	Onboarding cost may be excessive	Low friction, but identity, output and remedy need stronger buyer checks
Repeat monthly purchase	Repeated approval can add operating work	Can carry catalogue, budget, acceptance and credit across periods	Test an account, credits or invoicing against independent stateless payments
Variable final usage	Incremental authorisation or final charge logic required	Usage meter can feed invoice	upto, authorise or batch can fit if the meter and ceiling are auditable
Customer needs conventional dispute path	Card route may provide it	Contract, bank and provider remedies can be negotiated	Stablecoin route needs explicit refund/support; no default chargeback
Australian buyer	Check wallet, issuer and seller availability	PayTo/Peppol can become relevant	Check asset, network, custody, tax/FX and provider geography; no assumed local default

Settlement, retry and recourse by route class

The label settled must carry the method's meaning. This table is a control prompt, not a guarantee that any provider or institution will decide a case in the buyer's favour.

Route class	Evidence before treating value as usable	Retry rule after timeout	Primary adjustment or recourse path	Failure fixture before delegation
Card or network token	Seller/processor charge and captured or otherwise usable funds under the merchant setup; later payout is a separate event	Retrieve the original payment intent/charge and order before creating another attempt	Merchant refund, then card dispute/chargeback under issuer, scheme and processor rules where applicable	Approved credential but no charge; duplicate retry; capture failure; refund/dispute race; delivered-but-rejected job
Invoice and bank route	Invoice, payer/payee account, amount, reference and bank/ledger match; due and cleared do not mean accepted work	Search bank, invoice and virtual-account/reference records before asking the buyer to pay again	Contract correction/credit/refund, bank process and dispute forum named in the relationship	Missing reference; short/overpayment; duplicate transfer; invoice mismatch; rejected delivery after payment
Stablecoin x402	Facilitator/network result for the selected scheme, including pending versus final state and the recipient/asset/network actually used	Reconcile the logical payment identifier and chain/facilitator record; never resubmit from client timeout alone	Seller/provider refund or credit and contractual/support route; no default card chargeback	settlement_pending; wrong recipient/network; duplicate logical request; separate refund; settled-but-no-result
MPP method	Method-specific receipt plus the underlying card, bank or stablecoin provider's finality meaning	Retrieve the method/provider state and resource effect using one logical job/payment ID	The underlying method and seller contract determine refund, dispute and support	Challenge fulfilled but resource fails; delayed receipt; repeated credential; subscription/authorisation exceeds the application policy

Credential custody is a separate control. Private keys, reusable bearer tokens and full card credentials remain in the wallet, vault, issuer or signing service designed to hold them. The agent receives a scoped decision or one-time credential, while rotation, revocation and access logs remain available to the responsible security and finance owners.

The Payment and Settlement Record

The Payment and Settlement Record is an Agentic Economy editorial proposal. It is a linked view of the Commercial Job Record, not a payment standard, accounting ledger or substitute for provider records.

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

Operating invariants

1. Every attempt references one accepted offer and one current authority decision.
2. A material change to seller, resource, amount, currency or asset, network, recipient, delivery or acceptance invalidates the prior approval unless the mandate explicitly permits it.
3. Every retry declares whether it resumes the same attempt, checks a pending attempt or creates a new one.
4. credential_approved, payment_initiated, payment_settled, delivery_received, accepted and reconciled remain separate states.
5. Raw private keys, full card credentials and reusable bearer tokens do not enter model context or ordinary traces.
6. Refunds, credits, disputes, chargebacks and rework append to the original job; they do not erase it.
7. The job is not reconciled until finance can match authority, order or invocation, payment, invoice or ledger, and delivery or acceptance evidence.

Unknown is a first-class payment state

Distributed systems produce ambiguous outcomes. A client can time out after a processor accepts a charge. A stablecoin transaction can be broadcast but not confirmed. A webhook can arrive late or out of order. A bank transfer can reach an account without an invoice reference. A merchant can create an order while the client sees an error.

x402 v2 names settlement_pending as non-terminal. It can carry a transaction hash and network so the seller can reconcile before deciding whether to retry. The payment-identifier extension gives one logical request an identifier that survives retries. That helps at the payment boundary, but an ordinary idempotency key and atomic resource record are still needed for a non-idempotent business effect.

The safe pattern is:

response missing or records disagree
  -> preserve the original attempt and external references
  -> mark outcome_unknown
  -> query the authoritative processor, bank or network state
  -> compare merchant order, delivery and ledger
  -> resolve, remedy or escalate
  -> create a new attempt only after duplicate risk is closed

A retry policy that converts every timeout into a new payment can duplicate value. A seller policy that calls every unknown state a failure can withhold a result for a payment that later settles. Both are record design failures before they are agent failures.

Settlement does not close the customer job

A payment can settle and the report can still arrive late, omit a competitor, use prohibited sources or fail review. The buyer may request rework, credit or refund. A card dispute, stablecoin refund, invoice credit note and contractual service remedy are different operations with different evidence and deadlines.

Stripe's dispute documentation illustrates the institutional difference. The issuer decides a card dispute and evidence deadlines apply. Stripe's refund documentation describes a separate adjustment object and lifecycle. The x402 protocol does not supply a card-style chargeback, so a stablecoin refund or credit path must be specified by the chosen provider and contract. PayTo and bank-transfer invoicing have their own scheme, institution and contract paths.

Unattended spend exposes five unresolved questions on every route:

• What proves non-delivery or unacceptable delivery?
• Who can authorise a refund, credit, reversal or rework?
• Is the adjustment linked to the original job and settlement?
• Which deadline, evidence format and counterparty apply?
• What happens if payment and service disputes are open at the same time?

What the market has not resolved

The payment layer still lacks a portable representation of commercial authority that works across wallets, card networks, bank rails and machine-payment protocols. Credentials can become more specific, but the surrounding questions of buyer purpose, accepted delivery, tax and remedy remain distributed across other systems.

We expect the largest payment networks and processors to make agents legible inside existing commerce, while x402 and MPP establish a parallel route for machine-native services. The strategic contest will centre on credentials, acceptance and developer distribution rather than the settlement rail alone.

What the sources establish

Evidence	Establishes	Does not establish
Versioned payment or commerce specification	Message fields, roles and expected transitions	Production support, interoperability or adoption
Provider documentation	Documented credential, payment, ledger or refund capability under stated limits	Independent performance, buyer eligibility or future availability
Public sandbox or example	Inspectable example path	Funded production payment or merchant demand
Facilitator or provider transaction report	Activity inside the provider's disclosed population	Unique customers, accepted jobs, profit or ecosystem market share
Processor, bank or on-chain record	A particular payment event under that system's semantics	Correct order, accepted service, invoice match or repeat relationship
Invoice marked paid	An invoice payment state	Agent authority, delivery quality or economic finality after adjustments
Refund, dispute or credit	A remedy process or adjustment event	Resolution of the wider service failure unless linked to the job

The current market has rich documented supply: checkout protocols, mandates, scoped credentials, HTTP payment interactions, card-network programmes, stablecoin schemes, bank agreements, billing and invoice systems. The reviewed evidence does not establish one universal rail, comparable protocol adoption or a common accepted-job denominator.

Unresolved market questions

Five developments would materially change our view of the payment market:

• a neutral, widely implemented identifier and event model that lets finance match authority, order, payment attempts, settlement, invoice, delivery and acceptance across providers without manual reconstruction;
• independently tested multi-provider interoperability across ACP, UCP, AP2 and payment methods, including repricing, cancellation, timeout and remedy;
• one stateless payment protocol supporting broad merchant acceptance, governed authority, economical reconciliation, tax and invoicing, and suitable recourse across repeated enterprise jobs;
• an independently audited dataset reporting buyer type, geography, active accounts, repeat accepted jobs, failures, refunds and net settlement across methods; or
• a documented Australian production route joining agent authority, local payment or bank infrastructure, structured invoice, accepted delivery and remedy.

Outstanding evidence remains material:

• no common public denominator compares listings, payment attempts, settled value, delivered outputs, accepted jobs and repeat customers across rails;
• public partner and pilot announcements rarely expose failure, refund, reconciliation or repeat-use populations;
• product geography and preview eligibility can be narrower than global protocol documentation suggests;
• x402, MPP, AP2, ACP and UCP versions and adjacent profiles are moving at different speeds; and
• meter integrity and fair partial charging remain seller- and application-specific for variable machine work.

Conclusion

Agents do not need a magical new way to pay. They need controlled access to a suitable route.

The commercial mode determines the payment route. Buyer intent and limits precede credential exposure; seller acceptance and buyer funding constrain the rail. One logical attempt persists through retries, settlement retains its method-specific meaning, and the result joins to order, delivery, acceptance, invoice and remedy. Repeat use, not the first successful transfer, establishes a commercial relationship.

Cards, banks, wallets and stablecoins coexist because they carry different institutions and protections. x402 and MPP make selected payment interactions easier for software without becoming complete commerce systems. The durable capability is the joined record that tells the buyer, seller and finance systems what happened when their records disagree.

About the author and editorial record

Agentic Economy is the accountable publisher of this report. Joel Chan founded the publication in Perth to research the infrastructure, companies and operating choices shaping the agentic economy. This chapter is source-led market analysis, not a sponsored ranking, legal advice, financial advice or a claim that any listed route has been independently tested by Agentic Economy.