Adding a checkout page is easy. Choosing who legally sells your product is not.
When a customer buys your SaaS, someone must become responsible for accepting the payment, calculating the applicable tax, issuing the invoice, handling refunds, responding to disputes, and reporting the transaction to the relevant authorities.
With a traditional payment processor, that business is usually yours.
With a merchant of record, or MoR, another company becomes the legal seller for the transactions it processes on your behalf.
That distinction affects far more than sales tax. It influences your checkout experience, margins, cash flow, accounting, customer support, pricing models, billing architecture, expansion strategy, and ability to change providers later.
For a global SaaS business, the right question is therefore not:
Which provider charges the lowest transaction fee?
It is:
Which payment model gives this business the right balance of control, compliance responsibility, operational cost, and long-term flexibility?
This guide provides a practical framework for making that decision.
The Practical Answer
A merchant of record is often the better starting point when a small SaaS team wants to sell digital products internationally without building an internal tax and payment-compliance operation.
A payment processor is often the better choice when the business needs maximum checkout control, complex billing, custom enterprise contracts, direct customer invoicing, faster access to payment data, or lower marginal costs at meaningful transaction volume.
Neither model is automatically better.
The decision depends on what you sell, where your customers are located, how your pricing works, how much operational complexity your team can absorb, and how difficult it would be to change the payment system later.
What Is a Merchant of Record?
A merchant of record is the legal entity that sells a product or service to the end customer for a covered transaction.
The MoR typically processes the payment, calculates and collects applicable indirect taxes, issues compliant receipts or invoices, handles chargebacks and payment disputes, and remits collected tax to the appropriate authorities.
The customer is technically purchasing from the merchant of record, which is why the MoR’s name—or a descriptor containing its name—may appear on the customer’s card statement and transaction documents.
Providers such as Paddle, Lemon Squeezy, Polar, and Dodo Payments publicly describe themselves as merchants of record for eligible digital products.
Stripe also offers Stripe Managed Payments, a merchant-of-record product for eligible digital transactions. Stripe’s documentation currently identifies Managed Payments as a public-preview product, so availability and eligibility should be checked before designing a production billing system around it.
What the merchant of record handles
The exact responsibilities vary by agreement and provider, but an MoR commonly handles three major operational areas:
- Transaction compliance: indirect tax calculation, collection, invoicing, remittance, payment security, refunds, and disputes.
- Payment infrastructure: checkout, payment methods, currency handling, subscription collection, fraud screening, and settlement.
- Customer payment administration: payment receipts, billing-related questions, charge identification, and transaction records.
Your company still builds and operates the product.
You remain responsible for product delivery, account access, customer onboarding, technical support, privacy compliance, security, financial accounting, and the taxes your own business owes on its income or payouts.
Using an MoR does not make every legal or financial obligation disappear. Lemon Squeezy’s tax documentation, for example, distinguishes the sales taxes it handles as MoR from the taxes a seller may owe on income received through payouts.
What Is a Payment Processor?
A payment processor provides the infrastructure required to accept and move money, but your company normally remains the legal seller.
Stripe Payments is a familiar example. It can process cards, wallets, subscriptions, invoices, refunds, and other payment activity, but using standard Stripe Payments does not automatically make Stripe the merchant of record.
Your company is generally responsible for determining where it has tax obligations, registering in the relevant jurisdictions, collecting the correct amount, filing returns, remitting the tax, issuing appropriate documentation, and maintaining supporting records.
Tax software can automate much of this work.
For example, Stripe Tax can monitor obligations, calculate taxes, validate tax identifiers, produce reports, and support registration and filing workflows. However, under the standard processor model, the seller still has to configure its registrations and ensure that obligations are handled correctly.
Stripe’s documentation states that businesses must identify where they have tax obligations and register with the appropriate authorities before collecting tax in those locations. Filing frequency, registration rules, and reporting requirements vary between jurisdictions.
Merchant of Record vs Payment Processor Responsibilities
The most important difference is not the checkout interface. It is the allocation of responsibility.
| Responsibility | Payment processor model | Merchant-of-record model |
|---|---|---|
| Legal seller | Your company | The MoR for covered transactions |
| Payment processing | Processor | MoR and its payment partners |
| Indirect tax calculation | Your company or tax software | Usually handled by the MoR |
| Tax registration | Your company | Usually handled under the MoR’s registrations |
| Tax filing and remittance | Your company or filing partner | Usually handled by the MoR |
| Transaction invoices | Issued under your business | Issued under the MoR or reseller structure |
| Fraud screening | Your configuration and provider tools | Usually included in the MoR service |
| Chargebacks and disputes | Your responsibility, assisted by processor tools | Usually managed by the MoR |
| Product support | Your company | Your company |
| Billing-related support | Your company | Shared or handled by the MoR, depending on provider |
| Income and corporate tax | Your company | Your company |
| Checkout control | Usually higher | Usually more constrained |
| Customer payment data | More direct control | Depends on the MoR and agreement |
| Provider migration | Difficult but often more controllable | Can depend heavily on MoR migration support |
The word “usually” matters.
A contract, product category, market, or transaction type may change what the provider handles. Always verify the provider’s current terms, eligible product rules, supported countries, payout availability, and prohibited-business policies before committing.
Why This Decision Matters More for a Global SaaS
A SaaS product can become international before the company considers itself international.
A founder may launch in one country, price the product in a widely used currency, and receive purchases from several regions within the first week. That creates a cross-border transaction even when the company has no office, employee, or bank account in the customer’s country.
Different jurisdictions may apply VAT, GST, sales tax, digital-services rules, invoicing standards, business-customer exemptions, customer-location evidence requirements, or registration thresholds.
The complexity is not simply calculating a percentage.
The business may need to determine:
- Whether the product is taxable in that location.
- Whether the buyer is a business or consumer.
- Whether tax should be included in the displayed price.
- Which evidence establishes the customer’s location.
- Whether the customer’s tax identifier is valid.
- When the company must register.
- How often the company must file.
- How refunds and credit notes affect prior returns.
A tax-calculation API can solve the calculation step while leaving registration, filing, remittance, reconciliation, and legal responsibility with the seller.
An MoR moves more of that responsibility to the provider.
That additional coverage is the main reason an MoR generally costs more than basic payment processing.
The Real Cost Is More Than the Provider Fee
Comparing payment providers only by their headline percentage creates a misleading result.
A payment processor may have a lower transaction rate while requiring separate tax software, registrations, filings, accounting work, dispute operations, fraud configuration, and engineering maintenance.
An MoR may charge a higher blended fee but replace several of those costs.
A more useful calculation is:
Payment model total cost =
transaction fees
+ fixed payment fees
+ currency conversion
+ payout costs
+ dispute and refund costs
+ tax software
+ registrations and filings
+ accounting and legal support
+ engineering maintenance
+ billing support labor
+ expected failure and compliance cost
+ future migration cost
The MoR premium can then be evaluated as:
MoR premium =
total MoR cost
- equivalent payment-processor cost
Choose the MoR when:
MoR premium
< avoided compliance cost
+ avoided operational work
+ reduced risk
+ value of launching sooner
This formula is intentionally broader than payment fees.
A solo founder’s time has a cost. So does delaying a launch for several weeks while building tax, billing, and reconciliation workflows.
At the same time, a percentage-based MoR fee can become expensive as revenue grows. A business processing substantial volume may be able to build an internal operation for less than the recurring MoR premium.
The cheapest provider is not necessarily the provider with the lowest percentage. It is the provider with the lowest total cost after operations, compliance, failures, and migration risk are included.
Comparing the Main SaaS Payment Models in 2026
The market is no longer limited to choosing between Stripe Payments and a traditional merchant of record.
SaaS teams can now choose a processor, a processor combined with tax automation, a full MoR, or a hybrid model that applies merchant-of-record coverage only to selected transactions.
| Option | Model | Strongest fit | Important limitation to evaluate |
|---|---|---|---|
| Stripe Payments and Stripe Tax | Processor plus tax automation | Businesses that want checkout control, broad APIs, direct billing ownership, and configurable tax workflows | Your company normally remains responsible for registrations, filings, remittance, and compliance decisions |
| Stripe Managed Payments | Merchant of record | Eligible digital-product businesses that want an MoR while remaining in the Stripe ecosystem | Public-preview status, eligibility requirements, supported products, and regional availability |
| Paddle | Merchant of record | SaaS businesses needing subscriptions, one-time payments, usage-based billing, tax coverage, and customer self-service | Checkout, contracting, pricing-model, migration, and payout requirements should be tested against your use case |
| Lemon Squeezy | Merchant of record | SaaS and digital products seeking a relatively simple checkout, subscriptions, tax handling, and digital delivery | Store approval, product eligibility, surcharges, subscription requirements, and operational tooling |
| Polar | Merchant of record | Developer-oriented software, digital products, communities, and open-source businesses | Confirm that billing, invoicing, enterprise, and subscription workflows match your product |
| Dodo Payments | Merchant of record | Digital, AI, and SaaS products needing subscriptions, one-time purchases, or usage-based billing | Validate supported entities, payout methods, markets, product policies, and required billing behavior |
Paddle’s current SaaS documentation describes support for recurring plans, one-time charges, per-seat pricing, add-ons, plan changes, and usage-based charges. Lemon Squeezy documents its MoR role for digital products, while Polar and Dodo describe international tax handling through their merchant-of-record structures.
The table should be treated as a model comparison, not a final provider ranking.
Pricing, eligibility, country support, payout coverage, accepted products, billing features, and tax responsibilities can change. The final decision should be based on a documented test of your actual product and customer flow.
When a Merchant of Record Is Usually the Better Choice
An MoR is often attractive when the business is small, global, and selling standardized digital access.
Consider the MoR model when your team does not want to build tax operations before validating demand, when cross-border B2C sales are expected from launch, or when handling registrations and filings would distract the company from developing the product.
The model can also work well for a lifetime software license or one-time digital purchase. The tax treatment of a one-time purchase can still vary by customer location, so removing recurring subscriptions does not remove transaction-tax complexity.
The strongest MoR use cases usually share these characteristics:
| Business characteristic | Why an MoR may help |
|---|---|
| Small team | Avoids building a separate tax and payment-operations function |
| Global self-serve checkout | Reduces cross-border transaction complexity |
| Primarily digital products | Fits the eligibility model of many SaaS-focused MoRs |
| Standardized pricing | Works well with provider-hosted product and price catalogs |
| Limited finance operations | Moves transaction-level tax and dispute work to the provider |
| Fast validation is important | Reduces the systems required before accepting international sales |
| Predictable product fulfillment | Makes it easier for the MoR to act as reseller |
The MoR model is not only for early-stage businesses. Larger software companies also use merchants of record for selected markets, product lines, or transaction types.
The question is whether the responsibilities being transferred are worth the cost and loss of control.
When a Payment Processor Is Usually the Better Choice
A processor can become more attractive as the product, company, and billing requirements mature.
A direct processor relationship gives the business greater control over checkout behavior, payment data, invoices, contracts, customer communication, pricing experimentation, and provider combinations.
That control matters when the payment flow is part of the product rather than a separate purchase step.
A processor may be the stronger choice when:
- The business has finance, tax, accounting, and payment-operations support.
- The billing model requires highly customized usage, credits, marketplace flows, negotiated contracts, or complex invoicing.
- Direct ownership of the customer’s billing relationship is more important than transferring compliance operations.
For some B2B products, customers expect the SaaS company itself to appear as the contracted vendor and invoice issuer. Procurement teams may require custom terms, purchase orders, tax documentation, security reviews, manual invoicing, or bank-transfer workflows.
An MoR may still support some of these needs, but the arrangement should be tested before the payment model becomes part of the company’s sales process.
Scenario-Based SaaS Payment Recommendations
The business model is a more useful decision input than company size alone.
| SaaS scenario | Starting direction | Why |
|---|---|---|
| Solo founder launching globally | Merchant of record | Minimizes the compliance and payment-operations surface before product validation |
| Self-serve B2C SaaS | Merchant of record | International consumer tax and invoice requirements can become complex quickly |
| One-time lifetime software access | Merchant of record or processor plus tax | Both models can work; compare tax coverage, refunds, statement descriptors, payout timing, and margin |
| B2B SaaS with standardized card checkout | Either model | Depends on geography, tax resources, invoice expectations, and volume |
| Enterprise SaaS with negotiated contracts | Payment processor or direct invoicing | Provides more control over contracts, invoices, payment terms, and procurement |
| Usage-based AI product | Provider-specific evaluation | Verify meters, credits, prepaid balances, overages, invoice timing, retries, and webhook semantics |
| Developer tool with simple subscriptions | Merchant of record | Can reduce billing infrastructure and tax work |
| Marketplace or platform paying third parties | Specialized processor/platform model | Marketplace fund flows usually require capabilities beyond a standard SaaS MoR |
| High-volume SaaS with an internal finance team | Payment processor plus tax infrastructure | Lower marginal processing cost may outweigh the operational simplicity of an MoR |
| SaaS entering selected new markets | Hybrid or transaction-level MoR | Useful when the business wants direct processing in core markets and MoR coverage elsewhere |
There is no reliable rule that every startup should begin with an MoR and migrate to a processor later.
Migration itself can be costly. A business expecting rapid growth, enterprise sales, or unusual billing requirements may be better served by building the direct model correctly from the beginning.
Do Not Let the Provider Become Your Entitlement System
Whichever payment model you choose, the provider should not become the only system that knows what a customer is allowed to use.
A payment provider tells you what happened financially.
Your application must decide what that event means for product access.
A completed checkout might create a subscription, grant a lifetime license, add prepaid credits, start a trial, restore a previously suspended account, or wait for a risk review.
That decision belongs in your application’s billing and entitlement domain.
A resilient system stores its own records for customers, purchases, subscriptions, invoices, refunds, provider events, product mappings, and entitlements. Provider identifiers are references to external systems rather than the primary identity of the product relationship.
This separation is covered in more depth in Shipflash’s guide to SaaS billing architecture, entitlements, webhooks, and reconciliation.
A simplified provider-neutral event model could look like this:
type BillingProvider =
| "stripe"
| "paddle"
| "lemon_squeezy"
| "polar"
| "dodo";
type CanonicalBillingEvent = {
provider: BillingProvider;
providerEventId: string;
eventType:
| "purchase.completed"
| "subscription.activated"
| "subscription.changed"
| "subscription.ended"
| "payment.failed"
| "refund.completed"
| "dispute.opened";
customerReference: string;
productReference: string | null;
effectiveAt: string;
rawPayloadReference: string;
};
async function applyBillingEvent(event: CanonicalBillingEvent) {
const inserted = await recordEventOnce({
provider: event.provider,
providerEventId: event.providerEventId,
});
if (!inserted) {
return;
}
await updateLocalBillingState(event);
await recalculateEntitlements(event.customerReference);
}
The important idea is not the exact TypeScript shape.
It is that the webhook is verified, stored idempotently, normalized, and then applied to local billing state. Product access is calculated from your application’s rules rather than from a redirect URL or an unverified provider payload.
A production billing system should also reconcile local records against provider data. Webhooks can be delayed, duplicated, delivered out of order, or missed during an outage.
This is one reason a payment integration should be designed as a system rather than a checkout button.
Build Provider Portability Before You Need It
Changing payment providers is rarely a simple API replacement.
The provider may contain product prices, tax settings, customer payment methods, subscriptions, invoices, coupons, trials, disputes, refund history, and checkout links referenced throughout your application.
Migration becomes harder when provider-specific identifiers are spread across UI components, authorization rules, emails, analytics queries, and product-access checks.
A portable architecture keeps the dependency behind a small number of boundaries.
| Portability boundary | Recommended approach |
|---|---|
| Products and prices | Maintain internal catalog keys and map them to provider-specific IDs |
| Customer identity | Use your application user or account ID as the primary identity |
| Entitlements | Store product access in your database |
| Webhooks | Normalize signed provider events into canonical internal events |
| Event history | Retain the provider name, event ID, processing state, and raw payload reference |
| Reconciliation | Compare provider state with local projections on a schedule |
| Checkout | Create sessions through a provider adapter |
| Customer portal | Generate portal links through the active provider adapter |
| Analytics | Report from normalized internal billing records |
| Configuration | Keep provider choice and catalog mappings outside feature code |
This architecture does not make migration painless.
It reduces the number of places that must change.
A provider switch may still require subscription migration, customer communication, payment-method reauthorization, invoice continuity planning, tax cutover procedures, and reconciliation between the old and new systems.
That migration cost belongs in the original provider decision.
Questions to Ask Every Payment Provider
A provider demo should not end after a successful test checkout.
Evaluate the entire customer and operator lifecycle.
What exactly is the provider responsible for?
Ask for a clear explanation of who is the legal seller, who registers for tax, who files returns, who remits tax, who handles disputes, and which responsibilities remain with your company.
Do not assume that “tax included” means the provider becomes your merchant of record.
Which products and businesses are eligible?
Providers may restrict physical goods, services, marketplaces, financial products, user-generated content, high-risk categories, or products they cannot directly fulfil.
Account approval should be completed before the launch depends on the provider.
Lemon Squeezy, for example, documents an activation process involving KYC and KYB review because it assumes merchant-of-record responsibilities. Dodo Payments also publishes a merchant-acceptance policy for the products it is willing to resell.
Where can the provider accept customers and pay your business?
Customer coverage and merchant payout coverage are different.
A provider may accept payments from customers in many countries while supporting payouts, legal entities, bank accounts, or currencies in a smaller set.
Verify both sides of the transaction.
Which billing models are supported natively?
A provider that supports subscriptions may not support your specific subscription model.
Test trials, seat quantities, upgrades, downgrades, prorations, pauses, usage reporting, credit balances, annual commitments, add-ons, coupons, one-time charges, refunds, and grace periods.
Do not assume these behaviors are interchangeable between providers.
Who owns the customer’s payment relationship?
Understand what data can be exported, whether subscriptions can be migrated, whether payment credentials can be transferred through an approved process, and what happens if the provider closes the account or changes a supported feature.
What does the customer see?
Inspect the checkout domain, receipt, invoice, tax information, statement descriptor, refund communication, and support contact.
Lemon Squeezy’s documentation, for example, explains that its name appears in the payment descriptor because it acts as merchant of record.
How are failed payments and disputes represented?
Your application needs reliable webhook events for failed charges, subscription changes, refunds, chargebacks, fraud reviews, and payment recovery.
Check whether events can arrive more than once, how signatures are verified, how long retries continue, and whether historical events can be replayed.
What happens during an outage?
Ask whether checkout fails closed, whether subscriptions continue renewing, whether webhook events are queued, how reconciliation works, and how incidents are communicated.
A provider that saves tax work but gives you no operational visibility can still create a fragile customer experience.
Common Payment-Model Mistakes
Choosing from the checkout design alone
A polished checkout does not prove that the provider supports your refund policies, billing changes, customer portal, tax needs, payout schedule, reconciliation process, or enterprise sales workflow.
The payment model should be evaluated from first purchase through cancellation, refund, dispute, and financial reporting.
Comparing only headline fees
A processor can look cheaper until registration, tax software, filings, accounting, engineering, and support are included.
An MoR can look simpler until percentage fees, payout timing, checkout constraints, and migration risk are included.
Calculate both as operating systems, not APIs.
Treating the checkout redirect as payment confirmation
A customer can reach a success page while the payment is pending, later reversed, or associated with a different account.
Provision access from verified server-side events and reconcile the result.
Storing provider status as product authorization
A provider subscription status is not always the same as an entitlement.
Your product may support grace periods, lifetime purchases, manual access, account suspension, credits, refunds, or grandfathered plans.
Keep product access in your own domain.
Assuming global coverage means every transaction is supported
Country coverage, currency support, payout eligibility, product acceptance, sanctions, card-network rules, and local payment methods are separate constraints.
Verify the exact selling entity, customer location, product category, currency, and payment method combination you expect to use.
Postponing migration planning
The worst time to design portability is after thousands of active subscriptions depend on provider-specific state.
You do not need to build two complete integrations. You should avoid coupling the entire product to one provider’s object model.
A Payment-Provider Evaluation Worksheet
Score each provider from one to five for the criteria below, then assign a weight based on your product.
| Evaluation area | Questions to answer | Suggested weight |
|---|---|---|
| Legal and tax model | Who is the seller? Who registers, files, remits, and carries liability? | 15% |
| Product eligibility | Is the exact SaaS product permitted and approved? | 10% |
| Customer coverage | Can customers pay in your target markets and currencies? | 10% |
| Merchant payouts | Can your entity receive payouts reliably and affordably? | 10% |
| Billing models | Are subscriptions, seats, usage, credits, trials, and one-time charges supported? | 15% |
| Checkout experience | Does checkout match the brand, localization, conversion, and authentication flow? | 5% |
| API and webhooks | Are events secure, complete, idempotent, replayable, and documented? | 10% |
| Operations | Are refunds, disputes, reconciliation, exports, and support workflows usable? | 10% |
| Total cost | What is the complete cost at current and projected revenue? | 10% |
| Portability | Can data and subscriptions be moved if requirements change? | 5% |
The weighting should reflect your business.
A globally distributed B2C product may assign more weight to the legal and tax model. An enterprise SaaS may assign more weight to contracts, invoicing, and payment terms. An AI product may prioritize metered usage, credits, and real-time spend controls.
How Shipflash Approaches Billing Foundations
The payment provider is only one layer of a production SaaS.
The application still needs verified webhooks, idempotent event processing, local billing records, entitlement rules, refunds, customer operations, logs, reconciliation, and secure administration.
Shipflash is designed to provide a structured foundation for these recurring SaaS concerns, so billing logic has a clear place to live rather than spreading across checkout pages, route handlers, UI components, and authorization checks.
The broader architecture is explained in How to Build a Production-Ready SaaS Foundation.
Once customers exist, the operational side matters as much as the integration. Support teams need to trace purchases, inspect billing history, understand failed events, perform controlled actions, and leave an audit trail. The SaaS Admin Operations Playbook covers how to build that internal surface without relying on direct database edits.
A foundation does not choose the commercial model for you.
It makes that choice easier to implement, operate, and change.
Final Recommendation
Choose a merchant of record when transferring transaction-level tax and payment operations creates more value than the additional fees and reduced control cost you.
Choose a payment processor when direct ownership, flexibility, custom billing, enterprise requirements, and lower marginal cost are worth building and maintaining the surrounding compliance operation.
For many small global SaaS teams, an MoR offers the clearest route to accepting international payments without creating an entire tax function before the product has traction.
For a mature SaaS with specialized billing and finance resources, direct processing may provide better economics and control.
The most important decision is not the provider logo.
It is whether your billing architecture remains reliable when a payment fails, a refund arrives, a tax rule changes, a webhook is duplicated, a customer disputes a charge, or the business needs to move to another provider.
That is the difference between adding payments and building a payment system.
Frequently Asked Questions
Is Stripe a merchant of record?
Standard Stripe Payments does not generally make Stripe your merchant of record. Your business remains the seller.
Stripe now also offers Managed Payments, where Stripe acts as merchant of record for eligible digital-product transactions. Stripe currently documents Managed Payments as a public-preview product, so businesses should verify availability and eligibility.
Does a merchant of record handle all taxes?
An MoR generally handles applicable indirect transaction taxes—such as sales tax, VAT, or GST—for transactions covered by its service.
It does not normally replace your company’s income-tax, corporate-tax, payroll, accounting, or local business obligations. Consult an appropriate tax or legal professional for advice specific to your entity and markets.
Is a merchant of record cheaper than Stripe?
Not necessarily.
A merchant of record commonly has a higher transaction fee than basic payment processing, but the comparison changes after tax software, registrations, filings, fraud operations, disputes, support, accounting, and engineering work are included.
Compare total operating cost rather than the headline rate.
Is a merchant of record better for global SaaS?
It is often easier for a small global SaaS because the provider assumes more responsibility for indirect tax and transaction operations.
It may not be better when the company needs custom enterprise contracts, highly specialized billing, direct invoices, marketplace fund flows, maximum checkout control, or lower marginal costs at scale.
Can a SaaS switch from an MoR to a payment processor later?
Yes, but the migration can be complex.
Products, prices, customers, subscriptions, invoices, payment methods, tax records, refunds, webhooks, and entitlements may need to be migrated or reconciled. Some customers may need to provide payment details again.
Provider-neutral local billing records reduce the application changes required.
Can a SaaS use both models?
Yes.
A company might use a direct processor in its primary markets and an MoR for specific countries, products, or transaction types. Stripe Managed Payments also documents a transaction-level approach that can coexist with other Stripe products.
A hybrid strategy creates additional reconciliation and customer-support complexity, so each transaction should clearly record its provider and legal seller.
Does an MoR own the SaaS customer?
The SaaS company continues to provide the product and manage the product relationship, but the MoR becomes the customer-facing seller for covered transactions.
The practical level of control over payment credentials, subscription records, invoices, exports, and migration varies by provider and contract. Review these terms before treating any provider as a permanent billing foundation.
Should a new SaaS start with a merchant of record?
A new SaaS should consider an MoR when international self-serve sales are expected and the team does not have the resources to manage tax registrations, filings, disputes, and payment operations.
A processor may be better from the beginning when the business already knows it needs enterprise invoicing, custom contracts, a marketplace model, complex usage billing, or direct control of the payment relationship.
This article provides general product and technical information, not legal, accounting, or tax advice. Provider features, pricing, eligibility, and geographic availability can change. Verify current official documentation and seek qualified professional advice where appropriate.