Cobrar en pesos: por qué Stripe no alcanza en Argentina y cómo encararlo

Si te sentaste a comparar pasarelas de pago en Argentina para 2026 con la idea de meterle Stripe a tu SaaS y cobrar en pesos, seguro ya te pasó lo mismo que a todos: en las guías locales Stripe directamente no aparece. No es un olvido de los autores. Es que, para cobrar en ARS de forma local, Stripe no es una opción práctica — y eso cambia por completo cómo tenés que pensar el billing de un producto que factura en LATAM.

Este post es el mapa: por qué Stripe no es un riel local acá, qué te queda realmente para cobrar en pesos, dónde está el dolor que nadie te cuenta hasta que lo integrás, y cómo lo dejamos resuelto en useDeploy detrás de una sola interfaz. La versión corta del producto está en la página de billing; esto es el razonamiento de por qué esa página existe.

Por qué Stripe no es una pasarela local en Argentina

El detalle que rompe el plan de "uso Stripe y listo" es regulatorio, no técnico. Stripe no opera directo en Argentina por la restricción del BCRA. Lo más cerca que llegás es a través de un intermediario como dLocal, y ahí la comisión real trepa al rango de 4-6% y la liquidación cae en cuentas en USD/EUR — no en tu cuenta en pesos (fuente, a julio de 2026). Para un producto que le cobra a clientes locales, eso son dos problemas encimados: un costo transaccional más alto y una fricción cambiaria que no querés heredar.

MercadoPago, en cambio, cobra desde alrededor de 2,99% (misma fuente, a julio de 2026), liquida en pesos y trae suscripciones recurrentes nativas vía su API de preapproval. No es que MercadoPago sea "el Stripe pobre": es el riel que efectivamente puede procesar un pago en ARS sin pasar por una entidad extranjera.

El error mental que conviene desarmar temprano es tratar a Stripe y MercadoPago como sustitutos. No lo son. Son rieles complementarios:

• Stripe te sirve para cobro global en USD — típicamente si facturás desde una entidad en EE.UU. a clientes de afuera.
• MercadoPago te sirve para cobro local en pesos, con recurrencia nativa, a clientes en Argentina (y con equivalentes para Brasil y México).

La mayoría de los productos LATAM terminan necesitando los dos: MercadoPago para el mercado local y Stripe para el que paga en dólares. La pregunta correcta no es "¿cuál elijo?", sino "¿cómo hago para no reescribir el billing cuando sume el segundo?".

El mapa real de pasarelas de pago Argentina 2026

Cuando mirás una guía comparativa de pasarelas de pago en Argentina para 2026, la foto es clara. Una de las más completas lista diez proveedores — Mercado Pago, Payway, Mobbex, dLocal, Rebill, entre otros — y no menciona a Stripe una sola vez (fuente, a julio de 2026). Ese silencio es la respuesta a tu búsqueda: para cobrar en pesos localmente, el default pragmático es MercadoPago, y el resto son variaciones sobre agregadores y procesadores del mismo ecosistema.

Ahora, acá viene el problema que hace que este tema sea molesto de verdad: casi todos los boilerplates de SaaS que vas a encontrar son Stripe-first. ShipFast, MakerKit, Supastarter — todos asumen Stripe por defecto y ninguno trae MercadoPago listo. El resultado práctico es que, si construís para LATAM y arrancás de uno de esos kits, terminás pegando MercadoPago a mano en cada proyecto (por eso goncy/next-mercadopago es una referencia que aparece una y otra vez en la comunidad). El riel local, justo el que necesitás, es el que ninguno trae.

El costo escondido: integrar MercadoPago no es como integrar Stripe

Elegir MercadoPago resuelve el "cómo cobro en pesos", pero abre otro frente: la developer experience. Y esto no es opinión de un blog, es lo que dicen los propios devs en los repos oficiales de MercadoPago. En el hilo mercadopago/sdk-js#62 hay decenas de integradores frustrados (a julio de 2026):

"Please fix the sandbox for the Checkout Pro; it's just plainly unacceptable that we need to test our integration in production." — Víctor G. G. Quiroga

"I am almost giving up on integrating with Mercado Pago." — Rafael Cardoso

"Im dropping the integration and moving forward with another provider." — Vicente Martinez

El dolor es reproducible: un sandbox de Checkout Pro que te obliga a testear en producción, test users que no andan, errores intermitentes. En español ese mismo dolor vive en r/devsarg, que es el epicentro de la charla sobre pagos entre devs argentinos. Si vas a integrar MercadoPago, este es el pozo en el que vas a caer — y la razón por la que tener la integración ya resuelta vale plata real.

Pero el dolor del sandbox es solo la superficie. El problema técnico de fondo es que el webhook de MercadoPago es asincrónico y no te trae el pago: te avisa con el id de un pago y vos tenés que ir a buscar la verdad con otra request. La notificación puede llegar más de una vez, y si tu handler no es idempotente, el mismo pago te termina generando dos cobros o dos filas en la base. La verdad aterriza después, y esa ventana es exactamente donde las integraciones caseras se rompen.

