Checkout transparente y merchant of record: 5 decisiones

Para un proveedor brasileño que vende software al exterior, incrustar un checkout transparente en el asistente de código es la decisión de distribución más barata y la más cara de revertir cuando nadie definió, antes de la primera llamada en producción, quién es el merchant of record.

La cuenta de cobros vive en un panel separado. La tabla de precios está escrita dos veces, una en el panel y otra en el código. La clave de prueba quedó en un archivo de configuración un viernes y siguió ahí el lunes. El primer cliente paga en euros. Finanzas descubre la moneda equivocada después.

Esas mismas operaciones ahora son llamadas de herramienta dentro del asistente donde este equipo pasa el día. Por la LC 116/2003, lo que decide si un servicio es exportación no es la moneda que entra, sino dónde se verifica el resultado. Cuando el checkout se convierte en herramienta, el canal de venta pasa a ser el entorno de desarrollo del cliente.

Qué cambia cuando el checkout se convierte en herramienta del agente

Los servidores MCP exponen herramientas que el agente ejecuta. Un servidor MCP de cobros convierte crear producto, definir precio, abrir sesión de checkout y suscribir un plan en llamadas de herramienta. La pregunta deja de ser qué pasarela integrar y pasa a ser quién responde por la transacción que nace ahí.

El host instancia un cliente por servidor conectado; cada servidor declara herramientas, recursos y prompts. Una herramienta es una función ejecutable que la aplicación de inteligencia artificial invoca. La especificación usa la llamada de API como ejemplo.

Una skill es una carpeta con SKILL.md: instrucción y procedimiento, cargada por divulgación progresiva. Una skill no ejecuta nada. Dice cómo cobrar. El servidor ejecuta el cobro. Cambiar una por otra produce un agente elocuente que describe el checkout y nunca abre la sesión.

El entorno de desarrollo del cliente se convierte en punto de venta, y la capa que controla el tráfico de herramientas es donde ese poder se vuelve visible, como trata la pieza de MCP gateway. Quien instala el servidor opera la cuenta.

Pasarela, PSP y merchant of record: tres roles, tres responsables

La pasarela transporta y autoriza el pago. El PSP liquida con el comercio. El merchant of record vende al cliente final: emite el documento, recauda el impuesto al consumo en el mercado de destino y responde por reembolsos. Son tres roles con tres responsables, y el agente no crea un cuarto.

La pasarela no vende ni asume la relación con el consumidor. El PSP liquida con el comercio que contrató la cuenta, no con quien aparece en la pantalla.

La cuenta que abre la sesión es la que ven el comprador y el emisor de la tarjeta, y es por ella que se responde quién vende, no por el nombre del servidor que hizo la llamada.

Una pasarela mejor no cambia al vendedor: la relación con el consumidor final sigue siendo de quien vende. La distinción que ningún contrato resuelve: merchant of record es un rol comercial, y en Brasil la etiqueta firmada no crea ni transfiere obligación tributaria; la obligación sigue la ley. La ley brasileña ya atribuye responsabilidad a plataformas digitales, en las operaciones realizadas por su intermediación, en supuestos definidos, por el criterio de quién controla el cobro, el pago, la definición de los términos o la entrega (LC 214/2025, art. 22, caput y § 1º, II), incluso cuando la plataforma está domiciliada en el exterior, y permite que la plataforma opte por emitir el documento en lugar del proveedor con la anuencia del proveedor (§§ 12 y 13). El deemed supplier europeo es el mismo movimiento en otra jurisdicción, no el único caso.

La pregunta de decisión es concreta: quién firma la factura que recibe el cliente. La guía sobre qué es merchant of record separa ese rol de los otros dos; aquí interesa lo que cambia cuando la venta nace de una llamada.

Por qué la decisión cambia de lugar cuando el agente configura el precio

Cuando precio, moneda, cupón y plan se configuran por llamada de herramienta, la consecuencia fiscal nace en el repositorio y no en la reunión de pricing. Quien guarda la clave de producción decide qué se cobra. La decisión sale de finanzas y entra en el entorno de desarrollo.

La tabla de precios pasa a versionarse junto con el código, en el mismo repositorio y en el mismo historial. Es práctico y es trampa: el checkpoint de revisión se diseñó para una función, no para un precio. Alguien lee el diff de la regla de descuento, nadie lee el diff del valor en euros.

La clave de producción aparece en un archivo de configuración del asistente, junto a la clave de prueba, separada por una línea de comentario. Nadie registró quién la usó. En el arreglo descrito, nadie definió un límite de creación de producto.

El modo de falla tiene fecha y tiene nombre. La empresa descubre la moneda o el cupón equivocado después del primer cliente que paga, y la corrección deja de ser un commit para convertirse en un reembolso en mercado extranjero.

Nadie firma esa configuración de precio.

Quién emite el documento y quién recauda el impuesto en destino

La exportación de servicio depende de dónde se verifica el resultado, no de quién paga. Si el resultado queda en Brasil, la operación no es exportación y el ISS se aplica en la redacción actual de la LC 116/2003. Con un merchant of record extranjero, el proveedor le factura a ese tercero y el documento al consumidor se emite en destino.

