Transparent checkout and merchant of record: 5 calls

For a Brazilian supplier that sells software abroad, embedding a transparent checkout in the coding agent is the cheapest distribution decision and the most expensive one to reverse when nobody has defined, before the first production call, who the merchant of record is.

The billing account lives in a separate dashboard. The price table is written twice, once in the dashboard and once in the code. The test key landed in a configuration file on a Friday and stayed there through Monday. The first customer pays in euros. Finance finds out about the wrong currency afterwards.

Those same operations are now tool calls inside the assistant where this team spends its day. Under LC 116/2003, what decides whether a service is an export is not the currency that comes in, but where the result is verified. When the checkout becomes a tool, the sales channel becomes the customer's development environment.

What changes when the checkout becomes a tool of the agent

MCP servers expose tools that the agent executes. A billing MCP server turns creating a product, setting a price, opening a checkout session and subscribing to a plan into tool calls. The question stops being which gateway to integrate and becomes who answers for the transaction that is born there.

The host instantiates one client per connected server; each server declares tools, resources and prompts. A tool is an executable function that the artificial intelligence application invokes. The specification uses an API call as the example.

A skill is a folder with SKILL.md: instruction and procedure, loaded by progressive disclosure. A skill executes nothing. It says how to charge. The server runs the charge. Swapping one for the other produces an eloquent agent that describes the checkout and never opens the session.

The customer's development environment becomes the point of sale, and the layer that controls tool traffic is where that power becomes visible, as the MCP gateway covers. Whoever installs the server operates the account.

Gateway, PSP and merchant of record: three roles, three accountable parties

The gateway transports and authorizes the payment. The PSP settles with the merchant. The merchant of record sells to the end customer: it issues the document, collects consumption tax in the destination market and answers for refunds. Three roles with three accountable parties, and the agent does not create a fourth.

The gateway neither sells nor takes on the relationship with the consumer. The PSP settles with the merchant that contracted the account, not with whoever appears on the screen.

The account that opens the session is the one the buyer and the card issuer see, and it is through that account that anyone answers who sells, not through the name of the server that made the call.

A better gateway does not change the seller: the relationship with the end consumer still belongs to whoever sells. The distinction that no contract resolves: merchant of record is a commercial role, and in Brazil the signed label neither creates nor transfers a tax obligation; the obligation follows the law. Brazilian law already assigns responsibility to digital platforms, on the operations carried out through them, in defined cases, by the test of who controls the charge, the payment, the definition of terms or the delivery (LC 214/2025, art. 22, caput and § 1º, II), including when the platform is domiciled abroad, and it allows the platform to elect to issue the document in place of the supplier with the supplier's consent (§§ 12 and 13). The European deemed supplier is the same movement in another jurisdiction, not the only case.

The decision question is concrete: who signs the document the customer receives. The guide on what merchant of record means separates that role from the other two; what matters here is what it changes when the sale is born from a call.

Why the decision moves when the agent configures the price

When price, currency, coupon and plan are configured by a tool call, the tax consequence is born in the repository and not in the pricing meeting. Whoever holds the production key decides what is charged. The decision leaves finance and enters the development environment.

The price table is now versioned alongside the code, in the same repository and in the same history. It is practical and it is a trap: the review checkpoint was designed for a function, not for a price. Someone reads the diff of the discount rule, nobody reads the diff of the euro amount.

The production key appears in a configuration file of the assistant, next to the test key, separated by a comment line. Nobody recorded who used it. In the arrangement described, nobody defined a limit on product creation.

The failure mode has a date and a name. The company discovers the wrong currency or the wrong coupon after the first paying customer, and the fix stops being a commit and becomes a refund in a foreign market.

Nobody signs that price configuration.

Who issues the document and who collects the tax at destination

A service export depends on where the result is verified, not on who pays. If the result stays in Brazil, the operation is not an export and ISS applies under the current wording of LC 116/2003. With a foreign merchant of record, the supplier invoices that party and the document to the consumer is issued at destination.

