Agentcard
← Blog

How AI Agents Pay for DoorDash Orders Safely

Getting an AI agent to build a DoorDash cart is the easy half. The hard half is moving real money correctly: spending only what was authorized, charging exactly once, and being able to unwind a charge when an order fails halfway. This post is the payment-and-safety counterpart to how to build an AI agent that orders from DoorDash, which covered driving the store.

If you would rather not build a payments stack at all: Agentcard exposes all of this behind an MCP server your users connect to over OAuth, and you never touch cards, PCI scope, or settlement. The rest of this post is what that machinery is actually doing.

The lifecycle, in order

A safe agent checkout is not "charge a card." It is a sequence with a gate at the front and a settlement at the back, designed so that any step can fail without losing money or double-charging:

1. gate      reserve budget before any money is committed
2. mint      issue a one-time virtual card sized to the total
3. tokenize  hand the merchant a token, never a raw card number
4. place     submit the order
5. confirm   wait for the charge to actually authorize
6. settle    mark the reservation final once the charge lands

Each step exists because of a specific failure it prevents. Here is what each one is for.

Spend gate first

Before a single card is created, run the purchase through a spend gate. The gate enforces the user's policy — per-transaction caps, daily and monthly limits, merchant-category rules, and approval workflows for large amounts — and reserves the budget so two concurrent orders cannot both spend the last of it. Gating before minting matters: you never want a card to exist for money the user's policy would not allow. For the policy side of this, see how to set spending limits on AI agents.

Mint a one-time virtual card

Once budget is reserved, issue a virtual card funded for this order plus a small buffer, drawn from the user's prepaid wallet. The card is single-use: it authorizes once and closes. A hard balance ceiling is the cleanest defense against an agent that misbehaves — a runaway retry, a prompt injection, a fare that changed at the last second all hit a decline instead of an open-ended charge. This is the single-use virtual card model, and it is why a network-enforced limit beats trusting the agent to stop.

Tokenize: never hand over a raw card number

Tokenization means the merchant's payment processor turns the card into an opaque token, and you give the merchant that token rather than the PAN. The real card number stays in the issuer's vault; the merchant holds something that cannot be reused elsewhere. The agent never needs raw credentials at order time, and a compromised agent context yields nothing reusable.

Place is not paid: confirm, then settle

The mistake that bites everyone: treating "the order was placed" as "the money moved." It has not, yet. After you submit, the charge authorizes asynchronously. So the order sits in a pending state until the authorization actually lands, at which point you settle — mark the reserved budget as spent and the transaction final. If the authorization never confirms within your window, you do not silently assume success; a reconciliation job sweeps pending transactions and either settles them once the charge lands or releases the hold if it was declined.

Idempotency: charge exactly once

This is the single most important safety property, and the one most home-built integrations get wrong. Networks time out. Your agent retries. Without protection, the retry places a second order and charges a second time. The fix is an idempotency key: a stable identifier derived from the order, generated before you place it and reused on every retry. With it, a retry after a timeout re-checks the existing attempt instead of creating a new one — pre-placement it proceeds normally, post-placement it re-confirms the order already in flight, and once settled it simply echoes the original result. Same key, same outcome, no double charge.

Compensation: unwind only what is safe to unwind

Things fail between steps, so decide in advance what each failure unwinds. If checkout fails after minting but before the order is placed, that is safe to compensate: close the card and release the budget reservation. But once an order is actually placed, you must not blindly auto-refund or cancel — the order is real. Leave the card and the reservation in place and let confirmation or your reconciliation job resolve it. Auto-refunds belong to a different case: when the charge succeeded but the order did not, detect the orphaned charge and refund it before the card closes, so the refund has a valid destination.

The confirmation gate

No money should move without an explicit human yes, and the gate has to be structurally enforced, not just polite. The pattern: the agent shows the cart and total in one turn, and checkout is only allowed when the confirmation arrives in a later message. An agent cannot view a cart and check out in the same breath. This maps directly to the "excessive agency" risk in the OWASP LLM Top 10: the agent shops freely, but the irreversible action is fenced behind a separate, explicit approval.

Why does this need a real issuing stack?

Because minting cards is regulated. To issue virtual cards you need an issuing program, a funded wallet system behind it, and you take on PCI-DSS scope the moment your systems touch a real card number. Add the single-use lifecycle, settlement, refunds, and reconciliation, and the payment half is months of work and ongoing liability that has nothing to do with DoorDash specifically — it is the same for every merchant. That is precisely the part Agentcard removes.

How do virtual cards stop an AI agent from overspending?

Each card carries a hard balance ceiling set at issuance. If it is funded for the order amount plus a small buffer, the payment network enforces the limit no matter what the agent does — a retry loop, an injected instruction, or a last-second price change all hit a decline rather than accumulating charges on an open account.

How does idempotency work for AI agent payments?

You generate a unique key tied to the order before placing it, store it, and send it on every attempt. A retry with the same key returns the result of the original attempt instead of creating a new charge, so timeouts and reconnects can never double-order.

Or skip the build: connect Agentcard

The gate, the issuing program, tokenization, the confirm-settle flow, idempotency, compensation, refunds, PCI scope — that is the payment stack, and it is the same whether the merchant is DoorDash or anywhere else. Agentcard ships all of it behind an MCP server your users authenticate to over OAuth. Your agent calls one buy tool; the merchant integration and the entire payment flow are handled for you. You never solve the payment part. Give an agent a funded card in minutes with how to give Claude Code a virtual card.

Next steps