# Selling software from outside the US, and why a merchant of record solves the payout problem

> If your company is registered in India, Nigeria, Brazil or most of the world, the hard part is not accepting cards. It is getting paid, and staying compliant in a hundred countries you never visit.

The standard advice for taking payments online assumes a US or EU company. Sign
up, connect a bank account, start charging cards. If that describes you, most of
this article is not for you.

For everyone else, the sequence usually goes: sign up, get asked for a US
entity, look at Stripe Atlas or a Delaware C-corp, discover it costs money and
an annual filing, wonder whether there is another way.

There is, and it is what a merchant of record actually solves.

## The three problems, in order of how much they hurt

**1. Onboarding.** Card processors are regulated per country and support the
markets they are licensed in. A company registered in India, Nigeria, Vietnam or
Argentina frequently cannot open an account at all, or can only open one that
settles domestically, which is no use when your customers pay in dollars. Founders
routinely spend more time and money incorporating abroad to be accepted than
they spend building the first version of the product.

**2. Payouts.** Suppose you clear that. You now have money in a US account and a
company that is not in the US. Getting it home means an international transfer,
an intermediary bank fee, an FX spread that is rarely the mid-market rate, and
(in countries with capital controls) paperwork per remittance. In India that
means the FIRC/FIRA trail your bank wants for every inward remittance of export
revenue.

**3. Tax, in every country you sell to.** This one is jurisdiction-independent
and catches everyone. Digital services have no registration threshold in most of
the world: sell one subscription to a consumer in Germany and 19% VAT is due
there, from the first euro. The EU, the UK, Norway, Switzerland, Australia, New
Zealand, Japan, South Korea, Canada, Turkey and about twenty US states each have
their own regime, rate and filing cadence. Doing this properly is not difficult,
it is a permanent part-time job.

## What Dodo actually changes

Dodo Payments is the **merchant of record**. It buys the product from you and
sells it to your customer. The contract, the invoice and the tax registrations
are Dodo's.

- **Onboarding** is against Dodo's licences, not yours. A company in a country
  no US processor will touch can still sell worldwide, because the entity
  facing the card networks is Dodo.
- **Payouts** arrive from one counterparty on a schedule, in a currency you
  chose, into a supported country. India is included, which is the practical
  reason a lot of teams end up here. One inward remittance a cycle from a named
  business is also far easier to document than a stream of card settlements.
- **Tax** is collected and remitted by Dodo under its own registrations. You do
  not register for VAT OSS. You do not file quarterly returns in a country you
  have never been to. You do not keep ten years of location evidence per
  customer.

The trade is the rate: 4% + 40c against roughly 2.9% + 30c for a raw processor.
On $5,000 a month that gap is about $60: considerably less than one hour of an
international tax accountant, let alone the incorporation you were considering.

## What it does not change

**You still owe tax at home.** Dodo handles *sales* tax and VAT on the
transaction. The revenue Dodo pays you is your company's income and your own
jurisdiction taxes it normally. A merchant of record removes the multi-country
indirect tax problem, not your corporate return.

**You still need the export paperwork.** If your country requires documentation
for inward remittances, you still produce it. You are just producing it for one
payer instead of thousands of card settlements, which is the easier version of
the same task.

**Your brand is not on the statement.** The customer's card line and invoice say
Dodo. Most consumers do not care; occasional B2B buyers ask, and enterprise
procurement sometimes wants your entity on the contract. If that is your market,
a merchant of record is the wrong tool.

**Webhooks are still your problem.** Nothing about merchant of record changes
the fact that subscription state arrives asynchronously, at least once, out of
order. See the idempotency and lifecycle docs in this cookbook.

## What it costs you later

The percentage does not scale away. At $5,000/month the merchant of record is
obviously cheaper than the alternative. At $200,000/month, the same 1.1% gap is
roughly $2,200 a month, which buys a lot of accountant, and the calculation
flips.

That is fine. Treat it as a service you rent while compliance is the expensive
problem, and plan to reconsider at a revenue level you would be delighted to
reach. This repo keeps everything provider-specific behind `src/lib/billing`
precisely so that the reconsidering is a module swap and not a rewrite. Plans
live in `src/lib/pricing.ts`, not at the provider, and only
`src/lib/billing/provider.ts` and its `dodo-*` files know Dodo exists.

## The practical setup checklist

1. Register the company you actually have. No foreign incorporation required.
2. Complete Dodo's business verification early. There is a human review, and it
   is the step that gates going live.
3. Add the payout account and check the settlement currency and cadence before
   you promise anyone a launch date. Payout timing, not charge timing, is what
   your runway model needs.
4. Set the **tax category** on every product. Dodo remits based on it, and it is
   the one catalogue field with a compliance consequence.
5. Price in one currency to start. Multi-currency pricing is a product decision
   with FX consequences; do it deliberately, not by accident.
6. Tell customers the statement descriptor will read Dodo. It costs one line in
   the receipt email and saves a stream of fraud reports.

---

Agentic Boilerplate: A Next.js repo your agent already knows. Free during launch, then $99 once.

- Site map for agents: https://agenticboilerplate.com/llms.txt
- Public API: https://agenticboilerplate.com/openapi.json
- Contact: agenticstudio@gmail.com