Cards for agentic payments: economics, settlement, and operational fit

Start with the flow

Cards are an acceptance network, not an authorization policy

A card transaction connects a merchant, acquirer or payment processor, network, issuer, and cardholder account. The issuer's approval says that the presented transaction passed its checks at that moment; it does not prove that an AI agent was entitled to choose the merchant or that the resulting order satisfied the principal's intent. In agentic payments, a separate policy decision must bind the principal, agent, seller, order, amount, currency, and expiry before the card capability is exposed.

The safest credential is narrower than the underlying account. Network tokens, virtual cards, and seller-scoped payment tokens can reduce the value of a leaked credential and keep the model away from reusable account data. Scope still needs enforcement outside the model runtime. A token that is technically valid but reusable at the wrong seller, for a larger total, or after a mandate expires leaves the important authority question unanswered.

• Authenticate the principal and recognize the acting agent as separate steps.
• Bind approval to an immutable order snapshot rather than a conversational summary.
• Issue or reveal the narrowest credential only after deterministic policy approval.
• Record the authorization decision and processor attempt under durable identifiers.

Model card economics at the transaction and portfolio levels

Card acceptance cost can include processor charges, network fees, issuer economics, currency conversion, cross-border treatment, fraud losses, refunds, and disputes. Contracts and pricing vary, so a design should consume the merchant's actual schedule instead of assuming one universal card rate. Fixed components matter more as ticket size falls; percentage components and foreign exchange matter more as value rises or currencies diverge.

Approval rate also has economic value. A cheaper nominal rail is not cheaper if it creates more abandoned orders, manual review, duplicate attempts, or support work. Conversely, an agent that retries a declined card across processors can increase cost and risk without increasing legitimate completion. The unit model should include successful and failed attempts, authorization reversals, refunds, disputes, reconciliation labor, and any reserve or timing effect relevant to the merchant.

Treat reversals, refunds, and disputes as different operations

Cards are often described as reversible, but that word hides several mechanisms. An authorization reversal releases an unused hold. A refund is a merchant-initiated credit associated with a captured purchase. A dispute is a governed claim process with evidence, deadlines, and a later liability decision. None should be implemented as deleting the original payment record, and none guarantees that all downstream systems observe the change at the same time.

An agent needs explicit permissions for post-purchase actions. It may be allowed to request cancellation, but not to invent a refund destination or accept substitute store credit. Operations should join the mandate, order, processor transaction, clearing records, fulfillment, refund, and dispute case. When callbacks are late or duplicated, idempotent state transitions and independent reconciliation should determine the result rather than the agent's narrative.

Card settlement closes one rail stage; it does not close the commercial relationship or eliminate recourse.

Use cards when acceptance and recourse outweigh per-event overhead

Cards fit agent purchases from merchants that already support card checkout, especially when familiar refund and dispute processes matter. They can also bridge an agent workflow into existing commerce without asking every seller to adopt a new asset or settlement system. The architecture should preserve merchant terms and user review requirements rather than treating widespread acceptance as blanket permission.

Cards fit less naturally when every API call creates a tiny charge, when a supplier relationship is better handled by invoice or bank transfer, or when deterministic machine settlement is the primary requirement. In those cases, batching, prepaid balances, bank rails, or onchain mechanisms may reduce operational friction. A rail decision should compare total cost, merchant coverage, credential scope, latency, recourse, settlement evidence, and finance operations for the actual transaction pattern—not for an abstract average payment.

• Choose cards for merchant reach, existing checkout compatibility, and governed recourse.
• Prefer scoped tokens or controlled virtual credentials over reusable account data.
• Use explicit states for authorization, capture, settlement, fulfillment, and refund.
• Re-evaluate the rail when frequency, ticket size, supplier concentration, or recourse needs change.