# How Do AI Agents Pay for Things? Payment Rails for Agentic Commerce

URL: https://firestarter.network/blog/how-ai-agents-pay
Published: 2026-06-11
Author: Victor Young

A practical survey of how AI agents pay—card-on-file, virtual cards, payment APIs, and execution-layer APIs with escrow—and the real tradeoffs between each approach.

AI agents pay for things using the same payment rails that humans use—cards, bank transfers, payment APIs—but the way those rails are accessed and the protections they provide vary enormously depending on the architecture. The options range from a browser agent filling in a saved card number (minimal control, no order semantics) to an execution-layer API that holds payment in escrow until delivery is confirmed (full lifecycle accountability). This post surveys the real options, what each one actually provides, and why the choice matters for organizations building agents that spend real money.

## Option 1: Card-on-File with a Browser Agent

The simplest approach: a browser automation agent navigates to a retail or supplier site, adds items to a cart, and submits a checkout form using a card number stored in the agent's credential vault or retrieved from a secrets manager.

This works in the narrow sense—purchases complete. But it has serious structural problems for production use.

**No order semantics.** Once the form is submitted, the merchant owns the transaction. The agent has no programmatic record of what was ordered, what it cost, or when it will arrive—only scraped data from a confirmation page, which is unstructured and varies by merchant.

**No spend enforcement.** The card limit is the only ceiling. There is no intermediary enforcing a per-execution budget.

**Chargeback exposure.** Recovering funds for non-delivery requires a dispute process designed for consumer cases, not for programmatic agent purchases.

**Fraud risk.** A card number passed to an arbitrary merchant's checkout is exposed to that merchant. For a curated supplier list this may be acceptable; for any ad-hoc supplier an agent might discover, it is not.

Browser agent purchases suit narrow, supervised use cases but do not scale to general agentic commerce.

## Option 2: Virtual Cards

Virtual cards improve on card-on-file by issuing a new card number for each purchase or category, with controls set at issuance. Providers like Stripe Issuing, Brex, and others let you create a virtual card with a spend limit and merchant category restrictions.

This is meaningfully better. A virtual card with a $100 limit and a merchant category code (MCC) restriction to office supply stores cannot be used to buy something else or spend more than $100. The spend control is enforced by the card network, not by the agent.

But virtual cards still have gaps when used alone for agentic commerce:

**No order semantics.** A virtual card payment is a transaction, not an order. The card network knows that $87.50 went to Merchant X. It does not know what was ordered, whether it was delivered, or whether the agent's original intent was satisfied. Reconciliation requires matching card transactions to purchase intents through an external process.

**No delivery verification.** Payment is captured at checkout, before delivery. If the order is not fulfilled, the path to recovery is a dispute process, not an automatic release of held funds.

**No structured audit trail.** Virtual card transactions produce card statements. Those statements do not include the agent's original request, the options that were considered, who approved the purchase, or what the tracking number was. The [audit trail](/blog/ai-agent-audit-trails) for an agent-initiated purchase requires more than a transaction record.

Virtual cards are a useful component of an agentic payment stack, particularly for enforcing spend limits at the card-network level. They are not sufficient on their own for full-lifecycle accountability.

## Option 3: Payment-Layer APIs

Stripe recently introduced agentic commerce capabilities—a set of APIs and tools designed to help agents initiate and manage payments. This represents a meaningful step toward purpose-built infrastructure for agent payments.

