Merchant of record for AI-agent purchases: what changes
An AI-agent-triggered purchase surfaces every compliance obligation a regular purchase does — VAT, chargebacks, refunds, consumer disclosure — but the layer the agent connects to (the MCP server) usually isn't the underlying vendor. Without a merchant-of-record layer, each vendor a cartapi-style aggregator sources from would have to register in every jurisdiction the aggregator's agents sell into. Cartapi is MoR: buyer's statement shows cartapi, cartapi remits tax, cartapi handles disputes. The consent-first click is what makes chargeback evidence bulletproof.
The first cross-border eSIM cartapi ever sold was a $6 Airalo plan for a French user visiting Thailand. It shouldn't have been complicated. It was.
France collects 20% VAT on digital goods sold to French residents. Thailand isn't in the picture — the user lives in France. Airalo, based in Singapore, doesn't collect French VAT. So who does?
That's the merchant-of-record question. Here's why agent commerce runs into it faster than any category before it.
What MoR is, in one paragraph
The merchant of record is the legal entity on the buyer's card statement. That entity is responsible for:
- Sales tax and VAT — collect at checkout, remit to the right jurisdiction on schedule.
- Chargebacks and disputes — represent the merchant side to Visa/Mastercard/Amex when a buyer disputes.
- Consumer protection — comply with local disclosure, refund, and cooling-off rules (EU's 14-day right of withdrawal, California's ADA-adjacent disclosures, etc.).
- Refund policy — publish it, honor it, hold the funds against it.
For SaaS, Paddle and LemonSqueezy are the household names. For physical goods, Amazon-as-marketplace-facilitator plays a similar role in the US. For agent-mediated digital-goods purchases, the pattern is the same and cartapi is the entity.
Why agent commerce hits this problem harder
Three things stack:
- Cross-border by default. The user might be in Berlin, the eSIM is for Thailand, the underlying provider is Singaporean. Three tax regimes touch a $6 purchase. Regular e-commerce lets a brand pick one market and grow into others; agent commerce lets the agent buy across every market on day one.
- Aggregation. A single cartapi endpoint fronts Airalo, Nomad, Reloadly, and more. Without an MoR layer, each vendor has to register for tax collection in every jurisdiction any agent might route them into. That's not a scaling story — that's a rejection letter.
- Long-tail SKUs. Digital goods are cheap and numerous. A €4 eSIM crossing a border costs €0.80 in French VAT. The compliance overhead per transaction is fixed; the transaction is small. Only an MoR layer with amortized compliance makes the unit economics work.
The chargeback question, specifically
Imagine this scenario: a user asks their agent for a Japan eSIM. The agent buys one. The user's spouse sees the charge, doesn't recognize it, disputes it as fraud.
Who defends the charge?
Under MoR: cartapi. The evidence cartapi presents is the consent-first checkout — a Stripe checkout page, opened in the user's own browser, on the user's own device, with a timestamped click. The dispute is a friendly-fraud claim by the spouse, not fraud on cartapi. It resolves clean.
Without MoR, the dispute lands on the underlying provider (Airalo, say). Airalo has no evidence, no relationship with the buyer, no idea an AI agent was involved. They lose. They pull out of the API. The whole model breaks.
Consent-first isn't just a security pattern. It's also the chargeback evidence that makes MoR economically viable.
Tax, the boring part that eats the P&L
Cartapi collects VAT on EU sales via the OSS scheme, GST on Australian sales at the threshold, US sales tax in the ~24 states that consider MoR-based digital goods taxable, and a growing list of country-specific digital-services taxes. Stripe Tax does most of the heavy lifting; cartapi's job is to have the entity registrations, keep the rate table current, and file returns on time.
The alternative — each underlying vendor doing this per-jurisdiction — is not a product decision. It's a business-doesn't-exist decision.
Refunds, the part that's actually agent-specific
An agent-bought eSIM that never activated is a refund case. An agent-bought gift card whose code was already redeemed by the recipient is not. The refund policy has to distinguish, and the agent has to be able to trigger the right path.
Cartapi exposes request_refund(order_id, reason) as an MCP tool. The agent submits the request; the MoR (cartapi) applies policy and either issues the refund via Stripe or explains why not. The user isn't stuck in a support-ticket queue with the underlying vendor.
This is the same shape SaaS MoRs already handle — but agents are much better at noticing failure fast and requesting refunds cleanly than humans navigating an email support flow. Expect refund-rate metrics to look different in agent-commerce than in human-commerce.
The trade-offs
Being MoR has real cost:
- Cartapi holds the buyer relationship, not the vendor. That's the vendor's cost of using an aggregator.
- Cartapi eats fraud losses that consent-first can't evidence (edge cases: card cloning, ATO where the attacker also controlled the click).
- Cartapi's platform fee (~5% on top of Stripe's processing) exists because MoR compliance work is real. Direct vendor integration is always cheaper on paper, more expensive in practice once you count the compliance staff.
For a single-vendor MCP server, MoR is overkill — the vendor can just be their own MoR the way they were before agents existed. For an aggregator like cartapi, MoR is the whole business model.
What to check when picking an agent-commerce provider
- Whose name appears on the buyer's card statement? If the answer is "the underlying vendor's," they haven't solved the aggregation-tax problem.
- Who handles disputes? If the answer is "the underlying vendor," the model won't scale.
- Do they collect VAT / GST / sales tax? If the answer is "no," they're either not selling to those jurisdictions or accumulating a compliance debt.
- Is there a refund tool in the MCP surface? If the answer is "email support," the agent can't close the loop.
Cartapi answers those four the way you'd want: cartapi, cartapi, yes, yes.
Frequently asked questions
What is a merchant of record?
The legal entity that appears on the buyer's card statement and is responsible for collecting/remitting sales tax or VAT, handling chargebacks, and complying with local consumer-protection rules. Paddle and LemonSqueezy for SaaS; cartapi for agent-mediated digital goods.
Why does AI-agent commerce specifically need MoR?
Agents cross borders by default, aggregators front multiple vendors, and digital-goods SKUs are numerous and cheap. Without MoR, each vendor would have to register in every jurisdiction every agent might route them into — not viable. MoR amortizes the compliance work across all vendors and all buyers.
Who handles a chargeback when an AI agent bought the wrong thing?
The merchant of record. For cartapi, that's cartapi. The consent-first checkout provides the evidence — the user clicked, on their device, at that timestamp — so friendly-fraud disputes resolve cleanly.
Is cartapi the merchant of record for every purchase?
Yes. Buyer's card statement shows cartapi. Cartapi collects and remits tax. The underlying vendor (Airalo, Reloadly, Nomad, etc.) is paid net of tax and platform fee, out of band.
What's the cost of the MoR layer?
A platform fee (~5% on top of Stripe's processing). That covers tax filings, dispute defense, chargeback losses, and the entity registrations across ~30 jurisdictions cartapi currently operates in.