Article 2º, I, of LC 116/2003 keeps ISS out of service exports; the sole paragraph closes the door, and not even a payment coming from abroad changes the classification when the result is verified here.

The tax remains in force with a phased reduction of rates from 2029 to 2032 (art. 8º-B of LC 116/2003) and leaves the scene at the end of the transition.

During the transition, the same supply is also tested by IBS and CBS: LC 214/2025 treats the supply to a party resident or domiciled abroad, with consumption abroad, as an export of a service or of an intangible asset (art. 80). Two tests, and they do not coincide in every operation.

Export revenue is settled through an exchange contract, and Decree 6.306/2007 addresses the inflow of that revenue in its own provision (art. 15-B, I), distinct from the one that reaches the remittance abroad.

In Europe the test is explicit: the EUR 10,000 threshold belongs to the one-stop-shop regime, covers distance sales of goods and the service supplied electronically, and applies to a supplier established in a single Member State. For the supplier established outside the Union it does not apply: the tax is due in the State of the consumer from the first operation. The platform that intermediates the sale may be treated as the supplier in defined cases.

In the United States the map changed in 2018: South Dakota v. Wayfair reversed the physical presence requirement and allowed states to require remote sellers to collect and remit, with state thresholds.

Two routes, two documents. The consumer's document does not come from the same place, and whoever issues it answers for the tax at destination. The comparison between merchant of record and an own entity organizes the rest.

Five decisions before embedding billing in the agent

Five definitions have to exist before the first production call: who the seller of record is, who issues the document per market, who absorbs refunds and chargebacks, who holds the production key and who classifies the revenue on the way out of Brazil. Without the five, the configuration decides.

Seller of record is the record of who sells in the transaction and in the document. Merchant of record is the commercial role of whoever presents itself as the merchant and answers for tax, refund and chargeback. The two coincide when the company sells in its own name and separate when a marketplace or a reseller appears as the seller.

1. Merchant of record. Defining who appears on the invoice and whom the consumer complains to prevents the role from being decided by the screen someone built last.
2. Tax document per market. Defining the registration that supports each document, CNPJ here and a consumption or B2B sale registration there, avoids discovering a market without registration on the first sale.
3. Refund, chargeback and default. Defining the deadline and the cap for whoever absorbs the loss prevents the product team from inheriting one that is not its own.

The first three are design decisions and fit in one meeting. The next two are operational and appear on the day someone opens the editor with the key in hand. None of them is technical.

1. Production key and creation limit in the agent. Defining who can create a product, in which currency and with which limit prevents a plan from being born in a currency nobody agreed on.
2. Revenue classification on the way out of Brazil. Defining the record that supports the export position prevents finance from classifying the revenue out of last year's habit.

What a transparent checkout solves, and what it does not

A transparent checkout solves where the buyer pays, keeping the buyer on the domain of whoever sells. It does not define who the seller is for tax purposes, nor who collects tax at destination. Inside the agent, transparent gains a second meaning: the billing configuration becomes invisible to whoever develops, and so does the decision about it.

In the current sense, the term describes the payment page on the domain of whoever sells, with card data in the store's flow, and what it solves is conversion, not tax role.

Inside the agent, it describes a call that opens the billing without going through the store's page: the tool creates the session and the buyer completes the payment on the surface of the account that issued that session. What is invisible to whoever develops is the configuration, not the payment. What the local checkout changes in the conversion of a SaaS in another currency is another calculation, and that does not change who issues the document.

Both meanings share the trap: transparency for the buyer is not transparency for the tax authority.

The difference is who answers.

When each side makes sense

The company takes the role when it sells in one currency, serves few markets, wants to keep the customer and manages to register where it needs to. It contracts a third party when it sells in many countries, to end customers, and the cost of registration in each one exceeds what the margin supports. The verdict is per market. Never per company.

1. Company as merchant of record. It already has registration in the destination market, sells to a concentrated audience and keeps the relationship, the payment data, the subscription and its own tax structure.
2. Third party as merchant of record. It sells to end customers in many countries. The third party takes on the document, the tax and the refund; the company gives up margin, the commercial relationship and subscription portability.
3. Mixed model. It is merchant of record where it already has registration and outsources the rest, with two regimes and two reconciliation routines.