El artículo 2º, I, de la LC 116/2003 excluye el ISS de las exportaciones de servicio; el párrafo único cierra la puerta, y ni el pago venido del exterior cambia la clasificación cuando el resultado se verifica aquí.

El impuesto sigue vigente con reducción escalonada de alícuotas de 2029 a 2032 (art. 8º-B de la LC 116/2003) y sale de escena al final de la transición.

En la transición, el mismo suministro pasa a estar puesto a prueba por el IBS y la CBS: la LC 214/2025 considera exportación de servicio o de bien inmaterial el suministro a residente o domiciliado en el exterior con consumo en el exterior (art. 80). Son dos pruebas, y no coinciden en toda operación.

Los ingresos de exportación se liquidan por contrato de cambio, y el Decreto 6.306/2007 trata su entrada en dispositivo propio (art. 15-B, I), distinto del que alcanza la remesa al exterior.

En Europa el criterio es explícito: el umbral de EUR 10.000 pertenece al régimen de ventanilla única, alcanza la venta a distancia de bienes y el servicio prestado por vía electrónica, y vale para quien está establecido en un único Estado miembro. Para el proveedor establecido fuera de la Unión no vale: el impuesto se debe en el Estado del consumidor desde la primera operación. La plataforma que intermedia la venta puede ser considerada proveedor en supuestos definidos.

En Estados Unidos, el mapa cambió en 2018: South Dakota v. Wayfair revirtió la exigencia de presencia física y pasó a admitir que los estados exijan de los vendedores remotos el cobro y la remisión, con umbrales estatales.

Dos rutas, dos documentos. El del consumidor no sale del mismo lugar, y quien lo emite responde por el impuesto en destino. La comparación entre merchant of record y operación propia organiza el resto.

Cinco decisiones antes de incrustar cobros en el asistente

Cinco definiciones deben existir antes de la primera llamada en producción: quién es el seller of record, quién emite el documento por mercado, quién absorbe reembolso y chargeback, quién guarda la clave de producción y quién clasifica el ingreso a la salida de Brasil. Sin las cinco, la configuración decide.

Seller of record es el registro de quién vende en la transacción y en el documento. Merchant of record es el rol comercial de quien se presenta como comerciante y responde por impuesto, reembolso y chargeback. Los dos coinciden cuando la empresa vende en nombre propio y se separan cuando un marketplace o una reventa aparece como vendedor.

1. Merchant of record. Definir quién aparece en la factura y a quién reclama el consumidor impide que el rol lo decida la pantalla que alguien montó al final.
2. Documento fiscal por mercado. Definir el registro que sustenta cada documento, CNPJ aquí y registro de consumo o venta B2B allá, evita descubrir en la primera venta un mercado sin registro.
3. Reembolso, chargeback y mora. Definir plazo y techo para quien absorbe la pérdida evita que el equipo de producto herede una que no es suya.

Las tres primeras son de diseño y caben en una reunión. Las dos siguientes son de operación y aparecen el día en que alguien abre el editor con la clave en la mano. Ninguna de ellas es técnica.

1. Clave de producción y límite de creación en el agente. Definir quién puede crear producto, en qué moneda y con qué límite evita que un plan nazca en una moneda que nadie acordó.
2. Clasificación del ingreso a la salida de Brasil. Definir el registro que sustenta la posición de exportación evita que finanzas clasifique el ingreso por hábito del año anterior.

Qué resuelve un checkout transparente, y qué no resuelve

El checkout transparente resuelve dónde paga el comprador, manteniéndolo en el dominio de quien vende. No define quién es el vendedor a efectos fiscales ni quién recauda impuesto en destino. Dentro del agente, transparente gana un segundo sentido: la configuración del cobro queda invisible para quien desarrolla, y la decisión sobre ella también.

En el sentido corriente, el término describe la página de pago en el dominio de quien vende, con el dato de tarjeta en el flujo de la tienda, y lo que resuelve es conversión, no rol fiscal.

En el agente, describe una llamada que abre el cobro sin pasar por la página de la tienda: la herramienta crea la sesión y el comprador concluye el pago en la superficie de la cuenta que emitió esa sesión. Invisible para quien desarrolla es la configuración, no el pago. Qué cambia el checkout local en la conversión de un SaaS en otra moneda es otro cálculo, y eso no altera quién emite el documento.

Los dos sentidos comparten la trampa: transparencia para el comprador no es transparencia para el fisco.

La diferencia es de responsable.

Cuándo cada lado tiene sentido

La empresa asume el rol cuando vende en una moneda, atiende pocos mercados, quiere mantener al cliente y logra registrarse donde necesita. Contrata a un tercero cuando vende en muchos países, a consumidor final, y el costo de registro en cada uno supera lo que el margen soporta. El veredicto es por mercado. Nunca por empresa.

