Understand the merchant of record in a Connect integration

Because Connect integrations involve multiple businesses, you need to understand the concept of the merchant of record (MoR) when designing your integration. The MoR is the entity with legal responsibility for a transaction. It can be your platform or your connected accounts, depending on your configuration. The card networks enforce MoR rules, and violations can result in significant fines for your platform and for Stripe.

Think of the MoR as the party that receives a customer’s payment, appears on the statement or receipt and bears responsibility for the purchased goods or services. The MoR is also liable for any disputes or refunds related to the purchase. 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. In the case of a marketplace, although a third party might provide the actual product or service, customers conduct their transactions with the marketplace. They see the marketplace’s branding on the storefront, payment interface and transaction receipts.

In addition, each transaction must clearly identify the MoR so the customer knows who receives their payment. Typically, the MoR appears in the order confirmation and transaction receipt. To avoid customer confusion, define your statement descriptor to identify the same entity.

Define the merchant of record

Configure your Connect integration to use the correct charge type and, if appropriate, on_behalf_of setting for each transaction, based on the MoR:

• 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. However, if a connected account’s balance becomes negative, your platform is ultimately responsible for covering any losses.
• Indirect charges without using the on_behalf_of parameter: The merchant of record is the platform.

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 of being the MoR.

Use statement descriptors

You can define statement descriptors for your platform, for your connected accounts and for individual transactions. Statement descriptors can have both static and dynamic components.

When you create a transaction, Stripe sets the statement descriptor according to the payment method:

• Non-card payments: You can define the full statement descriptor when you create the payment. If you don’t specify the statement descriptor, Stripe uses the MoR’s statement descriptor.
• Card payments: You can use dynamic or static statement descriptors.
  • Dynamic: Specify a statement descriptor suffix when you create the payment. Stripe sets the statement descriptor by appending "* " (an asterisk and a space) and the suffix to the MoR’s statement descriptor prefix. If you didn’t define a statement descriptor prefix, Stripe uses the first several characters of the MoR’s statement descriptor as the prefix.
  • Static: Don’t specify a statement descriptor suffix. Stripe uses the MoR’s statement descriptor. You can’t specify a static statement descriptor when you create a payment.

Consider details that potentially affect the merchant of record

These factors can affect your compliance with payment network rules, so make sure that you understand how they apply to your integration.

Clear identification of the merchant of record

Connect integrations can involve complex business relationships where the MoR might not always be obvious. For example, consider a page on a connected account’s online storefront that contains the logo of a SaaS platform the account uses for some services. 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.

Customer service responsibility

In addition, if you implement multiparty customer service processes, you must make sure that they conform to network rules. If a third party provides customer service, the customer must understand who has responsibility for providing the service. If a third party physically takes possession of returned goods, the customer must understand who has responsibility for any refund.

Merchant category

Some payment network rules can depend on a business’ merchant category code (MCC). If you manually set MCCs for your connected accounts, make sure that you assign the correct codes.

Ownership and possession of goods for sale

Payment networks also have rules about the ownership of goods for sale. These rules can affect goods that might be in the possession of both the platform and a connected account during the fulfilment process.