Pagos para una empresa unipersonal: Stripe, Paddle, Lemon Squeezy o WeChat Pay

Aviso: este texto no es asesoría fiscal, legal, societaria, cambiaria ni de elegibilidad. Para Merchant of Record, VAT/GST/sales tax, entidades nacionales o extranjeras y liquidaciones, consulta las condiciones del servicio y a profesionales.

Tu pricing.ts define starter_monthly, pro_yearly, lifetime_license y wechat_one_time, pero la base solo tiene is_paid. Llega checkout.session.completed y el cliente vuelve por success_url, aunque entitlements sigue vacío. No falla el botón: el sistema no conecta productos, pedidos, suscripciones y acceso.

Antes de elegir proveedor hay cinco preguntas: qué vendes, cómo cobras, a quién, quién asume la transacción y el impuesto sobre ventas, y quién concede acceso tras el pago. Stripe, Paddle, Lemon Squeezy y WeChat Pay no son cuatro botones equivalentes; cubren responsabilidades distintas.

Define el modelo de venta antes del proveedor de pagos

Una compra única gira alrededor del pedido y la entrega. Una suscripción SaaS exige todo el billing lifecycle. El cobro por uso también necesita datos de consumo trazables. Lleva primero el modelo a products, prices y tablas locales.

Tres puntos importantes:

• Una venta única necesita pedido, entrega, reembolso y reenvío, no todo el ciclo de suscripción.
• Un SaaS recurrente necesita subscriptions con current_period_start/end, cancel_at y status; el consumo añade usage_events auditables.
• WeChat Pay es vía de pago y sistema de comercio, no Merchant of Record global ni plataforma de SaaS billing.

Las capacidades cambian. Antes de integrar, revisa región de cuenta, modo de producto, medios de pago, versión de API y condiciones.

Un Merchant of Record no elimina todas las responsabilidades

Un Merchant of Record, o MoR, es el vendedor registrado de una transacción. Paddle y Lemon Squeezy usan este modelo para productos digitales elegibles y gestionan pago, impuesto sobre ventas, reembolso o disputas dentro de ese alcance. Reduce la operación fiscal global, pero no elimina obligaciones de renta, entidad, producto, datos y contabilidad.

Vultr - Servidor cloud NVMe de alto rendimiento, 32 ubicaciones globales, despliegue Docker con un clic

Ver precios →Anuncio

Con Stripe, el comercio suele seguir siendo el vendedor registrado. Stripe Tax ayuda a calcular sales tax, VAT y GST y ofrece herramientas de supervisión y registro, pero no convierte automáticamente a Stripe en Merchant of Record. Registro, declaración y entidad dependen de la jurisdicción y la transacción.

No elijas un MoR por un umbral fijo de ingresos. Compara estas dimensiones:

El límite contractual y fiscal depende de entidad, territorio, producto y cliente. Una página comercial no sustituye las condiciones ni el asesoramiento.

Cómo elegir Stripe, Paddle, Lemon Squeezy o WeChat Pay

Si necesitas suscripciones y WeChat Pay, separa primero los problemas. Ciclo de suscripción, pagos globales y China pueden usar servicios distintos. Que un método aparezca en la plataforma no significa que funcione en cada región, modo Checkout o cobro recurrente.

La documentación oficial confirmaba el 18 de julio de 2026:

• Stripe Checkout ofrece páginas alojadas, integradas y componentes combinables. Los métodos dependen de región, divisa y modo Checkout.
• Paddle entrega webhooks al menos una vez. Si el endpoint no devuelve 200 en cinco segundos, reintenta. Puede duplicar o desordenar; usa event_id y occurred_at.
• Lemon Squeezy lista Cards, PayPal, Apple Pay, Google Pay, Alipay, WeChat Pay, Cash App Pay y bank debits. Las suscripciones solo admiten Cards, Apple Pay, Google Pay y PayPal.
• WeChat Pay H5 necesita crear el pedido en servidor, recibir callback y consultar el estado. El retorno del navegador no es definitivo.

Comisiones, medios, liquidación, países y políticas cambian. Abre las páginas de precios y contratos actuales al preparar el presupuesto.

El webhook es la frontera de sincronización de acceso

Dos fallos comunes:

1. Llega checkout.session.completed y se visita success_url, pero entitlements no cambia y el cliente no accede.
2. El mismo evento entra dos veces en webhook_events y el handler emite dos licencias.

Ambos tratan una solicitud HTTP o la página de éxito como verdad final. Los eventos pueden duplicarse, retrasarse o llegar desordenados; algunos estados requieren consulta o un evento posterior.