The criterion that separates the three is the combination of number of markets, type of buyer and willingness to keep an own tax structure in each country. For anyone who wants to sell SaaS abroad without a local operation, the second item is the most frequent and the most expensive to undo.

What to check in the contract and in the configuration

Contract and configuration have to answer the five previous decisions, under the same names: merchant of record, tax document per market, refund and chargeback, production key and revenue classification on the way out of Brazil. Checking this before the first sale costs one meeting. Afterwards, it costs a base migration.

1. Merchant of record. The clause that names the role and what it assigns to each party.
2. Tax document per market. The registration that supports each document and the named owner.
3. Refund, chargeback and default. The deadline, the cap and who pays the difference.

The next two are configuration and do not appear in the contract.

1. Production key and creation limit in the agent. Who owns the production key, what its scope is and what the creation limit is.
2. Revenue classification on the way out of Brazil. The record that supports the export position, and who signs it.

Beyond those five, three extra checks complete the day-to-day configuration, without replacing any of them.

• Rotation of the production key and the scope of product creation in the agent.
• Handling of payment data, with the subprocessors and the declared residency.
• The exit: subscription migration, card tokens and history.

Nexforce Marketplace serves the Brazilian supplier that wants to receive in reais with a domestic invoice document, does not turn Nexforce into a merchant of record at destination and does not issue a document in the customer's place. Nexforce Marketplace describes the flow.

Frequently asked questions

What changes when the checkout inside the agent becomes a tool call?

The owner of the configuration changes. With the checkout running as a tool, price, currency and plan start to be defined by whoever holds the production key, and the question about who the merchant of record is leaves finance, by omission and never by decision.

Who collects consumption tax when the agent opens the checkout?

The merchant of record collects, not the gateway. Outside Brazil, the tax follows the destination market. In Brazil, ISS is due in the municipality of the establishment that provides the service, subject to the exceptions of art. 3º of LC 116/2003. The agent does not change the role.

What changes in the tax document of a Brazilian SaaS that sells abroad?

It depends on where the result is verified. LC 116/2003 does not treat as an export the service whose result is verified in Brazil. If the software runs and produces effects here, the document follows the domestic operation, with ISS under the current wording and IBS and CBS during the transition.

Does a transparent checkout solve the tax problem of selling outside Brazil?

It does not. The term defines where the buyer pays and keeps card data in the flow of whoever sells, which is a conversion decision. Who issues the document and collects tax at destination is defined by the merchant of record role and by the law.

When is it worth contracting a third-party merchant of record?

It is worth it when the cost of registering in each market exceeds what the margin supports, which usually happens when selling to end customers in many countries. The third party takes on the document, the tax and the refund, and the company gives up margin and subscription portability.

References and Further Reading

• LC 116/2003, Planalto. Accessed 26/10/2026. https://www.planalto.gov.br/ccivil_03/leis/lcp/lcp116.htm
• LC 214/2025, Planalto. Accessed 26/10/2026. https://www.planalto.gov.br/ccivil_03/leis/lcp/lcp214.htm
• Decree 6.306/2007, IOF, Planalto. Accessed 26/10/2026. https://www.planalto.gov.br/ccivil_03/_ato2007-2010/2007/decreto/d6306.htm
• European Union VAT One Stop Shop. Accessed 26/10/2026. https://vat-one-stop-shop.ec.europa.eu/index_en
• Model Context Protocol specification. Accessed 26/10/2026. https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture
• Agent Skills specification. Accessed 26/10/2026. https://agentskills.io/specification
• South Dakota v. Wayfair, 585 U.S. (2018). Accessed 26/10/2026. https://supreme.justia.com/cases/federal/us/585/17-494/

What that decision costs later

The bill for not deciding lands on the first refunded sale in a market where the company does not issue a document, and on the day someone asks who authorized the price.

The rest is talk.