AP2 and Agentic Payments: What It Means for Refund and Billing Email

A refund request arrives at 2:47 a.m. It cites the order number, quotes your own return window back at you, and attaches a cryptographically signed document proving the customer authorized the purchase in the first place. No human typed it.

Most support teams reading this will not see that email in 2026. But the plumbing that makes it possible is already shipped, already governed by the Linux Foundation, and already backed by most of the card networks. The question isn't whether agent-authorized money movement reaches your inbox. It's whether your refund and billing workflows have anywhere to put the evidence when it does.

What AP2 is, in one paragraph

The Agent Payments Protocol is an open standard for proving a human gave an AI agent permission to spend money on their behalf. Google announced it in September 2025, developed with payments and technology companies to securely initiate and transact agent-led payments across platforms, and it shipped alongside A2A v1.0 with support from more than 60 organizations across payments and financial services. That same release put A2A at 150+ organizations under Linux Foundation governance, with Signed Agent Cards and production deployments at Microsoft, AWS, Salesforce, SAP, and ServiceNow.

Two things AP2 deliberately does not do, and both matter for support. It doesn't move money. Once the issuer receives the payment mandate, settlement happens over the normal card rails. It also binds a mandate to a user rather than to an agent, so proving the agent's own identity is a separate job, handled by things like Visa's Trusted Agent Protocol.

So AP2 answers one question extremely well: did this human actually authorize this? That is precisely the question a refund email is usually about.

The three mandates, translated into support language

AP2 mandates are JSON-LD documents structured as W3C Verifiable Credentials, signed with ECDSA over P-256 or stronger curves, each carrying the request payload, a timestamp, and the signer's public key reference. Strip the cryptography away and you get three artifacts that map cleanly onto things your team already argues about:

• Intent Mandate: the customer's original instruction, in their words. Order trail-running shoes under $150 that arrive by Friday. This is the closest thing to a signed record of what the customer wanted, which is exactly what's missing from most disputes today.
• Cart Mandate: the specific items, prices, and merchant the agent settled on. This is where mismatches between intent and outcome become visible.
• Payment Mandate: the authorization sent to the issuer, including whether a human was present at the moment of purchase or the agent acted alone.

Together they form a non-repudiable audit trail of who authorized what, within what limits. For a support team, that's a chain of custody you have never had before. Today when a customer says they never ordered something, you have an IP address, a timestamp, and a shrug.

Why this hits the support inbox before it hits anywhere else

Payments teams have spent a year on the authorization problem. Almost nobody has worked on what happens afterwards, and afterwards is where support lives.

The relationship doesn't transfer just because an agent placed the order. The merchant keeps the buyer relationship for refunds, dispute handling, and post-purchase support even when an agent bought on the buyer's behalf. Which means the agent gets the frictionless checkout and you get the email when it goes wrong.

The volume is coming from the direction you'd expect. Customers will ask their agents to track orders, initiate returns, request refunds, and chase resolutions, so where's my package and these don't fit become agent conversations rather than tickets typed by a person. If you already run AI on refund request emails, you're about to have an AI on the other side of the thread too.

What actually changes about a refund email

The evidence attached to the request gets much better

A signed Intent Mandate capping the order at $150 by Friday, set against a Cart Mandate showing a $180 item shipping Tuesday, is not a he-said-she-said. It's a documented mismatch, and it's machine-checkable. The refund decision that used to need a human reading two paragraphs of frustration becomes a comparison between two signed objects.

The practical requirement is boring and unglamorous: your own records have to line up with theirs. Order confirmations, digital receipts, and return policy links need to map cleanly onto the consent artifacts AP2 preserves, because fast programmatic alignment between merchant records and the AP2 audit trail is what keeps disputes cheap. If your order ID lives in one system and your refund decision lives in another with no shared key, the mandate can't help you.

A new failure class arrives: the hallucination dispute

This is the one nobody has a playbook for. If an agent orders the wrong item because it misread the user's intent, the merchant is likely to be held liable for the return and the chargeback. In every protocol currently proposed, from OpenAI to Google, the merchant remains the merchant of record. You take on the risk of somebody else's autonomous execution without the fraud signals you used to have.

Support feels this before finance does. The email says your site sent the wrong thing, the customer genuinely believes it, and the actual failure happened inside a model you don't control and can't inspect.

The liability answer is still missing

Be careful about assuming the protocol settles anything legally. As of 2026 no government has enacted regulation that specifically addresses who is liable when an AI agent makes a purchase autonomously, and the EU AI Act doesn't cover it either. Some issuers have moved unilaterally, and American Express committed to covering erroneous purchases made by AI agents on its network, but that's a network policy rather than a rule. Existing chargeback rules were written for a world where a human clicks buy.

Honestly, the gap is the whole story. AP2 gives you better evidence for an argument whose rules haven't been written.

Billing email gets a category it didn't have

Refunds get the attention, but recurring billing is where the messier version shows up. An agent that can authorize a purchase can authorize a subscription, and a delegated mandate with a spend cap looks nothing like the annual renewal notice your billing flow was built around.

The questions your team will start getting:

• Scope: the agent was allowed to spend $200 a month, so why is this charge $340? Answerable only if you stored the mandate's limits alongside the subscription record.
• Revocation: a customer revokes an agent's authority on Tuesday. Does your billing system know, and does your support agent know, before the Wednesday charge runs?
• Attribution: which of the customer's three agents authorized this line item, and can you show them?
• Human-present versus human-absent: a charge the customer watched happen and a charge their agent made overnight deserve different handling, and the mandate tells you which one it was.

None of this is exotic. It's the same shape as the delegated-access problems that billing and payment support emails already deal with, just with better paperwork and worse edge cases.

Six things worth doing before any of this is urgent

1. Add mandate fields to your ticket schema. Intent, cart, and payment mandate IDs as first-class fields on refund and billing tickets. Cheap to add now, painful to retrofit later.
2. Log the authorization context you already have. Whether the order came through a browser session, an API call, or an agent surface. Most teams don't capture this at all, and it's the single most useful field in an agent-era dispute.
3. Write the mismatch rule before you need it. When intent and cart disagree, what does your team do? Decide it now, as policy, rather than case by case at 2 a.m.
4. Give your refund automation a confidence floor. An agent-originated refund with a clean mandate chain and a value under your auto-approve threshold can be resolved without a human. Above it, escalate.
5. Keep an audit trail that survives a chargeback. Immutable, timestamped, and exportable. Audit trail design for AI email support covers what to log and how long to hold it.
6. Talk to your PSP about agentic transaction flags. Ask what they surface today and what they'll surface in six months. The answer varies enormously between providers right now.

Where an agent-authorized refund should still stop at a human

A signed mandate is a strong signal, not a blank cheque. There are cases where the right move is to route to a person even when the cryptography checks out.

Escalate when the mandate chain is incomplete or unverifiable, when the refund exceeds the customer's historical order value by a wide margin, when the same agent has filed multiple refunds against the same account inside a short window, or when the dispute involves a policy exception rather than a policy application. Also escalate anything that looks like coordinated abuse across accounts, because a fast, well-formatted, correctly signed refund request is exactly what a well-built attack would look like.

The general principle holds here without modification: automate the decision when the evidence is complete and the policy is unambiguous. Everything else is a human's call.

Where Robylon fits

Robylon resolves 60-80% of customer emails autonomously, and refund and billing threads are a large share of that in commerce and subscription accounts. The relevant capability for agentic payments isn't reading the email well. It's what happens after: querying the order in Shopify, checking the charge in Stripe, applying the refund policy, executing the refund, and writing the decision and its evidence back to the helpdesk record.

That's the part that has to exist before mandate verification is worth anything. A mandate you can validate but not act on is just a nicer-looking dispute. Robylon runs 60+ write-access integrations for exactly this reason, with human-in-the-loop escalation for the cases above, and deployment measured in days rather than quarters.

The adjacent question, whether you should give customer-side agents a proper front door instead of making them write emails at all, is worth its own argument. We make it in the case for a support API.

Frequently Asked Questions

What is AP2 in simple terms?

AP2 is an open protocol that gives an AI agent a signed permission slip from a human before it can spend that human's money. It works as an extension to the A2A protocol, and it produces three signed records: what the person asked for, what the agent selected, and what was authorized to the payment provider. It doesn't move funds itself. Settlement still runs over the existing card rails, so your payment stack doesn't change, only the evidence attached to the transaction does.

Does AP2 affect chargebacks for agent-made purchases?

Indirectly. AP2 gives you far stronger evidence of authorization, but it doesn't rewrite card network dispute rules, and no jurisdiction has passed law assigning liability for autonomous agent purchases. In practice the merchant remains the merchant of record and carries the risk. What changes is your ability to defend a dispute: a matching intent and cart mandate is much better evidence than an IP address and a timestamp.

Should support teams do anything about AP2 right now?

Yes, but nothing expensive. Add fields for mandate IDs and authorization context to your refund and billing tickets, decide your policy for intent-versus-cart mismatches, and confirm your audit trail can survive a chargeback six months later. These are schema and policy decisions, not integrations. Retrofitting them after agent-originated refunds start arriving is significantly more work than adding them while the queue is still quiet.

How is AP2 different from A2A and MCP?

They sit at different layers and are designed to compose. MCP connects an agent to tools and data. A2A connects agents to other agents across organizational boundaries. AP2 rides on top of both as a payments extension, adding the signed mandates that let money move with proof of consent. A support organization dealing with customer-side agents will eventually touch all three, but AP2 is the one that shows up in refund and billing threads first.

What is a hallucination dispute?

It's a refund or chargeback caused by an agent misreading its user's intent rather than by fraud or a merchant error. The customer wanted one thing, the agent bought another, and the customer disputes the charge. The uncomfortable part is that the merchant usually absorbs it under current rules, even though the failure happened inside a model the merchant didn't build. Signed intent mandates are the best available defence, because they show what the customer actually asked for.

Ready to resolve refund and billing email without growing the queue? Robylon AI resolves 60-80% of customer emails autonomously with AI agents that take action across Stripe, Shopify, Zendesk, and 60+ other integrations. Start free at robylon.ai