Payment-layer APIs like these handle the payment step well. They are designed for programmatic access, produce structured transaction records, and integrate with agent frameworks via tools and MCP. [Stripe's approach](https://stripe.com/payments) reflects careful thinking about authentication, authorization, and fraud in agent contexts.

But a payment API is, by definition, payment infrastructure. It handles the money movement. It does not handle supplier discovery, product comparison, fulfillment, shipping, or delivery verification. For a complete agentic purchase, you need all of those things, and a payment API requires you to build or integrate the rest.

See [Firestarter vs. Stripe Agentic Commerce](/compare/firestarter-vs-stripe-agentic-commerce) for where payment-layer and execution-layer approaches diverge.

## Option 4: Execution-Layer APIs with Escrow

An execution-layer API is designed around the full purchase lifecycle, with payment as one step in a managed sequence. Firestarter is built on this model: one API call initiates a lifecycle that covers supplier search, quote comparison, human approval, payment via Stripe held in escrow, shipping label generation via EasyPost, and tracking through delivery.

The payment semantics are different from the other approaches in a meaningful way.

**Escrow until delivery.** When a Firestarter execution reaches the payment stage, Stripe authorizes the charge but does not capture it. Funds are held in escrow. Capture only occurs when delivery is confirmed. If the execution is cancelled before shipping, the authorization is released and no charge appears on the card. If an order ships but is not delivered, the escrow provides a clean refund path without a chargeback dispute.

**Spend limits enforced at the execution layer.** The `budget.max_total` parameter enforces a hard ceiling on total landed cost—including shipping and taxes—before the agent surfaces options or touches a payment method. No option above the limit reaches the approval gate, and no payment above the limit is authorized. This is a deterministic constraint, not a prompt-level suggestion. See [how to give your AI agent a budget](/blog/give-your-ai-agent-a-budget) for the full spend-control configuration.

**Order semantics throughout.** Every execution is a structured record—parsed intent, supplier queries, ranked options, approval event, payment reference, tracking number, delivery confirmation. The payment event is linked to the original request, the approver identity, and the fulfillment outcome. This is the [audit trail](/blog/ai-agent-audit-trails) that compliance, finance, and dispute resolution require.

**Human approval checkpoint.** By default, executions pause at `pending_approval` before payment is processed. A human reviews the options and authorizes the purchase. This can be disabled for low-value, high-frequency purchases, but it is on by default because unsupervised spending is a risk most organizations are not ready to accept. See [human-in-the-loop approval workflows](/blog/human-in-the-loop-ai-purchases) for the full approval flow.

## Comparing the Four Approaches

| Approach | Spend control | Order semantics | Delivery verification | Audit trail |
|---|---|---|---|---|
| Card-on-file browser agent | None (card limit only) | None | None | None |
| Virtual cards | Good (card-level) | None | None | Transaction record only |
| Payment-layer API | Good (payment-level) | Partial | Not included | Payment record |
| Execution-layer API with escrow | Best (pre-payment, total landed cost) | Full lifecycle | Yes (escrow released on delivery) | Full step-by-step |

For organizations where agent purchases are infrequent, supervised, and limited to known suppliers, card-on-file or virtual cards may be sufficient. For organizations where agents are placing orders autonomously or semi-autonomously at any volume, the absence of order semantics and delivery verification becomes a significant operational problem.

## How Firestarter Handles Payment

Firestarter's payment model:

1. Human (or automated policy) approves the execution via `POST /v1/executions/:id/approve`
2. Stripe payment intent is created and authorized—funds are held, not captured
3. Supplier fulfills the order; Firestarter issues a shipping label via EasyPost
4. Carrier tracking events update the execution status through `in_transit`
5. Delivery confirmation triggers escrow release—Stripe captures the payment
6. Execution status advances to `delivered`; receipt and tracking number are recorded in the audit log

If the execution is cancelled at any point before delivery confirmation, the authorization is released. No capture, no charge.

The API surface for a buyer is straightforward. To start an execution and check status, see the [developer docs](/developers) and the [OpenAPI spec](/openapi).

## Connecting via MCP

For language models that support the Model Context Protocol, Firestarter exposes its execution tools via a hosted MCP endpoint:

```
claude mcp add firestarter \
  --transport sse \
  --url https://api.firestarter.network/mcp \
  --header "Authorization: Bearer fs_live_YOUR_KEY"
```

This gives the model access to `firestarter_execute`, `firestarter_status`, `firestarter_approve`, `firestarter_cancel`, and `firestarter_message`. Purchase endpoints are marked `x-openai-isConsequential: true` in the [OpenAPI spec](/openapi), which signals to compatible agent frameworks that these calls have real-world financial consequences and should request user confirmation.

See the [MCP integration page](/mcp), the [developer docs](/developers), and the [agent action API use case page](/use-cases/agent-action-api) for integration details. For a full walkthrough of how payment fits into a B2B procurement workflow, see [AI procurement automation](/blog/what-is-agentic-commerce) and the [kraft mailer scenario](/scenarios/kraft-mailer-boxes-austin).

---

## FAQ

### Do agent-initiated purchases require a different card type than regular purchases?

No. Firestarter accepts standard card payment via Stripe. The card on file does not need to be a virtual card or a special "agent card." The spend controls and escrow protections operate at the Firestarter execution layer, on top of the standard Stripe payment infrastructure.

### What happens to the escrow if a supplier never ships the order?

If a supplier fails to generate a shipment within the expected window, the execution flags for exception handling. Firestarter can re-source the order from an alternative supplier or cancel the execution. On cancellation, the Stripe authorization is released and no charge is captured. Buyers pay no transaction fees, and cancelled executions do not consume additional tokens.

### How does Firestarter handle refunds?

Refunds are initiated on the Stripe payment intent associated with the execution. For orders cancelled before delivery confirmation, the authorization is simply released—no refund process is needed because no capture occurred. For orders where a return is required after delivery, the refund flow depends on the supplier's return policy, with Firestarter facilitating the process and recording it in the execution audit log.

### Can an agent initiate a payment without human approval?

Yes. Set `"approval": {"required": false}` in the execution request. The execution will advance automatically through all stages including payment without waiting for human input. This is appropriate for low-value, high-frequency purchases with tight spend limits enforced at the API level. See [give your AI agent a budget](/blog/give-your-ai-agent-a-budget) for the full spend-control configuration.

### What does it cost to use Firestarter?

[Free tier: 100 tokens to start plus a 14-day Pro trial, no credit card required.](/pricing) Pro is $99/month with 10,000 tokens. Buyers pay no transaction fees. Sellers list free and pay a 3% commission on completed sales only.