1. Empresa como merchant of record. Ya tiene registro en el mercado de destino, vende a público concentrado y mantiene relación, dato de pago, suscripción y estructura fiscal propia.
2. Tercero como merchant of record. Vende a consumidor final en muchos países. El tercero asume documento, impuesto y reembolso; la empresa entrega margen, relación comercial y portabilidad de la suscripción.
3. Modelo mixto. Es merchant of record donde ya tiene registro y terceriza el resto, con dos regímenes y dos rutinas de conciliación.

El criterio que separa los tres es la combinación de número de mercados, tipo de comprador y disposición de mantener estructura fiscal propia en cada país. Para quien quiere vender SaaS en el exterior sin operación local, el segundo ítem es el más frecuente y el más caro de deshacer.

Qué verificar en el contrato y en la configuración

Contrato y configuración deben responder a las cinco decisiones anteriores, con los mismos nombres: merchant of record, documento fiscal por mercado, reembolso y chargeback, clave de producción y clasificación del ingreso a la salida de Brasil. Verificar esto antes de la primera venta cuesta una reunión. Después, cuesta migración de base.

1. Merchant of record. La cláusula que nombra el rol y lo que atribuye a cada parte.
2. Documento fiscal por mercado. El registro que sustenta cada documento y el responsable nombrado.
3. Reembolso, chargeback y mora. El plazo, el techo y quién paga la diferencia.

Las dos siguientes son de configuración y no aparecen en el contrato.

1. Clave de producción y límite de creación en el agente. Quién es dueño de la clave de producción, cuál es su alcance y cuál es el límite de creación.
2. Clasificación del ingreso a la salida de Brasil. El registro que sustenta la posición de exportación, y quién lo firma.

Fuera de esas cinco, tres verificaciones extra completan la configuración del día a día, sin sustituir ninguna.

• Rotación de la clave de producción y alcance de creación de producto en el agente.
• Tratamiento del dato de pago, con los subprocesadores y la residencia declarada.
• La salida: migración de la suscripción, tokens de tarjeta e historial.

Nexforce Marketplace atiende al proveedor brasileño que quiere recibir en reales con factura local, no convierte a Nexforce en merchant of record en destino ni emite documento en lugar del cliente. Nexforce Marketplace describe el flujo.

Preguntas frecuentes

¿Qué cambia cuando el checkout dentro del agente se convierte en llamada de herramienta?

Cambia el dueño de la configuración. Con el checkout corriendo como herramienta, precio, moneda y plan pasan a definirse por quien tiene la clave de producción, y la pregunta sobre quién es el merchant of record sale de finanzas, por omisión y nunca por decisión.

¿Quién recauda el impuesto al consumo cuando el agente abre el checkout?

Recauda el merchant of record, no la pasarela. Fuera de Brasil, el impuesto sigue el mercado de destino. En Brasil, el ISS se debe en el municipio del establecimiento prestador, salvo las excepciones del art. 3º de la LC 116/2003. El agente no cambia el rol.

¿Qué cambia en la factura de un SaaS brasileño que vende al exterior?

Depende de dónde se verifica el resultado. La LC 116/2003 no trata como exportación el servicio cuyo resultado se verifica en Brasil. Si el software corre y produce efecto aquí, el documento sigue la operación doméstica, con ISS en la redacción actual e IBS y CBS en la transición.

¿El checkout transparente resuelve el problema fiscal de vender fuera de Brasil?

No resuelve. El término define dónde paga el comprador y mantiene el dato de tarjeta en el flujo de quien vende, lo que es decisión de conversión. Quién emite el documento y recauda impuesto en destino lo definen el rol de merchant of record y la ley.

¿Cuándo vale contratar un merchant of record tercero?

Vale cuando el costo de registrarse en cada mercado supera lo que el margen soporta, lo que suele ocurrir en la venta a consumidor final en muchos países. El tercero asume documento, impuesto y reembolso, y la empresa entrega margen y portabilidad de la suscripción.

Referencias y lectura complementaria

• LC 116/2003, Planalto. Acceso 26/10/2026. https://www.planalto.gov.br/ccivil_03/leis/lcp/lcp116.htm
• LC 214/2025, Planalto. Acceso 26/10/2026. https://www.planalto.gov.br/ccivil_03/leis/lcp/lcp214.htm
• Decreto 6.306/2007, IOF, Planalto. Acceso 26/10/2026. https://www.planalto.gov.br/ccivil_03/_ato2007-2010/2007/decreto/d6306.htm
• Ventanilla única de IVA de la Unión Europea. Acceso 26/10/2026. https://vat-one-stop-shop.ec.europa.eu/index_en
• Especificación del Model Context Protocol. Acceso 26/10/2026. https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture
• Especificación de Agent Skills. Acceso 26/10/2026. https://agentskills.io/specification
• South Dakota v. Wayfair, 585 U.S. (2018). Acceso 26/10/2026. https://supreme.justia.com/cases/federal/us/585/17-494/

Qué cuesta esa decisión después

La cuenta de no decidir cae en la primera venta reembolsada en un mercado donde la empresa no emite documento, y en el día en que alguien pregunta quién autorizó el precio.

Lo demás es conversación.