← All guides · Selling to AI agents

Refunds and Disputes with Agent Buyers: What a Seller Actually Does

Part 8 of Selling to AI agents · 1,508 words · published 2026-08-03 · updated 2026-08-03 · Markdown variant

What happens on the seller side when an autonomous agent's purchase needs to be reversed or is disputed — API-key refund mechanics, why x402 settlement cannot be undone, what card-token revocation does and does not prove, and what to log before you reverse anything.

Part of the How to Sell to AI Agents: The Complete Guide to Machine Buyers guide.

An agent completing a purchase autonomously does not change what a seller owes when something goes wrong — it changes how fast the mistake can happen and how hard it is to walk back. This article sits inside how to sell to AI agents, the pillar for this cluster, as the reversal-and-dispute layer underneath the identity and revocation ground covered in agent spend limits and trust — that article covers revoking access before or during a transaction; this one covers undoing or contesting a transaction that already happened.

What "refund" means once the deliverable already shipped

A refund on a digital purchase is only realistically available if the deliverable itself was never sent — not because a buyer changed its mind after receiving it. ChangeGamer's own terms state this precisely: under EU consumer rules, a buyer has a 14-day right of withdrawal, but because a key or corpus file is a digital service delivered immediately on request, the buyer expressly consents to delivery beginning before that window expires, and the right of withdrawal lapses upon delivery — a term stated for the Corpus Updates subscription and, as of Q2 2026, extended explicitly to the one-time emailed deliverables on the Corpus and Enterprise licenses too, per access and pricing for crawlers. In practice that leaves one real question when a refund request comes in: did the deliverable actually go out? A Starter key that returned a 404 instead of a working cg_ token, or a Corpus/Enterprise license whose corpus email never arrived within the stated one-business-day window, is a legitimate refund case. A key that was issued and works, or a corpus file that was sent and opened, is not — the digital-delivery carve-out has already closed that door, whether the requester is a person or the agent that executed the checkout on their behalf.

This is worth stating plainly because "refunds are easy via Stripe" is the wrong mental model here. Stripe makes it operationally trivial to issue a refund; it does nothing to change what a seller has agreed to refund. An agent that autonomously buys a key expecting a no-questions-asked reversal window is relying on a right that, by ChangeGamer's own published terms, ends the moment delivery completes.

Cancelling a subscription is not the same as refunding it

Of ChangeGamer's four paid tiers, only Corpus Updates is a true subscription — Starter, Corpus, and Enterprise are one-time purchases with no recurring charge to cancel at all. Cancelling Corpus Updates through the Stripe customer portal before the next billing date stops the next renewal; it does not, by itself, refund the period already paid for. Access and pricing is explicit on this: a refund for the current period is offered only if no corpus file has been delivered during it, requested by replying to the Stripe receipt email. Once the annual corpus file has gone out, cancellation is a forward-looking action — it stops future billing and future re-delivery, and the buyer retains whatever rights attach to the corpus version already delivered, per the same terms. A seller fielding a request from an agent (or the person operating it) that conflates "I cancelled" with "refund my last charge" needs to check one fact before answering either way: was that period's deliverable actually sent.

Settlement finality: why an x402 payment cannot just be undone

A settled x402 payment has no seller-side reversal mechanism documented anywhere in this corpus, and a seller should not imply one exists. The protocol's flow — client signs a transfer authorization, server or facilitator verifies it, then broadcasts and settles on-chain — is described as a one-way sequence ending in an X-PAYMENT-RESPONSE settlement confirmation, per agentic payment protocols and the seller-side verify-then-settle mechanics in accepting x402 payments. Once that settlement confirmation exists, the funds have moved on-chain; there is no described seller-initiated "undo."

