Skip to content
SpendTheBits

AI agent payments in production: an agent bought a gift card over x402, with no custodian

By , Founder, SpendTheBits ·

In short

AI agent payments usually end at the same question: who holds the money while the agent shops? In our production app an agent bought a real Amazon gift card over x402, paid in USDC, and nobody held the funds on the way. In our production run the agent paid at 19:04 UTC and the card was issued at 19:08 UTC, about 4.5 minutes later, and the forwarding transaction is public [6]. The pay-to address was a contract that can only forward the money to the card provider or send it back.

4.5 min
from an agent's x402 payment to an issued gift card, on mainnetSource: Blockscout (Base mainnet)

Software agents can now search, compare and decide. Paying is the part that still makes people nervous. An agent that can pay needs money, and money needs rules. Most setups solve this by giving a company your funds and trusting it to follow your instructions.

This piece shows a different answer, from a purchase that really happened. It covers what the agent did, where the money went, and which limits stayed with the owner. It also says plainly what is not finished yet.

A gold robot hand reaching for a gift box while a coin sits inside a sealed glass cube with only two paths out, representing an agent payment held by a contract that can only forward or refund.

What happened on mainnet, step by step

The owner opened Agent budgets in SpendTheBits and created an agent. The app made a fresh key on the phone. That key is not the wallet's recovery phrase, and it never reaches our servers. The owner then topped the agent up with USDC on Base and allowed gift cards for it.

The agent ran a stock x402 client. It asked our store for a quote on a small Amazon card. The store answered with a price, a pay-to address and a deadline. The agent paid, and then it polled a status link.

In our production run the agent paid at 19:04 UTC and the card was finished at 19:08 UTC, about 4.5 minutes later [6]. The order's contract was deployed 12 seconds after the payment, in the public transaction linked in our sources [6]. The card provider used the rest of the time. The card landed in the owner's orders, under the owner's name, and the agent never saw the code.

One detail matters for anyone building on this. The store checks the payment's signature before it does anything else. A request that only claims to come from an agent creates no order and learns nothing about the owner. Everything that costs something waits for a payment that is real.

Nothing in that flow is a demo. It ran on mainnet, with a real card, from an unmodified client.

The SpendTheBits My orders screen showing an Amazon.com card marked Ready and tagged as bought by an agent
The owner's orders after the purchase. The card is tagged with the agent that bought it.

Why AI agent payments stall at the custody question

Google's Agent Payments Protocol names the three worries well: authorization, authenticity and accountability [3]. Did the user really allow this purchase? Does the request match what the user meant? Who answers when something goes wrong? Google says it is working with more than 60 organizations on those questions [3].

Card networks and platforms tend to answer with signed mandates and a trusted intermediary. That works when a regulated company sits in the middle. It also means the company holds the funds, or at least the keys to move them.

x402 starts from the other end. A server answers a request with HTTP 402, and the client pays and retries [1]. The standard describes itself as open and neutral, with zero protocol fees [1]. Its own site publishes live counts of transactions, buyers and sellers [1]. So the rail for AI agent payments exists. The open question is what sits at the receiving address.

There is a quieter point too. A budget is easier to reason about than a permission. An owner who funds an agent with a small amount knows the worst case in advance. No policy engine has to be trusted to enforce it, because the chain already does.

A pay-to address that is a contract, not a company

In most x402 setups the pay-to address belongs to the seller. For a gift card that would be us, and we would be holding customer money between the agent and the card provider. We did not want that, even for a minute.

So each order gets its own small contract. Its address is worked out before the contract exists. Every term is part of that address: where the money may go, how much, who gets a refund, and when the offer ends. Change one term and you get a different address.

This is the part people find odd, so it is worth saying slowly. The agent pays an address where nothing lives yet. A relayer then deploys the contract to exactly that address, and deploying it is what moves the money. Anyone can check the result: the same terms always produce the same address.

The contract can do three things. It can bridge the USDC to the card provider. It can pay the quoted service fee. It can send everything back to the payer once the deadline passes. It has no owner and no admin key, so we cannot redirect it either.

The payment itself is an ordinary signed USDC authorization. ERC-3009 lets a holder sign a transfer and lets someone else submit it and pay the gas [2]. That is why the agent needs no gas token, only USDC. The standard uses random 32-byte nonces, so one signed payment can never be used twice [2].

How the USDC crosses from Base to Ethereum

The agent pays on Base. The card provider accepts USDC on Ethereum. Something has to carry the money across, and that step is where custody usually sneaks back in.

Here the contract burns the USDC through Circle's Cross-Chain Transfer Protocol. Circle describes CCTP as native burn-and-mint, without traditional bridge liquidity pools [4]. The mint address is fixed inside the contract as the provider's deposit address, so the new USDC can only appear there.

Circle lists Fast Transfer at roughly 8 to 20 seconds [4]. In our production run the burn on Base happened 12 seconds after the agent paid [6], and the mint on Ethereum followed within the same minute. You can read more about this rail on our bridge page.

If the price expires before the money can be forwarded, the same contract refunds the agent in full. Nobody has to file a ticket. The rule is in the code that holds the money.

Limits that live with the owner, not the agent

AI agent payments need brakes that the agent cannot release. The hard limit is simple: the agent can only spend the USDC at its own address. On top of that, the owner sets a per-card limit and a monthly limit in the app, per agent. One tap pulls the remaining balance home.

The card is always issued to the owner. The agent cannot send a name, and a request that tries is refused. Card codes stay hidden from the agent unless the owner turns that on. A code is money in plain text, and an agent's logs are not a safe place for it.

