Start by naming the Merchant of Record, Buyer of Record, and final accept/decline owner, then design checkout around explicit user-linked authorization. For merchant of record for ai agents, the practical baseline is still agent-assisted flows where merchants keep order approval while AI surfaces mediate the experience. Use a model comparison across platform-led, merchant-led, and hybrid setups, then confirm provider acceptance, jurisdiction limits, and ASC 606 treatment before scaling.
AI commerce is moving faster than role clarity, and that is where teams get into trouble. Before you debate protocols or checkout surfaces, decide who is actually selling, who is the recognized buyer, who captures approval, and who owns the fallout when a charge, dispute, or identity mismatch shows up later.
That is the real issue in merchant of record for ai agents. This is not abstract architecture. It is operating reality. As of 2026, current production patterns are often better described as agent-assisted commerce than fully autonomous agentic commerce. Mastercard drew that line clearly in its October 14, 2025 framework. One mode is where AI agents assist consumers through the buying process. The other is where agents can autonomously find and buy products based on the consumer's intent. Those can carry different risk profiles, so they should not be treated as the same contract or checkout design.
The implementations we can point to reinforce that distinction. OpenAI's commerce guidance says ChatGPT collects buyer, fulfillment, and payment information from the user, and the merchant still accepts or declines the order and returns that state. That keeps the human-linked authorization moment and the merchant's approval decision at the center, even when the purchase flow feels embedded in an assistant. Microsoft made the same point on January 8, 2026 with Copilot Checkout: "you stay the merchant of record." The interface may shift into an AI assistant, but the underlying commercial role can remain with the merchant.
That gap between interface and legal role is where platform teams need discipline. If your product, finance, and engineering leads do not name the Merchant of Record and the buyer identity before launch, you will end up arguing about them during disputes, reconciliation, or provider review, when your options are worse. A good first checkpoint is simple: can your team point to the exact moment where the user provided payment details or approval, the exact party that accepted the order, and the exact record tying that action to a buyer identity? If not, you are not ready to scale AI-assisted checkout.
There is also a real trust problem underneath the excitement. Mastercard warns that without a standardized method to verify agent identity and consumer intent, merchants risk increased fraud. So this article stays grounded in what is workable now: agent-assisted payment flows, explicit authorization, merchant-side decisioning, and role assignments that can survive provider scrutiny.
The goal is practical. By the end, you should have a workable path for choosing MoR and Buyer of Record roles. You should also have a short list of launch checkpoints and a set of validation questions your finance, product, and engineering owners can act on this quarter.
Related: How to Record High-Quality Audio for Your Videos.
Define the legal and operational roles first, then choose tools. If you skip that sequence, teams often confuse interface ownership with payment liability.
Merchant of Record is the entity legally authorized and responsible for processing customer payments, and it carries the financial, legal, and compliance responsibility for those transactions. Treat Buyer of Record as the buyer identity your records connect to the purchase, consent, and fulfillment, rather than assuming it is the same thing as the MoR.
For most current AI-checkout implementations, separate these four actors explicitly:
This split reflects how current flows actually work: user payment and buyer details are collected from the user, merchants still control accept/decline, and payment providers remain a distinct actor in the transaction path. Use a simple readiness check before launch: can you show who collected payment details, who captured authorization, and who made the final accept/decline decision?
In practice, call these implementations agent-assisted payments unless you can prove a different model contractually and operationally. That wording better matches today's human-linked authorization patterns and avoids confusion in consent records, support handling, and provider reviews.
If you want a deeper dive, read ASC 606 for Platforms: How to Recognize Revenue When You're the Merchant of Record.
Choose the model your risk, finance, and support teams can defend under dispute pressure, not the one that looks most autonomous in a demo. The core decision is still who is Merchant of Record, who controls authorization, and whose balance takes the hit on refunds and chargebacks.
| Model | Practical setup | Liability surface | Authentication and authorization control | Dispute handling | Unknowns to confirm before launch |
|---|---|---|---|---|---|
| Platform-led MoR | Usually closest to destination-charge behavior, where customers transact with the platform for connected-account goods/services | More platform exposure; in destination charges, the platform balance is debited for fees, refunds, and chargebacks | Typically platform-owned approval and payment handoff flow | Usually platform-first | Provider acceptance for agentic flows, country footprint, cross-border payout eligibility, contract carve-outs |
| Merchant-led MoR | Usually closest to direct charges, where payment is made directly to a connected account | More merchant/connected-account exposure; disputed amounts are debited from the connected account balance in direct charges | Merchant controls final checkout/approval step | Usually merchant-first | Whether merchant acquiring/support operations can absorb this channel, statement clarity, connected-account agreement consent capture |
| Hybrid delegation | Platform mediates parts of the flow while merchant retains defined sale/approval obligations | Shared and easier to contest unless contracts are explicit | Shared or sequenced controls across platform and merchant | Can bounce between parties without clear event ownership | Highest uncertainty: provider acceptance, program eligibility, and precise contract language for submit/confirm/reverse actions |
Decision rule: if your immediate priority is scaling one mediated flow across many agents and merchant endpoints, platform-led is often the cleaner starting point. If your merchants already run strong acquiring and dispute operations and need control, merchant-led is usually safer.
Use a second decision axis for Buyer of Record design:
| Buyer record design | What it means operationally | Consent record implication |
|---|---|---|
| End-user direct buyer | Buyer evidence is tied to the actual user/business making the purchase | Keep records of who approved, when approval happened, which merchant was selected, and session context |
| Platform-instrumented buyer | Platform identity submits or represents the order flow | Keep explicit linkage from platform identity to the real user and delegated permission; session ID alone is weak evidence |
Avoid mixing labels and money movement. If you call a flow merchant-led but the platform appears on statements or platform balances absorb chargeback/refund debits, your contracts, support scripts, and provider disclosures are out of sync.
Before launch, confirm connected-account agreement acceptance before payments, and confirm country plus cross-border eligibility up front because coverage is conditional. You might also find this useful: Merchant of Record for Platforms and the Ownership Decisions That Matter.
Before launch, lock the exact point of user confirmation, where authorization is attempted, and who can still decline the order. If those three moments are not explicit, your checkout design is not ready.
In current agent-assisted flows, the split is straightforward: the agent handles checkout presentation and collects user-provided purchase details, while merchant systems still make the final accept or decline decision and return that status to the agent surface. OpenAI's flow is endpoint-driven, so the agent calls merchant ACP endpoints to create or update checkout sessions before the merchant returns order state.
Define the handoff in order:
| Step | Checkpoint |
|---|---|
| 1 | User gives purchase-confirming input in the agent UI |
| 2 | Agent/channel calls your ACP endpoint to create or update the checkout session |
| 3 | Payment layer attempts authorization and exposes the actual payment state |
| 4 | Merchant logic returns accepted, declined, or needs_user_action to the user-facing surface |
Model non-happy paths explicitly. For example, Stripe PaymentIntents can move to requires_action for additional authentication or requires_payment_method after a payment failure, so a catch-all "submitted" status is not enough.
Direct ACP integration gives you explicit endpoint-level control, but you own more day-to-day integration behavior across agents and session flows. If you plan to use OpenAI Instant Checkout, treat partner approval as a launch dependency.
An aggregated path like Agentic Commerce Suite can reduce channel-by-channel work by giving you a single integration path. It does not remove requirements for expiration handling, retry safety, or payment-state management.
If your team cannot safely support multiple ACP variants, start with one path, prove it in production, then expand agent by agent.
Handle these cases up front:
| Case | Required handling |
|---|---|
| Stale session | Expired checkout sessions cannot be completed; return an explicit expired state and offer restart |
| Failed or interrupted authorization | Route requires_action and requires_payment_method to a user-completed step, not a silent dead end |
| Duplicate submit | Use idempotency keys so retries do not create duplicate operations |
Treat retries as an API and state-model concern, not just a UI concern. The user-facing status should clearly show whether the attempt is pending, failed, or handed off to standard checkout.
For a step-by-step walkthrough, see How to Choose a Merchant of Record Partner for Platform Teams.
Before you scale agent-assisted checkout, lock ownership for each failure event: who takes the loss, who investigates, and which evidence is retrievable by transaction ID.
After authorization mapping, build a responsibility matrix by event type, not around a generic fraud owner. For the Merchant of Record, be explicit about who runs review, who submits dispute evidence, and who approves refunds or write-offs when the issue is not payment fraud.
| Event type | Dispute or risk category to map | Primary owner questions | Evidence you should already have |
|---|---|---|---|
| Unauthorized purchase | Fraud dispute categories, including card-absent fraud such as Visa 10.4 Other Fraud | Who proves the buyer authorized the purchase? Who responds to the issuer? | Consent proof, authorization timestamp, payment reference ID, user session or actor identity context |
| Fulfillment mismatch | Product not received 13.1 or not-as-described style claims | Who proves delivery or service completion? Who owns remediation? | Fulfillment details, delivery status, communication logs, receipts, policy disclosures |
| Charge dispute | Formal issuer dispute process | Who submits the evidence pack and tracks deadlines? | Provider dispute ID, payment ID, receipts, communications, system logs grouped by type |
| Identity mismatch | Buyer identity or account-context mismatch | Who verifies the actor matched the intended buyer account at purchase time? | Account identifier, session context, consent event, any step-up authentication result |
Structure records the way dispute teams need them: separate receipts, communications, policies, and system logs. For each order, require at least four artifacts from day one: consent proof shown in the agent UI, auth timestamp, actor identity context, and provider reference IDs (such as payment or dispute ID).
Classify events against known dispute families early. Fraudulent card-absent claims and fulfillment claims require different evidence, so your matrix should treat them differently. Visa's Compelling Evidence 3.0 update for dispute code 10.4 took effect on 15 April 2023, which is a practical reminder that evidence standards change.
Run a quick audit on recent transactions and confirm you can pull the full pack quickly. If logs, receipts, and communications sit in separate systems without shared reference IDs, dispute handling will slow down under load.
Tighten authorization when dispute costs rise faster than the conversion gains from looser agent behavior. A dispute reverses payment and adds a dispute fee, and cases can take 2-3 months to resolve. In practice, tightening can mean a clearer user confirmation step, stronger identity context, or routing more orders into a user-completed checkout step.
Early patterns may not match legacy bot-fraud assumptions. As one marketplace risk leader put it, "One of the first challenges teams are running into is that bot-driven fraud doesn't look the way it used to." Use that as a signal to expand autonomy carefully.
Related: Paddle vs. Stripe: A Comparison for SaaS Founders.
Once liability is assigned, your finance logic has to match it end to end. If finance cannot explain a transaction from order creation through payout and later adjustments, do not open new agent channels yet.
Principal versus agent under ASC 606 is a control assessment, not a presentation election. Start with two questions: what is the specified good or service, and who controls it before transfer? That conclusion drives gross-versus-net reporting.
| Operating model | ASC 606 question to answer | Revenue presentation implication |
|---|---|---|
| Platform-led MoR | Does the platform control the specified good or service before transfer, or is it arranging for another party to provide it? | Could support gross presentation if control exists before transfer; if not, net presentation may be more appropriate |
| Merchant-led MoR | Does the merchant retain control through fulfillment and customer transfer, with the platform only arranging access, demand, or payment flow? | Often points toward the platform presenting net fees if it is acting as an intermediary, but the contract and facts still decide |
| Hybrid delegation | Which party actually controls the specified good or service at the transfer point, especially when checkout, support, or refunds are split? | Most likely to create mixed indicators, so document the control analysis clearly before choosing gross or net reporting |
Use this as a decision prompt, not a shortcut. The memo should follow control analysis, contract terms, and operating facts.
ASC 606 does not require a daily cadence, but daily reconciliation is a practical control for agent-assisted checkout at scale. Build one chain that connects commercial events, payment events, accounting entries, and exception handling before payout close.
At minimum, reconcile these four layers every day:
If you use Stripe, balance transactions are a strong accounting starting point because they provide a ledger-style record of inflows and outflows. The source field gives related object IDs for lineage tracing. Automatic payouts help preserve transaction-to-payout linkage, and reconciliation pulls can be triggered when payout.paid or payout.reconciliation_completed arrives.
Two failure modes to avoid: reconciling only cash movement while ignoring the commercial event trail, and letting teams key records on different IDs so payouts cannot be traced back to the original order and decision path.
Define a repeatable internal audit pack for each payout or settlement cycle:
Keep adjustment history as separate records rather than overwriting prior entries. If your team cannot pull one payout pack and show the full chain, including later adjustments, pause rollout until that is fixed.
This pairs well with our guide on What is a Merchant of Record (MoR) and How Does It Work?.
Want a quick next step? Try the free invoice generator.
Implement in the same order you decided liability and transaction ownership: role decision sign-off, contract language, integration path, event mapping, reconciliation tests, then controlled rollout. This keeps product, engineering, and ops working from one state model instead of patching conflicts later.
Pick one object as the commercial source of truth for the flow and align every team to it. In OpenAI commerce specs, the merchant-managed Checkout session carries item, fulfillment, and payment information, so it can anchor both UX and reconciliation.
Before launch work starts, document which event moves a session from created to authorized, paid, fulfilled, refunded, or failed. If that mapping is ambiguous, duplicate charges, premature fulfillment, and hard-to-explain exceptions follow.
Use explicit checkpoints by team so gaps are visible early:
| Team | Responsibilities |
|---|---|
| Product | Flow design, confirmation points, and buyer-facing status states |
| Engineering | Request authentication, signature verification, idempotent POST retries, and durable event handling |
| Ops | Exception queues, replay handling, and manual override decisions when automation cannot resolve safely |
Treat retries and duplicate delivery as normal operating conditions. Stripe recommends idempotency keys on POST requests, supports safe retries, and expects fulfillment handlers to tolerate repeated execution for the same Checkout Session ID.
For Stripe APIs, do not treat redirect completion or a success page as proof of payment. Use server-side payment state (payment_status) for fulfillment transitions, and treat client callbacks and UI success states as informational only.
For delayed methods, define the exact transition event up front. checkout.session.async_payment_succeeded is the completion signal when a delayed method eventually succeeds, and webhook deliveries can be retried for up to three days, so your state machine must handle delay, replay, and out-of-order arrival.
Before production, run this minimum test set:
If any test marks an order paid without a server-verified payment signal, stop rollout and fix that first.
Related: Home Office Deduction for Real Estate Agents: Qualify, Choose a Method, and Keep Records.
Treat country and program eligibility as a go-live blocker. A merchant-of-record setup that works in one market can fail in another because onboarding requirements, payout eligibility, tax handling, and available payment options vary by jurisdiction. Confirm coverage first, then scope rollout.
On Stripe Connect, required verification information depends on account location, business type, and requested capabilities. Connected accounts can only perform actions for capabilities that are active. Cross-border payouts are conditional, and payout/settlement rules are still tied to the connected account's bank-country context, even where multi-currency support exists (up to 18 supported currencies).
Use a written provider confirmation checkpoint for your exact markets and transaction pattern. Confirm:
If policy is unclear for agent-assisted or autonomous transaction flows, pause rollout and request explicit acceptance criteria in writing.
Keep a short go-live gate list signed by finance, legal, and ops:
This risk is practical, not theoretical. OpenAI's September 29, 2025 Instant Checkout launch started with a narrow scope: U.S. ChatGPT Plus, Pro, and Free users buying from U.S. Etsy sellers, with single-item purchases first. Plan for that pattern: provider rollout scope may be narrower than your target footprint at launch.
See also: When to Use an Employer of Record for International Hiring.
The practical win here is not choosing the newest protocol or checkout surface first. It is choosing a Merchant of Record and buyer-accountability model that your legal, finance, product, and engineering owners can all explain the same way when an order fails, a dispute lands, or revenue gets reviewed.
That matters because current signals point to constrained, agent-assisted commerce, not open-ended autonomous spend. OpenAI's delegated payment request is tied to what the user selected to buy, with a maximum chargeable amount and an expiry, and the actual checkout state and payment processing occur on the merchant's systems. Other protocol designs make a similar point from another direction: you own your business logic, and you remain the Merchant of Record. Different protocols may package the flow differently, but they do not remove the need to assign liability, consent handling, and accounting ownership clearly.
If you take one operating recommendation from this piece, let it be this: start from the assumption that your first launch needs explicit user-linked consent, merchant-owned order accountability, and finance-approved revenue treatment. Do not expand to broader agent behavior until you can prove three things in production:
The common failure mode is not technical polish. It is organizational mismatch. Product assumes the platform is orchestrating the sale. Engineering builds around that assumption. Then provider rules or contract language may still treat the merchant as the selling party, while finance realizes principal-versus-agent is a facts-and-circumstances judgment rather than a reporting preference. Once that happens, you are not just cleaning up UX. You are rewriting contracts, receipts, support ownership, and revenue presentation after launch.
So keep the next step small and concrete. Run one internal decision session using your model comparison table and launch gates. Force answers on four points before more roadmap scope gets approved: who sells, who buys, who can accept or decline the order, and who owns dispute and reconciliation outcomes. Any policy question you cannot answer internally should go back to providers in writing, especially where protocol fragmentation means support for multiple approaches may be needed.
If those answers hold up under review, you are ready to scale carefully. If they do not, pause there. In this category, disciplined clarity beats speed.
Want to confirm what's supported for your specific country/program? Talk to Gruv.
In current implementations, MoR responsibility often sits with the merchant that sells to the end customer. In OpenAI’s Agentic Checkout materials, OpenAI explicitly says it is not the merchant of record, and the merchant still accepts or declines the order. In some payment facilitator structures, the answer shifts by program rules. Adyen, for example, says the platform’s user is considered the MoR for card-scheme data requirements.
Treat current production designs as agent-assisted unless a provider clearly documents otherwise. OpenAI’s ACP flow says ChatGPT collects buyer, fulfillment, and payment information from the user before the merchant processes the order, which shows that human-linked input is still central. If a provider markets autonomy but cannot show where user details enter the flow and who makes the accept/decline decision, slow down.
MoR is the legal entity selling to the customer and carrying the core seller obligations. Buyer of Record is often used as an operational label for the buyer identity in the transaction record, but you should not assume one universal legal definition across jurisdictions. The practical test is simple: if you cannot show who bought, who sold, and who accepted the order, operations and accounting get harder.
You should not assume that as the default pattern. In ACP, ChatGPT collects the buyer, fulfillment, and payment details from the user, and the merchant then decides whether to accept the order. OpenAI also says supporting Instant Checkout requires merchants to implement three flows, which is another clue that this is structured commerce logic, not free-form autonomous purchasing.
Decide who is the seller in the transaction and who controls order acceptance. That choice shapes contracts, dispute handling, revenue presentation, and the evidence you must retain. If your team is still debating whether the platform or the merchant is really selling, do not start integration yet.
Get written confirmation for your exact AI-agent use case, not a generic marketplace yes. Verify who the provider treats as MoR in that program, whether AI-agent checkout is accepted at all, what buyer and payment data is collected from the user, and who has the final accept or decline decision on the order. One risk is building around platform-led assumptions only to learn the provider or scheme rules assign seller responsibility differently.
They matter early, not after launch. PwC’s ASC 606 guidance says principal versus agent applies when there are three or more parties, and it is often helpful to assess it before working through the rest of the revenue model. If finance may conclude you are arranging another party’s sale rather than providing it yourself, avoid product and contract language that assumes you are the seller. If you need a deeper accounting pass, use this next: ASC 606 for Merchant-of-Record Platforms: Principal vs Agent Revenue Recognition.
Ethan covers payment processing, merchant accounts, and dispute-proof workflows that protect revenue without creating compliance risk.
Includes 2 external sources outside the trusted-domain allowlist.
Educational content only. Not legal, tax, or financial advice.
If you run a Merchant of Record flow, cash movement is not your revenue policy. Under ASC 606, the hard part is that customer payment, processor settlement, and the point when revenue is actually earned can sit on different dates and in different records.
For merchant-of-record teams, the **ASC 606 principal vs agent merchant of record** call is a high-stakes judgment, not a presentation preference. It can move revenue from gross to net and raise the level of judgment finance, audit, and compliance teams need to defend.
**Paddle vs Stripe is a risk-ownership decision first, so choose the setup that keeps cashflow stable when tax, refunds, and disputes show up together.** If you are the CEO of a business-of-one, you are not just picking a checkout. You are deciding who carries the operational burden when things get messy.