Descripción general
Las suscripciones bajo demanda te permiten autorizar el método de pago de un cliente una vez y luego cobrar montos variables cuando lo necesites, en lugar de en un horario fijo. Esta función está disponible para todas las cuentas; no se requiere aprobación. Utiliza esta guía para:- Crear una suscripción bajo demanda (autorizar un mandato con un precio inicial opcional)
- Activar cargos posteriores con montos personalizados
- Rastrear resultados utilizando webhooks
Requisitos previos
- Cuenta de comerciante de Dodo Payments y clave API
- Secreto de webhook configurado y un endpoint para recibir eventos
- Un producto de suscripción en tu catálogo
Cómo funciona bajo demanda
- Creas una suscripción con el objeto
on_demandpara autorizar un método de pago y, opcionalmente, cobrar un cargo inicial. - Más adelante, creas cargos contra esa suscripción con importes personalizados usando el endpoint dedicado de cargos.
- Escuchas webhooks (p. ej.,
payment.succeeded,payment.failed) para actualizar tu sistema.
Crear una suscripción bajo demanda
Endpoint: POST /checkouts Campos clave de la solicitud (cuerpo):Consúltalos en Crear Sesión de Pago
Crear una suscripción bajo demanda
- Node.js SDK
- Python SDK
- Go SDK
- cURL
Success
Cargar una suscripción bajo demanda
Después de que se autorice el mandato, crea cargos según sea necesario. Endpoint: POST /subscriptions/{subscription_id}/charge Campos clave de la solicitud (cuerpo):Charge request body parameters
Charge request body parameters
Importe a cobrar (en la unidad monetaria más pequeña). Ejemplo: para cobrar $25.00, pasa
2500.Anulación opcional de moneda para el cargo.
Anulación opcional de descripción para este cargo.
Si es verdadero, incluye tarifas de moneda adaptativa dentro de
product_price. Si es falso, las tarifas se agregan encima.Metadatos adicionales para el pago. Si se omite, se utilizan los metadatos de la suscripción.
- Node.js SDK
- Python SDK
- Go SDK
- cURL
Success
Reintentos de pago
Nuestro sistema de detección de fraude puede bloquear patrones de reintento agresivos (y puede marcarlos como pruebas de tarjeta potenciales). Sigue una política de reintento segura.Principios para políticas de reintento seguras
- Mecanismo de retroceso: Usa retroceso exponencial entre reintentos.
- Límites de reintento: Limita los reintentos totales (máx. 3–4 intentos).
- Filtrado inteligente: Reintenta solo en fallos reintentables (p. ej., errores de red/emisor, fondos insuficientes); nunca reintentes rechazos definitivos.
- Prevención de pruebas de tarjetas: No reintentes fallos como
DO_NOT_HONOR,STOLEN_CARD,LOST_CARD,PICKUP_CARD,FRAUDULENT,AUTHENTICATION_FAILURE. - Varía los metadatos (opcional): Si mantienes tu propio sistema de reintentos, diferencia los reintentos mediante metadatos (p. ej.,
retry_attempt).
Cronograma de reintentos sugerido (suscripciones)
- 1er intento: Inmediato cuando creas el cargo
- 2do intento: Después de 3 días
- 3er intento: Después de 7 días más (10 días en total)
- 4to intento (final): Después de otros 7 días (17 días en total)
Evita reintentos en ráfaga; alinea al tiempo de autorización
- Ancla los reintentos al sello de tiempo original de autorización para evitar comportamientos de “ráfaga” en todo tu portafolio.
- Ejemplo: si el cliente inicia una prueba o mandato a la 1:10 p. m. de hoy, programa reintentos de seguimiento a la 1:10 p. m. en días posteriores según tu retroceso (p. ej., +3 días → 1:10 p. m., +7 días → 1:10 p. m.).
- Alternativamente, si almacenas la hora del último pago exitoso
T, programa el próximo intento enT + X dayspara mantener la alineación horaria.
Zona horaria y horario de verano: usa un estándar de tiempo consistente para programar y convierte solo para visualización para mantener los intervalos.
Códigos de rechazo que no debes reintentar
STOLEN_CARDDO_NOT_HONORFRAUDULENTPICKUP_CARDAUTHENTICATION_FAILURELOST_CARD
Para una lista completa de razones de rechazo y si se pueden corregir por el usuario, consulta la documentación de
Transaction Failures.
Directrices de implementación (sin código)
- Usa un programador/cola que persista sellos de tiempo precisos; calcula el próximo intento en el mismo desplazamiento de hora del día exacto (p. ej.,
T + 3 daysa la misma HH:MM). - Mantén y consulta el sello de tiempo del último pago exitoso
Tpara calcular el siguiente intento; no aglomeres múltiples suscripciones al mismo instante. - Evalúa siempre la última razón de rechazo; detén los reintentos para rechazos definitivos en la lista de exclusión anterior.
- Limita los reintentos simultáneos por cliente y por cuenta para evitar aumentos accidentales.
- Comunica de forma proactiva: envía un correo electrónico/SMS al cliente para que actualice su método de pago antes del siguiente intento programado.
- Usa metadatos solo para observabilidad (p. ej.,
retry_attempt); nunca intentes “evadir” los sistemas de fraude/riesgo rotando campos sin importancia.
Rastrear resultados con webhooks
Implementa el manejo de webhooks para rastrear el viaje del cliente. Consulta Implementación de Webhooks.- subscription.active: Mandato autorizado y suscripción activada
- subscription.failed: Creación fallida (por ejemplo, fallo del mandato)
- subscription.on_hold: Suscripción en espera (por ejemplo, estado impago)
- payment.succeeded: Cargo exitoso
- payment.failed: Cargo fallido
Pruebas y próximos pasos
Create in test mode
Usa tu clave de API de prueba para crear la suscripción con
payment_link: true, luego abre el enlace y completa el mandato.Trigger a charge
Llama al endpoint de carga con un pequeño
product_price (p. ej., 100) y verifica que recibes payment.succeeded.Solución de problemas
- 422 Invalid Request: Asegúrate de que
on_demand.mandate_onlyse proporciona al crear yproduct_pricese proporciona para los cargos. - Errores de moneda: Si anulas
product_currency, confirma que está soportado para tu cuenta y cliente. - No se reciben webhooks: Verifica la configuración de tu URL de webhook y el secreto de firma.