Gift cards attract fraud, so the caps matter. The Federal Trade Commission puts it bluntly: gift cards are for gifts, not for payments [5]. It also warns that no real business or government agency will ever tell you to buy a gift card to pay them [5]. An agent with a small budget and a monthly ceiling cannot be talked into draining a wallet.

Refusals are free. If the agent is over a limit, unknown, or switched off, the store says so before any payment settles.

The SpendTheBits sheet that allows gift cards for one agent, with a per-card limit, a monthly limit and card codes hidden by default
Gift cards are off until the owner allows them, per agent, with limits.

When something goes wrong

Payments fail in boring ways, and AI agent payments fail in the same ones. A reply gets lost. A price expires. A bridge is slow. The design has an answer for each, and none of them needs a person.

If the agent pays and hears nothing back, it polls the status link. If it pays the same order again, the store answers with the same order and charges nothing. If the facilitator times out, the store keeps that payment reserved and reads the chain to see whether the money arrived.

If the deadline passes first, the contract refunds the agent in full when it is deployed. If the owner freezes the wallet or switches gift cards off, the next quote is refused before any payment settles. We wrote a test for each of these, and each test fails when its safeguard is removed.

What is live today, the Copilot route, and what is not

Live now: an owner's own agent can buy gift cards for the USA and Canada, within the owner's limits. Any stock x402 client works, once its own spend cap is raised above the card's price. Expect about five minutes per card, and poll the status link instead of paying twice.

No agent of your own? Inside the app, Copilot does the same job with you in the loop. Ask it for a card and it finds the real product in your country. It fills in the amount and opens the review screen. Copilot only prepares, and your device signs, every time. If the card is not sold at the value you asked for, it picks the nearest real value and tells you. The full flow is in our guide to buying gift cards.

Not live yet: anonymous agents with no owner. That path needs the card provider's written approval first, because a named buyer is required. The per-card ceiling is also deliberately low while the forwarding contract awaits an outside review.

One honest note on price. The card provider's quote includes its own spread, and that spread is a larger share of a small card. An agent should compare the total with the face value before it pays. The mechanics of x402 itself are covered in our x402 explainer.

SpendTheBits Copilot preparing a 10 USD Amazon.com gift card order with a Review and confirm button
Copilot prepares the order. The owner reviews and signs.

In the app · 6 steps

Let your AI agent buy a gift card in SpendTheBits

You set the budget and the limits on your phone. The agent pays with its own key and the card lands in your orders.

  1. Create an agent and fund it

    Open Agent budgets and create an agent. The key is made on your phone. Tap Top up to send it USDC on Base.

    The SpendTheBits Agent budgets screen with one agent, its balance, its gift card status line, Top up and Kill switch
  2. Allow gift cards and set limits

    Tap the Gift cards line on the agent. Switch it on, then set a per-card limit and a monthly limit. Leave card codes hidden unless you need them.

    The gift card permission sheet for one agent with per-card and monthly limits
  3. Give the key to your agent

    Tap Show key and copy the line into your agent's environment. It works with any stock x402 client.

  4. Or ask Copilot instead

    No agent? Ask Copilot for a card. It finds the real product and fills in the amount for you to review.

    Copilot preparing an Amazon.com gift card order
  5. Review the card and the price

    The card opens with the amount selected. You see the live price before anything is signed.

    The Amazon.com gift card screen with USD 10 selected and USD Coin as the payment
  6. Find the card in My orders

    Cards your agent bought are tagged with its name. Tap Ready to reveal the code behind your device unlock.

    My orders showing a Ready Amazon.com card bought by an agent

Hold your own keys, keep the yield, skip the middleman.

SpendTheBits is a fully non-custodial wallet for 13 chains, free on iOS and Android.

Frequently asked

Yes. In SpendTheBits the agent gets its own key and only the USDC you put at its address. Your recovery phrase and your main wallet are never shared with it.

A per-order contract does. It can only forward the USDC to the card provider, pay the quoted service fee, or refund the payer after the deadline.

About five minutes in our production runs. The bridge leg is under a minute and the card provider issues the card after that.

Not by default. The card appears in the owner's orders, and the owner can choose to let a specific agent read codes.

Any stock x402 client that can sign a USDC payment on Base. Raise the client's per-payment cap above the card's price, since many clients default to a very small cap.

Sources

  1. 1.x402: an open standard for internet-native payments · x402 Foundation · accessed 2026-09-20
  2. 2.ERC-3009: Transfer With Authorization · Ethereum Improvement Proposals · accessed 2026-09-20
  3. 3.Powering AI commerce with the new Agent Payments Protocol (AP2) · Google Cloud · accessed 2026-09-20
  4. 4.Cross-Chain Transfer Protocol (CCTP) · Circle · accessed 2026-09-20
  5. 5.Avoiding and Reporting Gift Card Scams · Federal Trade Commission · accessed 2026-09-20
  6. 6.The forwarding transaction on Base: the order's contract is deployed and burns the USDC through CCTP · Blockscout (Base mainnet) · accessed 2026-09-20

This article is educational and reflects observed data and public sources on the date shown. It is not financial, legal or tax advice. Digital assets can lose value; yields shown are observed, not promised.

STB Weekly, every tuesday

The short version of pieces like this one, plus what moved in AI in finance and agent payments. What you get

Product updates and release notes. No price calls, no spam, unsubscribe in one click. We email you once to confirm before anything else is sent.