

Choosing between a merchant of record and a direct payment setup affects how an Indian business sells, collects, documents, and reconciles overseas payments. Indian businesses selling globally must examine these responsibilities before selecting a provider. A convenient checkout alone does not confirm that the tax, settlement, and documentation structure suits the company.
Consider an Indian software company selling an annual subscription to a customer in Germany. Under a third-party merchant of record, the provider may appear as the seller, manage the customer invoice, collect German VAT, process refunds, and send the Indian company a net payout. With a direct payment gateway arrangement, the software company keeps the customer relationship and remains responsible for the commercial transaction.
The merchant of record vs payment gateway decision depends on the countries where the business plans to sell, the strength of its finance and compliance teams, the level of control it needs over customers and billing, and its ability to manage tax, payment, and documentation requirements across borders.
This blog compares both structures from an Indian business perspective.
A merchant of record is the entity registered as the merchant for a completed purchase. Its identity appears across the checkout terms, payment authorization data, purchase receipt, and card statement descriptor. Acquiring banks and card networks recognize this entity as the responsible party for that transaction.
The company that creates or delivers the product may hold a different role. A business can use its own registered merchant identity, appoint an external provider, or assign the position only to selected transactions. The written agreement and payment records must support the same arrangement.
A buyer can identify the recorded merchant by checking:
Merchant of Record Example
Think of an Indian game studio that sells a downloadable expansion pack through an online marketplace. The marketplace appears in the purchase terms and on the buyer’s card statement, while the studio supplies the digital content. In this merchant of record example, the marketplace holds the recorded merchant position for the purchase.
A merchant of record connects the product company to its payment, risk, accounting, and payout systems through a formal service agreement. The arrangement begins before the first order reaches the platform.
The process follows these stages:
Business verification
The provider checks the company’s registration details, ownership, website, product category, pricing model, expected sales volume, and delivery method. It may request further records when the product carries a higher financial or regulatory risk.
Product configuration
The company adds its catalog, prices, subscription periods, supported currencies, cancellation rules, and fulfillment conditions. The provider uses this information to configure transaction controls and reporting fields.
Transaction screening
The system reviews signals such as the buyer’s location, device, card activity, purchase value, and earlier payment behavior. It may approve the order, block it, or send it for further review.
Fulfilment confirmation
After approval, the provider sends a notification through an API, plugin, or webhook, plugin, or webhook. The product company can then activate an account, release a download, or begin the purchased service.
Ledger calculation
The platform records the gross order amount and every contractual deduction as separate entries. These may include provider charges, currency adjustments, reserves, or earlier account corrections.
Payout processing
The provider transfers the resulting balance according to the agreed schedule. A detailed statement should connect each payout with the orders and deductions included in it.
Consider an Indian cybersecurity company that sells a one-year software license for $1,200. Assume its agreement sets a 5% provider charge and a temporary 10% reserve for new accounts. The ledger would record:
The provider may release the $120 reserve later if the account meets the conditions stated in the agreement. This itemized record allows the company to verify why the bank transfer differs from the original order value.
Read more: Merchant Category Codes (MCC): Meaning, Benefits and Importance
A merchant of record can create compliance and accounting issues when the contract, invoice, and bank records do not describe the same supply. Indian businesses must verify five areas before using this model.
Section 2(6) of the Integrated Goods and Services Tax Act sets the conditions for an export of services. The Indian supplier must prove:
An overseas provider’s location does not, on its own, satisfy these conditions. The contract must identify the party receiving the Indian company’s service.
CBIC treats a business as an intermediary when it arranges a supply between two other parties instead of supplying the main service on its own account. A reseller agreement offers stronger support when the overseas provider buys the service and resells it independently. Risk increases when the Indian company deals directly with the final customer and the provider only arranges payment or the sale.
An export-of-services refund may require a Bank Realization Certificate, Foreign Inward Remittance Certificate, or another accepted remittance record. A single monthly credit may cover several invoices, refunds, and deductions. The finance team must obtain a statement linking the bank receipt to each export invoice included in the amount.
The RBI regulates payment aggregators that handle eligible cross-border e-commerce payments. An Indian business should confirm:
The checkout brand may not be the regulated entity that handles the cross-border flow.
The agreement should explain how the provider will handle:
Consider this example: an Indian software company may raise four export invoices of $10,000 each, while its bank receives one payment of $37,600 after provider charges and customer adjustments. Without an invoice-level statement, the company cannot clearly match the remittance with all four invoices during reconciliation or a GST refund review.
A payment gateway is a technology layer that securely transmits payment information between the customer, the merchant, the acquiring bank, and the issuing bank. Its primary role is to facilitate payment authorization by carrying transaction data through the required banking and card-network infrastructure.
In India, a payment gateway does not collect or settle customer funds. Under the Reserve Bank of India (RBI) framework, it functions as a technology service that supports payment processing, while payment collection and settlement are performed through a payment aggregator or acquiring institution.
When a customer enters card details, authorizes a UPI payment, or chooses another supported payment method, the gateway encrypts the transaction data and routes it to the relevant payment network. The customer receives an approval or decline message within seconds, while settlement follows separately according to the merchant's agreement with its payment partner.
For businesses selling online, a payment gateway can support multiple payment methods such as cards, UPI, net banking, digital wallets, and international payment instruments through a single integration. Many gateways also provide additional capabilities including recurring payments, tokenization, fraud controls, payment analytics, refund management, and checkout customization.
Unlike a merchant of record, a secure payment gateway does not become the seller in the transaction. The business continues to own the customer relationship, issue invoices, manage tax obligations, handle customer support, and remain responsible for the commercial transaction.
Consider an Indian SaaS company selling subscriptions directly to customers in the United Kingdom. When a customer completes a payment on the company's website, the payment gateway securely routes the transaction for authorization and returns the payment status. The SaaS company remains the seller of record, issues the invoice, manages VAT or other applicable tax obligations, handles refunds, and receives settlement through its payment partners according to the agreed terms.
A third-party MOR runs a broader sales operation, while a gateway handles the technical movement of payment instructions. Under the RBI framework, the gateway does not hold customer funds. A payment aggregator or acquiring partner performs the collection and settlement function.
The main difference is control. A merchant of record can reduce operational workload, but the business gives up some control over checkout, data, taxes, refunds, and settlements. A direct payment gateway setup gives the business more control, but also more responsibility.
| Comparison Point | Merchant of Record | Payment Gateway with Direct Merchant Setup |
|---|---|---|
| Regulatory position in India | MOR is a commercial role, not a separate RBI payment category | RBI defines the gateway as technology that facilitates payment processing without handling funds |
| Operating model | Uses the provider's standard sales, risk, and reporting system | Lets the business build its own payment stack around the gateway and aggregator |
| Transaction controls | Provider sets approval rules, restricted categories, and risk limits | Merchant configures available controls within the provider's and card network's rules |
| Data access | Provider decides the level of order and payment data shared | Merchant receives direct access to transaction status, failure codes, and payment performance |
| Cost basis | Charges a bundled fee for several connected services | Charges for payment processing, while the business pays separately for its own operations |
| Implementation | Requires the business to follow the provider's fixed integration and operating standards | Allows greater flexibility through APIs, plugins, software development kits, and custom checkout flows |
| Suitable use case | Suits businesses that want to outsource several parts of international commerce | Suits businesses that already have finance, legal, tax, and payment teams in place |
Suppose an Indian SaaS provider reviews 900 card payment attempts from its UK customers over one month. The report identifies 150 failed authentications, showing that available funds were not the underlying issue. With a direct setup, the payments team can review the issuer response codes, adjust its authentication settings within network rules, and measure whether the change improves approval rates. Under an MOR arrangement, the company can act only on the data and configuration access included in the provider agreement. This makes direct payment control valuable when the business has the expertise to analyze failures and manage checkout performance.
A direct payment gateway setup is suitable when the business needs payment operations to follow its own product, billing, and fulfillment rules.
Payment Actions Can Match the Order Lifecycle
A direct integration of a payment gateway can support separate authorization, capture, void, and refund actions, subject to provider and card-network rules. This structure works well for businesses that confirm inventory, hotel room availability, service completion, or delivery before collecting the final payment.
Subscription Changes Remain Under Business Control
The company can manage plan upgrades, downgrades, trial conversions, prorated charges, renewal dates, and cancellation rules through its billing system. It does not need an external reseller to approve each change to the subscription structure.
Product and Pricing Updates Can Move Faster
The company can introduce new plans, bundles, discount codes, payment schedules, or country-specific prices within the limits of its provider agreement and applicable law. A third-party merchant of record may require additional review because it assumes responsibility for the customer-facing sale.
Payment Stack Can Be Built With More Flexibility
A direct payment gateway setup allows businesses to build their payment stack around more than one processor, acquiring partner, fraud tool, subscription billing system, tax-support layer, or foreign exchange service, where such integrations are supported. This reduces dependence on a single provider and helps established businesses replace or optimize one service without moving their entire international sales operation.
Fraud and Chargeback Protection in MOR
A merchant of record can manage fraud checks and card disputes, but the supplier agreement decides who bears the final financial loss. Fraud prevention and chargeback handling also occur at different stages of the payment cycle.
Fraud Controls Act Before Authorization
The provider may use card verification values, 3D Secure authentication, velocity limits, sanctions screening, and risk scoring before sending a transaction for approval. These controls can reduce suspicious orders, but no system can prevent every unauthorized payment.
Chargebacks Require Transaction Evidence
A chargeback begins when a cardholder disputes a completed payment through the issuing bank. The provider must respond within the card network’s deadline and submit evidence that supports the transaction.
Relevant records may include:
The issuing bank and card network processes determine whether the evidence supports the original payment.
The Contract Decides Who Absorbs the Loss
A provider may handle the dispute without accepting the final cost. Its agreement may allow it to deduct the disputed amount, charge an administration fee, or recover losses linked to the supplier’s product or conduct.
Businesses should check:
Visa Applies Rules Based on the Actual Payment Role
Visa rules apply based on the transaction role and acquiring structure, not merely the marketing label ‘merchant of record. Its public rules classify participants according to their actual functions, such as merchant, payment facilitator, sponsored merchant, or marketplace.
The applicable Visa rules for a merchant of record, therefore, depend on how the provider enters the acquiring and card-network structure. A marketing label cannot replace the legal and network classification used in the transaction.
Choosing between a merchant of record and a direct payment setup should be based on verified contracts, payment roles, and regulatory evidence rather than on provider claims. Indian businesses must test the arrangement against RBI payment classifications, the export-of-services conditions under the IGST Act, card-network requirements, and the actual allocation of financial risk. A merchant of record may reduce the workload linked to overseas sales, while a direct setup preserves greater operational authority. Before signing, the business should obtain written clarity on settlement records, chargeback liability, tax responsibilities, data access, and exit rights.
1. How long does the merchant of record onboarding take?
Onboarding time varies by provider, business type, ownership structure, product risk, and document quality. Straightforward digital businesses may complete verification quickly, while complex ownership structures, regulated products, or missing records can extend the review and delay activation.
2. Can a merchant of record offer local payment methods?
A merchant of record may offer local wallets, bank transfers, direct debit, or regional card methods where its network supports them. Businesses should confirm country coverage, settlement rules, refund handling, and any extra fees before launch.
3. Can a Merchant of Record be used for physical goods?
Some providers support physical goods, but many specialize in software and digital products. Physical sales also require stronger controls over shipping, customs, returns, proof of delivery, product liability, and country-specific consumer protection obligations.
4. Who provides customer support under an MOR arrangement?
Customer support duties depend on the provider agreement. The MOR may handle payment questions, receipts, and billing issues, while the product company manages technical help, delivery problems, account access, and product performance complaints.
5. Can a Merchant of Record support B2B sales?
A merchant of record can support business-to-business sales by offering bank transfers, purchase-order workflows, tax-exemption handling, and invoice-based collections. Companies should verify credit terms, approval limits, debtor follow-up, and the impact of unpaid invoices on payouts.
6. Does a Merchant of Record handle local e-invoicing requirements?
Local e-invoicing support depends on the provider’s registrations and technical coverage. Businesses should confirm whether the MOR creates compliant invoice formats, submits data to government portals, stores records, and handles correction or cancellation requirements.
7. Can an online marketplace use a Merchant of Record?
A marketplace can use an MOR structure, but the contract must clearly allocate responsibilities among the platform, sellers, and providers. Product approval, seller verification, payment splitting, complaints, and prohibited-item controls need separate rules.
8. How does an MOR arrangement affect revenue recognition?
Revenue recognition does not automatically follow the cash received from an MOR. The company must assess its contract, performance obligations, principal-versus-agent position, deductions, and accounting policy in accordance with the standards applicable to its financial statements.
9. Who pays foreign exchange charges in an MOR transaction?
Foreign exchange costs may arise at checkout, during card conversion, or when the provider pays the supplier. Businesses should check the pricing currency, cardholder conversion option, exchange-rate source, applied markup, settlement currency, and conversion date.
10. Can a Merchant of Record support usage-based billing?
Usage-based billing requires the provider to accept accurate consumption data, calculate charges, issue adjustments, and manage late usage updates. Before adopting an MOR, a business should test metering rules, billing cut-offs, dispute handling, and audit records.