MERCHANT OF RECORD
Merchant of Record Requirements: SaaS Approval Checklist for 2026
Anyway Team
· 9 min read ·
Merchant of Record requirements usually cover six areas: seller identity, a real product website, clear commercial terms, accurate product details, a secure payment path, and payout setup for the verified applicant. Prepare application materials early, then complete payout setup when the provider requests it. A consistent website and verification record make review easier.
Merchant of Record requirements at a glance
Area: Applicant identity; What to prepare: Business or individual legal details, tax residency, and requested identity documents; Why it matters: The provider must know who receives the commercial relationship and payout
Area: Product website; What to prepare: HTTPS site, product description, visible pricing, and support contact; Why it matters: Reviewers need to see a real product and a customer path
Area: Commercial terms; What to prepare: Refund, cancellation, renewal, and acceptable-use information; Why it matters: Buyers need clear expectations before payment
Area: Payment setup; What to prepare: Product IDs, prices, currencies, billing intervals, and checkout URLs; Why it matters: The payment record must match the offer shown to customers
Area: Technical setup; What to prepare: Secure backend, webhook endpoint, and entitlement logic; Why it matters: Your service must react to payment state accurately
Area: Finance and payouts; What to prepare: Verified payout details and records for reconciliation; Why it matters: Funds can be sent to the intended account and reported correctly
Requirements vary by provider, product, market, and account type. This is a preparation checklist, not legal or tax advice.
1. Prepare the applicant identity
Start with the legal identity that will apply for the account. Anyway's public business verification documentation describes both Business and Individual paths. An individual application can require the legal name, tax residency, personal tax or registration number, and identity documents such as a passport. A business application can require entity information and supporting documents.
Use the exact spelling and address that appear in your official records. Do not use a brand name as the legal applicant unless the form explicitly asks for a trading name. Keep the person who can answer verification questions available during review.
What can go wrong: A website may show one founder name, the application may use another spelling, and the payout account may use a third name. That mismatch creates a clarification loop. Create a one-page source of truth before you submit.
Read the Anyway business verification documentation for the current document list and account fields.
2. Publish a real HTTPS product website
An MoR reviewer needs to understand what a buyer is paying for. Your site does not need a large marketing campaign, but it should be reachable, secure, and specific. Include:
Product name and a plain-language description.
A working demo, screenshots, or a clear explanation of the service.
The customer type and the main use case.
A visible pricing page or a clear route to pricing.
A support email or help center link.
Terms, privacy information, and refund or cancellation instructions.
The website and the payment product should describe the same thing. If your checkout says "Team plan" while the site only describes an individual tool, reviewers and buyers may have questions.
What can go wrong: A placeholder page, a broken sign-in button, or pricing hidden behind an unavailable demo makes a legitimate product look unfinished. Test the site in a private browser window before you apply.
3. Describe the product and customer journey
Write down the journey from first visit to paid access:
The visitor sees the product and price.
The buyer opens checkout.
The payment is confirmed.
The product is delivered or enabled.
The buyer can find support, invoices, cancellation, and refunds.
For SaaS, explain whether access is by account, workspace, seat, usage allowance, or a combination. For digital downloads, explain what is delivered and how updates work. For an AI or developer tool, state what a customer receives without making claims that depend on a future roadmap.
What can go wrong: A review form may ask for a product URL, but the URL opens a generic homepage with no pricing or purchase route. Link directly to a page that a reviewer can understand in one visit.
4. Make pricing and billing rules explicit
Every product should have a stable internal price definition. Record:
Product ID and product name.
One-time or recurring billing type.
Billing interval, if recurring.
Currency and displayed amount.
Trial duration and conversion rule, if offered.
Upgrade, downgrade, cancellation, and refund behavior.
Any usage or seat limit that affects the buyer's bill.
Anyway's public product page lists one-time payments and recurring subscriptions with weekly, monthly, and annual intervals. If your plan needs a different billing design, confirm the current product capabilities before you advertise it.
Use the Merchant of Record pricing comparison to document the fee model separately from your customer price. Do not describe the provider fee as a tax, and do not describe a tax amount as your revenue.
What can go wrong: A pricing page says "$20 per month" while the checkout uses an annual amount or a different currency. Compare the public page, product configuration, and receipt in a test order.
5. Prepare tax and invoice information
An MoR can handle the covered transaction's indirect tax workflow, but the product owner still needs accurate product, buyer, and seller information. Make sure your checkout can collect the billing country and any required address details. Keep your own records of orders, invoices, refunds, and payouts.
Anyway's public site says it calculates, collects, and files applicable indirect tax for covered transactions and issues compliant invoices. The invoice identifies the Merchant of Record. Your product page should link to the correct terms and support route so a buyer knows who to contact about a payment.
For background, read what a Merchant of Record is and how an MoR differs from a payment processor.
What can go wrong: A team copies a tax percentage into marketing copy and treats it as universal. Tax treatment can depend on buyer location, product classification, and transaction details. Keep public language general and rely on the checkout and invoice for the transaction calculation.
6. Merchant of Record requirements for the technical payment path
You can prepare the technical side before the account is approved. Use a test product and implement these components:
A hosted checkout link or API-created payment session.
A backend HTTPS webhook endpoint.
Request authenticity checks according to the provider's current documentation.
An event store keyed by event ID.
An entitlement service that can grant, pause, and end access.
A reconciliation job that compares payment events with your own orders.
Anyway's webhook documentation lists payment.succeeded, payment.failed, payment.pending, and payment.cancelled. It recommends an accessible HTTPS endpoint, a quick 2xx response, and duplicate-event handling. Use eventId and orderId as stable references in your database.
What can go wrong: A developer puts the webhook URL behind authentication intended for browser users, so the provider receives a 401. Give the endpoint a narrow machine-to-machine path, validate the request, and keep the response fast.
7. Verify finance and payout details
Payout setup is part of the launch requirements, even when it is completed after business verification. The payout beneficiary should match the approved applicant or entity. Check the account name, bank country, currency, and any minimum payout threshold in the provider's current documentation.
Anyway publishes supported payout account types and a minimum payout threshold in its finance and payouts documentation. Availability can depend on the account and verification result. Use the official page as the source of truth rather than promising a particular local method to every applicant.
Create a reconciliation sheet with:
Gross order amount.
Tax amount shown on the invoice.
Provider fee.
Refund or adjustment.
Net payout amount.
Payout date and reference.
What can go wrong: A team forecasts cash flow from gross sales while the payout arrives later and net of fees or tax. Model the complete path before committing to payroll, vendor, or advertising spend.
8. Complete a product and policy preflight
Before submitting, review your product against the provider's current acceptable-use and restricted-product rules. Keep the review factual and avoid launching a category that you cannot explain clearly. Your public pages should not contain contradictory claims about the product, customer, or delivery method.
Check these pages manually:
Homepage and pricing page load without a login.
Checkout link opens from a clean browser.
Support email receives a test message.
Refund and cancellation instructions are visible.
Privacy and terms links work.
The product name is consistent across site, account, and checkout.
Screenshots show the current product.
What can go wrong: A reviewer clicks a support email that points to an abandoned inbox. Use a monitored address and respond during the review window.
9. Keep a review packet
A small review packet makes future updates faster. Store:
Legal applicant details and document expiry dates.
Product URLs and screenshots.
Pricing and billing definitions.
Support and refund policy links.
Payout account confirmation.
A diagram of checkout, webhook, and entitlement flow.
Do not put identity documents or payment secrets in a public repository. Use the provider's secure upload flow and restrict internal access to the packet.
FAQ
Can an individual apply for an MoR account?
Not every provider uses the same applicant paths. Anyway documents both Business and Individual verification options. The required identity, tax residency, product, and payout information still needs to be accurate and complete.
What should be on my SaaS website before applying?
Publish a working HTTPS site with a product explanation, visible pricing, support contact, terms, privacy information, and refund or cancellation instructions. A reviewer should be able to understand what the buyer receives and how to reach you.
Does an MoR handle all of my tax obligations?
An MoR handles the covered transaction responsibilities described in its agreement. Your own business may still have separate reporting, income-tax, accounting, or regulatory duties. Use the provider's invoice and tax documentation, and ask a qualified adviser about obligations outside the transaction flow.
How long does MoR approval take?
Timing depends on the provider, product, documents, and any follow-up questions. A complete public website and consistent application usually gives the reviewer the information needed to assess the account without repeated clarification.
Can I apply before my SaaS is fully launched?
You can prepare the application early, but the provider may need a working product page, pricing, support route, and accurate description of the service. Do not submit placeholder claims that you cannot fulfill for a buyer.
Final checklist
You are ready to submit when you can answer yes to each question:
Is the legal applicant clear and consistent across documents?
Does the product website use HTTPS and show what customers receive?
Are price, interval, currency, refund, and cancellation rules visible?
Can a buyer reach support without searching for a hidden email?
Is the checkout product identical to the website offer?
Does the webhook update entitlements from verified events?
Does the payout account match the verified applicant?
Have you checked the current product and acceptable-use requirements?
Start an Anyway account or review the developer documentation after your public launch checklist is complete.