Principios para diseñar el endpoint webhook

Reglas operativas:

• Webhook o callback inicia la sincronización. success_url solo muestra procesamiento.
• Verifica la firma y guarda el evento o campos necesarios en webhook_events; mueve el trabajo complejo a un job asíncrono.
• Impón una restricción única y registra event_id, source, occurred_at, processed_at, status y payload_hash.
• Para el desorden, compara hora del proveedor, actualización del objeto o versión del estado, no solo llegada.
• Ejecuta reconciliation, consulta pedido o suscripción y conserva recuperación manual.

Tablas de pedidos, suscripciones, acceso y eventos

No copies cada objeto de la API. Define campos estables para decidir acceso y guarda IDs del proveedor para consultas y reconciliation.

KiloClaw - OpenClaw gestionado para empresas: orquestación de agentes IA y enrutamiento inteligente

Empezar →Anuncio

Estrategias de sincronización de acceso

Paddle recomienda lean cache para la mayoría de aplicaciones. Usa state mirror solo si necesitas consultas locales más ricas. Las claves de Lemon Squeezy también exigen validar producto y cliente y vincular la instance con tu cuenta y dispositivo.

Puntos de integración de cada servicio

Estos puntos delimitan la primera implementación, no sustituyen la documentación completa.

Integrar Stripe

Un SaaS inicial puede usar Checkout alojado y Customer Portal en lugar de mantener un formulario de tarjeta. Stripe Billing gestiona suscripciones, facturas, consumo y recuperación de ingresos. Stripe Tax es herramienta fiscal, no Merchant of Record.

Productos y precios deben mapearse a acceso local: product_id es producto o paquete; price_id, mensual, anual, seat o usage. No dejes solo is_paid en users.

Consulta el tutorial de carrito Next.js y pago con Stripe para Checkout Session, endpoint webhook y pedidos.

Integrar Paddle

Confirma que el tutorial usa Paddle Billing, no Paddle Classic. Cambian API, webhooks, Paddle.js y Product/Price.

Paddle Checkout muestra la caja, pero la aplicación hace provisioning. Normalmente basta con customer, subscription, status, price, product y scheduled change. Crea state mirror solo si operaciones necesita datos completos.

Actualiza ambos modelos por webhook y ejecuta reconciliation. Un Merchant of Record no sabe automáticamente quién usa cada función.

Integrar Lemon Squeezy

Lemon Squeezy sirve para productos digitales, licencias y suscripciones simples. Ofrece Merchant of Record, checkout, suscripciones, usage-based billing, webhooks y License Keys. Confirma tarifas y alcance en el store plan actual.

Alibaba Cloud - Opción preferida para desarrolladores, 15 % de descuento exclusivo en Lighthouse

Obtener 15% dto. →Anuncio

Tras activar una clave, guarda instance ID y verifica store_id, product_id, variant_id y customer. Una clave ajena o revendida no debe activar Pro.

Para suscripción con WeChat Pay, revisa aparte los métodos recurrentes. La documentación lista WeChat Pay y Alipay, pero las suscripciones solo admiten Cards, Apple Pay, Google Pay y PayPal.

Límites de WeChat Pay

WeChat Pay funciona para China continental y WeChat, pero no es Merchant of Record global ni ciclo SaaS completo. El comercio gestiona estado, firma, consultas, reembolsos, reconciliation, facturas y acceso.

H5, JSAPI, Mini Program y Native son escenarios de pago. En H5, el backend crea el pedido y entrega h5_url; al volver el navegador, consulta el pedido y aplica el callback al mismo out_trade_no.

Verifica permisos, entidad, dominios, tarifas y parámetros en la documentación vigente de WeChat Pay.

Siguiente paso: convertir el botón en una máquina de estados comprobable

Después de elegir, divide la integración en tareas verificables:

1. Crea orders, subscriptions, entitlements y webhook_events; añade usage_events para consumo.
2. Implementa firma, idempotencia, desorden, confirmación rápida y recuperación para cada webhook o callback.
3. Haz que la página de éxito consulte el pedido local en lugar de escribir is_paid=true.
4. Añade pruebas de consulta, reconciliation, reembolso, renovación fallida y recuperación manual.
5. Reenvía eventos e invierte actualizaciones en sandbox; el acceso no debe duplicarse ni revertirse por error.

Para backend y base de datos, continúa con Supabase Edge Functions y los artículos de backend y datos de esta serie. Completar no es volver de la página de pago: pedidos, suscripciones y acceso deben converger al estado correcto pese a duplicados, retrasos, desorden y reembolsos.