Cómo lo encara useDeploy: un puerto, varios rieles

La decisión de arquitectura que resuelve el problema "necesito los dos rieles sin reescribir nada" es poner un único puerto tipado entre tu aplicación y el proveedor. En useDeploy eso es la interfaz IPaymentProvider: checkout, portal del cliente, webhooks y catálogo de planes hablan solo con esa interfaz, y cada proveedor es un adapter que se elige por variable de entorno.

Lo primero que se nota es que las monedas de LATAM son ciudadanas de primera clase desde la primera línea, no un parche posterior:

export type Currency = 'USD' | 'EUR' | 'ARS' | 'BRL' | 'MXN';

export interface Money {
  /** Monto en la unidad mínima de la moneda (centavos). */
  readonly amountMinor: number;
  readonly currency: Currency;
}

Prender MercadoPago es una variable de entorno, no un refactor:

PAYMENT_PROVIDER=mercado-pago
MERCADO_PAGO_ACCESS_TOKEN=...
MERCADO_PAGO_WEBHOOK_SECRET=...

El adapter de MercadoPago trae el checkout implementado contra la Preferences API (el redirect de Checkout Pro) para mode: 'payment', y el webhook resuelto de verdad: verifica la firma HMAC con el esquema exacto de MercadoPago (id:<data.id>;request-id:<x-request-id>;ts:<ts>;, HMAC-SHA256, comparación en tiempo constante), y recién ahí va a buscar el estado real del pago con un GET /v1/payments/:id. Ese patrón "el webhook te da un id, vos traés la verdad" es justo donde las integraciones DIY tropiezan, y el evento normalizado que sale de ahí se publica por el outbox del event bus — con handlers idempotentes — para que una notificación repetida no se convierta en un doble cobro.

Ahora la parte honesta, porque un boilerplate que sobrevende sus adapters te hace perder la tarde. La recurrencia nativa de MercadoPago (preapproval) todavía no está implementada, y el adapter lo dice en la cara en vez de fallar raro:

if (input.mode === 'subscription') {
  return err(
    new InfrastructureError(
      'MercadoPago subscriptions (preapproval) are not yet supported. ' +
        'Use mode "payment" for one-time checkout.',
    ),
  );
}

Así que, a hoy, el adapter de MercadoPago te cubre pagos únicos con Checkout Pro, firma de webhook e idempotencia; las suscripciones recurrentes por preapproval son el próximo paso que dejás enchufado contra un contrato que ya existe, no una integración que tenés que diseñar de cero. El adapter de Stripe, por su lado, es todavía un esqueleto tipado: sus métodos devuelven un InfrastructureError('... not yet implemented') hasta que le metés el SDK. Lo que está 100% comprometido es la interfaz — sumar o cambiar de proveedor es tocar un solo archivo, y el resto de la app nunca ve un DTO de Stripe ni de MercadoPago. Si querés el recorrido completo del puerto y sus tres adapters, está en One billing port, three providers y en la doc de billing.

Qué mirar antes de elegir cómo cobrar en pesos

Si estás en la etapa de decidir tu stack de pagos para un producto LATAM, esta es la checklist que te ahorra reescrituras:

• Riel local real. ¿Podés liquidar en pesos sin pasar por una entidad extranjera? Si la respuesta es "vía dLocal en USD", ese 4-6% y la fricción cambiaria son parte del costo del producto.
• Recurrencia nativa. Si vendés suscripciones, fijate que el riel soporte cobros recurrentes de verdad (el preapproval de MercadoPago), no que tengas que simularlos con pagos únicos y cron.
• Webhook firmado + idempotencia. El modelo asincrónico ("la verdad aterriza después") es donde nace el bug de doble cobro. Verificación de firma y handlers idempotentes no son opcionales.
• No casarte con un solo proveedor. Vas a querer MercadoPago para local y Stripe para USD tarde o temprano. Un puerto tipado hace que sumar el segundo sea un archivo, no un rewrite.
• Docs en tu idioma. Integrar MercadoPago ya es bastante dolor sin además tener que traducir de cabeza. Docs reales en ES/PT (no solo routing de locale) cuentan.

La conclusión práctica de buscar "pasarelas de pago Argentina 2026" es incómoda pero clara: Stripe no te alcanza para cobrar en pesos, MercadoPago es el default pragmático, y su integración es lo suficientemente molesta como para que valga la pena no arrancar de cero. Esa es exactamente la apuesta de useDeploy — MercadoPago nativo (con Stripe y Polar detrás de la misma interfaz para cuando necesites cobro global), webhooks firmados e idempotencia ya resueltos, y docs trilingües de verdad. Si construís para el mercado local, empezá por la página para builders LATAM/MercadoPago y seguí por la página de billing para ver dónde está la costura.