Stripe Merchant of Record

Three rows decide it, and only three

Stripe publishes the mapping as a short list, and it is worth reading as a decision table rather than as prose. Configure the charge type and, where appropriate, the `on_behalf_of` setting for each transaction, based on who the MoR should be:

- **Direct charges:** "The merchant of record is the connected account." - **Indirect charges using the `on_behalf_of` parameter:** "The merchant of record is the connected account." Stripe attaches a condition to this one, covered in the next section. - **Indirect charges without using the `on_behalf_of` parameter:** "The merchant of record is the platform."

So the default for an indirect charge is that your platform is the legal seller. Destination charges and separate charges and transfers are both indirect, which means a platform that never sets `on_behalf_of` is the merchant of record for every sale its connected accounts make, whether or not anyone intended that.

There is also a hard prerequisite on newer accounts. Stripe: "For a connected account created using the Accounts v2 API to be the MoR, it must have the `merchant` configuration. Otherwise, payments will fail." That is a failure at charge time rather than a silent misassignment, which makes it the friendlier of the two ways to get this wrong.

The line in the table that is not symmetrical

The second row carries a qualifier that changes what "the connected account is the MoR" is worth to a platform. Stripe, in full: "The merchant of record is the connected account. However, if a connected account’s balance becomes negative, your platform is ultimately responsible for covering any losses."

Read those two sentences together and the arrangement is clearer than either alone. `on_behalf_of` moves the legal seller position to the connected account. It does not move the financial backstop, which stays with the platform. A platform using indirect charges with `on_behalf_of` has assigned the liability that card networks care about while keeping the one its bank account cares about.

That asymmetry is the reason the parameter is worth understanding on its own terms. Stripe’s own glossary entry for it describes `on_behalf_of` as "a parameter that allows a Connect platform to create an indirect payment where the connected account is the merchant of record (MoR)", which ties the two concepts together explicitly. What that parameter separately changes about settlement country, fee schedule and branding is covered in the Stripe on_behalf_of entry linked below.

The default you picked at onboarding, and the one you may have overridden since

Stripe ties the MoR to the business model you declared. "When you onboard your platform and decide whether to operate as a SaaS platform or as a marketplace, you also define the MoR for your transactions: for most SaaS platforms, connected accounts are the MoRs, and for most marketplaces, the platform is the MoR." If you onboard as a marketplace, Stripe asks you to acknowledge the responsibilities that come with it.

The warning worth pinning to that is about what happens afterwards. Stripe: "Some integrations use non-standard charge types. For example, a SaaS platform might use destination charges for certain transactions. For those transactions, the MoR is the SaaS platform, not the connected account."

This is the practical trap. A SaaS platform whose whole model assumes its customers are the sellers can reassign the seller role to itself for a subset of transactions by choosing a convenient charge type, for reasons that are usually about funds flow rather than about liability. Stripe’s instruction in that case is not to avoid it but to be honest about it: "If you use non-standard charges, you need to make sure that every transaction clearly identifies the MoR to the customer."

Worth auditing by charge type rather than by intent, because the intent lives in a design document and the charge type lives in the API call.

What the customer has to be told

The MoR rules are not satisfied by getting the API right. Stripe is explicit that the customer-facing surface has to match: "The customer-facing website, payment flow, and terms of service must clearly identify that party, whether it’s your platform or a connected account. The customer needs to understand that any transaction is with the MoR, and only with the MoR."

Stripe’s illustration is a storefront that carries a SaaS platform’s logo: "The page must make clear that purchases through the website are with the connected account’s business, and that the SaaS platform has no responsibility for fulfilling those purchases." The same logic extends to multiparty customer service, where "if a third party provides customer service, the customer must understand who has responsibility for providing the service", and to returns, where the customer must understand who is responsible for any refund.

Statement descriptors are where this becomes concrete, because Stripe fills them from the MoR by default. For non-card payments, "if you don’t specify the statement descriptor, Stripe uses the MoR’s statement descriptor". For a dynamic card descriptor, Stripe "sets the statement descriptor by appending '* ' (an asterisk and a space) and the suffix to the MoR’s statement descriptor prefix", falling back to the first several characters of the MoR’s statement descriptor when no prefix is defined. For a static one, Stripe simply uses the MoR’s descriptor, and you cannot specify a static descriptor when you create a payment.

So the descriptor is a readout of who Stripe thinks the seller is. If a cardholder is seeing a name that surprises you, that is worth treating as evidence about the charge type rather than as a formatting problem.

Why a bookkeeper should care about a compliance field

The MoR question and the revenue question are the same question asked by two departments.

Stripe’s description of the role is that the MoR receives the customer’s payment, appears on the receipt, bears responsibility for the goods or services, and is liable for disputes and refunds. Those are the attributes that normally decide which entity books a sale as its own revenue, and which entity books the cost of a refund.

This does not resolve itself into a single accounting answer, because the presentation question (gross or net, platform or connected account) depends on the specific arrangement and on the standards you report under. It is a conversation to have with your accountant. What the Connect configuration gives you is the input to that conversation, and the useful discipline is to make sure the input is accurate before the volume gets large: run the charge-type audit, confirm whether `on_behalf_of` is set, and check that the answer matches what your revenue policy assumes.

One adjacent case is worth separating out, because it uses the same words for a different arrangement. Under Stripe Managed Payments, Stripe itself is the merchant of record and Connect is not supported at all, which makes it a different question from the platform-versus-connected-account one on this page. The accounting consequences of that arrangement are covered separately in our writeup on Stripe Managed Payments, linked below.