The one mechanism that looks superficially like a refund is Apify's deposit-and-refund pattern for the upto scheme, and it is important not to conflate it with post-settlement reversal. That pattern authorizes a ceiling before a variable-cost run starts, and returns whatever portion of the deposit the run did not use at completion — it is a pre-settlement true-up of a variable cost against an authorized maximum, per agent wallets and x402, not a mechanism for clawing back money after a fixed payment has already settled. A seller running the exact scheme, where the full authorized amount settles up front, has no equivalent true-up available at all. If your x402 integration needs anything resembling a refund path, build it as a business decision — sending a separate on-chain payment back to the buyer's wallet — rather than assuming the protocol gives you one for free.

Card-network agent tokens: a kill switch, not a documented dispute right

Both Visa and Mastercard document the ability to revoke an agent's tokenized card credential independently of the user's underlying card, per agent spend controls — a clean, network-level kill switch that stops a misbehaving agent from transacting further. That is a real, documented capability. What is not documented anywhere in this corpus, and was not independently verified this session against a primary Visa or Mastercard dispute-policy source, is whether ordinary cardholder chargeback rights apply in full to a transaction that was already completed through an agent token. Because the transaction still rides normal card-network rails, assuming standard dispute mechanics carry over is a reasonable working assumption — but it is an inference, not a documented fact, and this article is deliberately naming that gap rather than papering over it. A seller relying on card-network dispute handling as its backstop for agent-driven fraud should confirm the current merchant agreement and dispute-liability terms with its acquirer directly rather than assume they read across unchanged from human-initiated card transactions.

AP2 and ACP mandates: proof of authorization, not a resolved dispute mechanism

An AP2 Intent, Cart, or Payment Mandate, or an ACP Shared Payment Token, proves that a purchase was authorized up to a signed ceiling at the moment the agent made it — that is what these mandate-based protocols are built to carry, per agentic payment protocols and the protocol comparison in ACP vs. AP2 vs. x402. Neither protocol's documentation in this corpus describes what happens next if the human principal later disputes the charge — claims the agent exceeded its mandate, that the mandate was forged, or that they never intended to authorize the purchase at all. There is no documented real dispute case and no documented issuer-liability rule covering that scenario as of this writing. Treat a signed mandate as strong evidence that authorization existed at transaction time, useful for a seller to produce if a dispute is raised — but not as a settled answer to who bears the loss if the authorization itself is contested. That is a live gap in mandate-based agent commerce, not a solved problem; do not represent it as one to a buyer or an issuer.

What to log and check before reversing anything

Separate three questions before acting on any refund or dispute request from an agent buyer, because collapsing them into one decision is the most common mistake:

• Was the deliverable actually sent? Check the key-issuance or email-delivery record, not the buyer's claim. This is the only question that matters for ChangeGamer's own one-time tiers, per the withdrawal-lapse terms above.
• Was the payment settled, or only authorized? An x402 upto authorization that has not yet settled is a different state than a completed exact settlement; a card-token authorization hold is different from a captured charge. Log the settlement receipt or capture confirmation, not just the initial request.
• Does the authorization on file actually cover the charge? For a subscription, check the Stripe subscription status and last renewal date. For a mandate-based purchase, check what ceiling and scope the mandate or token actually granted. A dispute that turns on "was this authorized" needs the signed record, not a summary of it.

Log every refund and dispute decision with the request or session id, the deliverable-sent timestamp (or its absence), the settlement or capture status, and — for mandate-based purchases — a reference to the specific mandate or token that authorized the charge. That log is what a seller hands to a payment processor, card network, or its own counsel if a dispute escalates past a reply-to-receipt-email conversation.

When to route it to a human

Route to a human immediately, rather than resolving it in an automated reply, whenever a request involves a settled x402 payment (no reversal mechanism exists to fall back on), a claim that a mandate or card token was used outside its authorized scope (a legal and evidentiary question, not a support-ticket one), or any formal chargeback or dispute notice from a card network or processor. Routine refund requests that reduce cleanly to "was the deliverable sent, yes or no" can stay automated; anything that requires interpreting whether an authorization was valid cannot, because no protocol in this corpus documents a settled answer for that question yet.

#refunds #disputes #chargebacks #payments #x402 #agents #monetization