Hola — vi tu mensaje esta mañana, la captura de pantalla de alguien preguntando "cómo te pago por esto" en la bandeja de soporte de tu app. Felicidades, de verdad. Ese es el momento en que un proyecto paralelo deja de ser una demo. También es el momento en que cien pequeñas decisiones que has podido posponer aparecen todas el mismo martes. Me pediste que simplemente te dijera qué hacer. Voy a hacerlo, pero quiero explicarte primero el porqué, porque el "porqué" es lo que evita que tengas que preguntarme de nuevo dentro de tres meses cuando sea Lemon Squeezy en vez de Stripe, o suscripciones en vez de pago único.
La decisión que realmente estás tomando
Lo planteaste como "qué proveedor de pagos debería usar", pero en realidad son dos decisiones apiladas una sobre otra. Primero: ¿quieres ser el comerciante registrado, o quieres que otro lo sea? Segundo: ¿cuál es la forma de tu facturación: compra única, suscripción o según uso? Si te equivocas en la primera, dentro de seis meses te pasarás un fin de semana registrándote para el IVA en un país que nunca has visitado. Si te equivocas en la segunda, es una migración molesta, no legal, así que es la menos preocupante de las dos.
Ser el comerciante registrado significa que tú eres quien vende el producto, legalmente. Recaudas el dinero, eres responsable de calcular el impuesto sobre ventas y el IVA en cada jurisdicción donde vivan tus clientes, y presentas las declaraciones correspondientes. Stripe calculará ese impuesto por ti con gusto (Stripe Tax), pero calcular no es lo mismo que remitir: aún tienes que registrarte y presentar declaraciones en cada lugar donde superes un umbral. Un servicio de comerciante registrado como Lemon Squeezy o Paddle te quita todo ese problema de encima: ellos son legalmente el vendedor, recaudan y remiten el impuesto en todas partes, y te pagan el neto. A cambio, cedes una parte del margen.
| Opción | Quién es el vendedor | Comisión típica | Gestión de impuestos | Ideal para |
|---|---|---|---|---|
| Stripe (directo) | Tú | ~2.9% + $0.30/transacción, +0.5% por Stripe Tax | Tú te registras y presentas declaraciones, Stripe solo calcula | Esperas escalar más allá de unos pocos miles al mes y quieres tarifas más bajas a largo plazo |
| Lemon Squeezy | Lemon Squeezy | ~5% + 0,50 $/transacción | Totalmente gestionado, ellos son el vendedor registrado | Creador independiente, primer producto, no quiere pensar en impuestos para nada |
| Paddle | Paddle | ~5% + comisiones que varían según la región | Totalmente gestionado, más orientado a empresas | SaaS con suscripciones y algunas necesidades de facturación |
| PayPal | Tú | ~3,5-4,5%, disputas favorables al comprador | Tú te encargas | Clientes que confían específicamente en PayPal, no es una opción predeterminada |
Para el punto en el que estás ahora mismo —un cliente, un producto simple, sin saber todavía si esto se convertirá en un negocio— te recomendaría Lemon Squeezy o Paddle antes que Stripe directo. Ese par de puntos extra de comisión es un seguro barato contra convertirte accidentalmente en declarante de impuestos en un estado donde nunca has puesto un pie. Puedes migrar a Stripe directo más adelante, una vez que el volumen justifique el cambio y tengas estómago para el papeleo. Nadie migra proveedores de pago por diversión, pero es un problema resoluble en un martes cualquiera, no un problema que te quite el año.
Yo mismo cometí este error en un proyecto anterior: fui directo a Stripe porque "todo el mundo usa Stripe", cobré unos cientos de dólares al mes a un puñado de clientes europeos, y dieciocho meses después recibí un correo muy educado pero muy confuso sobre el registro en el VAT MOSS. Me costó una tarde de contable y cuarenta minutos de pánico puro buscando en Google "si le debo dinero a Países Bajos". No fue catastrófico. Tampoco era necesario en absoluto.
Antes de tocar las claves de producción
Elijas lo que elijas, no lo conectes primero en modo producción. Todos estos proveedores tienen un modo de prueba/sandbox con números de tarjeta falsos que provocan resultados específicos: cargo exitoso, tarjeta rechazada, requiere 3D Secure, fondos insuficientes. Prueba todos esos casos antes de tocar una clave real. Las rutas de fallo son las que realmente te encontrarás en la primera semana, y son mucho menos divertidas de depurar en producción con la tarjeta real de una persona de por medio.
En tu chat de construcción, deja claro que quieres esto por etapas: pide que la integración se conecte primero en modo de prueba, con un banner o indicador claramente visible para que nadie —incluido tu yo del futuro— cobre por accidente a una tarjeta real mientras se está probando. Luego haz un segundo paso, deliberado, para cambiar a las claves de producción. Dos indicaciones, no una, aunque sea más rápido decir simplemente "añade pagos" y dejar que adivine el modo. La fricción es justamente el objetivo.
También tienes que decidir qué pasa cuando se dispara un webhook y tu servidor está caído, lento, o el evento llega dos veces. Esto no es hipotético: sucede en la primera semana, de forma constante. Los eventos que realmente necesitas gestionar, como mínimo:
checkout.session.completed(o el equivalente): concede el acceso, este es el momento en que el cliente se convierte en clienteinvoice.payment_failed— para suscripciones, decide ahora si eso significa un bloqueo instantáneo o un periodo de gracia, porque un "bloqueo instantáneo" es realmente una mala primera impresión para una tarjeta que acaba de tener un fallo temporalcustomer.subscription.deleted— alguien canceló, revoca el acceso al final del periodo, no de inmediato, a menos que tus términos digan lo contrario- Un evento de reembolso: decide una vez, por escrito para ti mismo, cuál es realmente tu política de reembolsos, antes de que la primera solicitud de reembolso te obligue a decidirlo sobre la marcha
La idempotencia importa aquí más que en casi cualquier otra parte de tu app. Si un webhook llega dos veces —y llegará, los proveedores reintentan ante cualquier respuesta que no sea 200— no puedes conceder acceso dos veces ni, peor aún, duplicar el estado interno de cobro. Guarda el ID del evento y comprueba que no lo has procesado antes de actuar sobre él.
La pregunta de precios que estás evitando
Mencionaste en tu mensaje que no sabías si cobrar 9 $/mes o un pago único de 49 $. No creo que ninguna de las dos opciones sea incorrecta, pero fíjate en lo que realmente estás evitando: la conversación con el cliente sobre cuál es el valor recurrente. Un precio único es más fácil de aceptar y más fácil de construir para ti (sin gestión de cobros fallidos, sin manejo de renovaciones fallidas, sin flujo de cancelación). Una suscripción es una apuesta a que seguirás mejorando el producto lo suficiente como para que la gente no se dé de baja, lo cual es un compromiso real, no solo una casilla en una página de precios. Si no estás seguro de que seguirás trabajando activamente en esto dentro de seis meses, un precio único es la oferta más honesta. Siempre puedes añadir un nivel de suscripción más adelante, una vez que haya algo continuo a lo que suscribirse.
Una cosa más, y luego te dejo seguir: pon una política real de reembolsos y cancelaciones en la página antes de cobrar el primer dólar, aunque sean tres frases. No porque nadie te vaya a demandar por un cargo de 9 $, sino porque escribirla te obliga a decidirla de verdad, y "ya lo resolveré cuando alguien pregunte" es la forma en que acabas tomando una decisión de política en medio de un correo enfadado en lugar de una tarde tranquila.
Ve a conectar primero el sandbox. Escríbeme cuando hayas pasado una tarjeta falsa rechazada por él; esa es la versión de "funciona" que de verdad importa.
