What Is a Merchant of Record
Definition
A Merchant of Record (MoR) is the entity that is legally authorized to process a customer's payment and appears on the customer's bank or credit card statement. The MoR assumes liability for the transaction, including chargebacks, refunds, tax collection, and regulatory compliance.
How It Works
When a customer makes a purchase, the Merchant of Record is the legal seller in the eyes of the card networks and banks. The MoR's name appears on the cardholder statement, and the MoR is responsible for handling disputes, collecting and remitting sales tax, managing PCI compliance, and ensuring the transaction meets card network rules. In platform and marketplace models, the MoR can be the platform itself, the individual seller, or a third-party service.
Why ISVs Care
The MoR question is fundamental to how an ISV structures its payment integration. If the ISV is the MoR, it takes on liability but gains control over pricing, branding, and the full payment experience. If each merchant is their own MoR, the ISV avoids liability but loses control. PayFac-as-a-Service and marketplace payment models offer middle-ground options where the ISV can act as the MoR without building the full compliance infrastructure.
Merchant of Record is the entity whose name appears on a customer’s credit card statement — and more importantly, the entity legally responsible for every aspect of that transaction.
Why Merchant of Record Matters for ISVs
When you embed payments into your software, one of the first architectural decisions is: who is the Merchant of Record?
This isn’t just a legal technicality. The MoR decision determines:
- Who handles chargebacks — The MoR is liable for all disputes
- Who collects and remits taxes — Sales tax, VAT, and other transaction taxes are the MoR’s responsibility
- Whose name appears on statements — This affects brand recognition and customer trust
- Who owns the customer payment relationship — Including refund policies and compliance obligations
The Three MoR Models for ISVs
1. Merchant Is Their Own MoR
In a traditional payment gateway integration, each merchant on your platform has their own merchant account and is their own MoR. The ISV simply facilitates the connection to a payment processor.
Pros: No liability for the ISV, simple compliance posture Cons: Slow merchant onboarding (days to weeks), no payment revenue for the ISV, fragmented payment experience
2. ISV as Merchant of Record (PayFac Model)
When the ISV registers as a PayFac or uses PayFac-as-a-Service, the ISV becomes the MoR for all transactions processed through its platform. Sub-merchants operate under the ISV’s master merchant account.
Pros: Fast merchant onboarding (minutes), ISV earns payment revenue, unified payment experience Cons: ISV assumes chargeback liability, must manage compliance, needs fraud monitoring
3. Third-Party MoR Service
Companies like Paddle, FastSpring, and Lemon Squeezy act as the MoR on behalf of both the ISV and its merchants. The third-party handles taxes, compliance, chargebacks, and statement descriptors.
Pros: Zero compliance burden for the ISV, global tax handling included, minimal integration effort Cons: Less control over the payment experience, lower revenue per transaction, third-party branding on statements
MoR and Statement Descriptors
The MoR’s name on the cardholder statement has real business implications:
- Customer recognition: If customers don’t recognize the charge, they file chargebacks. An ISV acting as MoR can use a recognizable descriptor, but sub-merchant names may be unfamiliar to the end customer.
- Brand control: ISVs that want their brand (or their merchant’s brand) on statements need to structure their MoR relationship carefully. PayFac models often allow customizable statement descriptors per sub-merchant.
- Support routing: When customers call about a charge, the MoR’s support team handles it. ISVs need to plan for this volume if they’re the MoR.
Tax Implications of Being the MoR
The MoR is legally responsible for collecting and remitting sales tax. For ISVs operating across multiple states or countries, this creates significant complexity:
- Nexus determination: The MoR must track where it has tax obligations
- Rate calculation: Tax rates vary by jurisdiction, product type, and buyer status
- Filing and remittance: Monthly or quarterly tax filings in every jurisdiction with nexus
ISVs that don’t want to manage tax compliance often choose a third-party MoR or use tax automation services (Avalara, TaxJar) alongside their PayFac setup.
Choosing Your MoR Strategy
| Factor | Merchant as MoR | ISV as MoR (PayFac) | Third-Party MoR |
|---|---|---|---|
| Onboarding speed | Days-weeks | Minutes | Minutes |
| ISV payment revenue | None | 20-80+ bps | 5-15 bps |
| Chargeback liability | Merchant | ISV | Third party |
| Tax responsibility | Merchant | ISV | Third party |
| Brand control | Low | High | Low |
| Best for | Referral partnerships | Growth-stage ISVs | SaaS with global sales |
The right choice depends on your ISV’s scale, risk appetite, and how central payments are to your product strategy. Most ISVs in the embedded payments space are moving toward PayFac or PayFac-as-a-Service models because the revenue opportunity outweighs the compliance cost.