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 tarde, creas cargos contra esa suscripción con montos personalizados utilizando el endpoint de cargo dedicado.
- Escuchas los webhooks (por ejemplo,
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):Parámetros del cuerpo de la solicitud de cargo
Parámetros del cuerpo de la solicitud de cargo
Monto a cobrar (en la unidad más pequeña de la moneda). Ejemplo: para cobrar $25.00, pasa
2500.Anulación de moneda opcional para el cargo.
Anulación de descripción opcional para este cargo.
Si es verdadero, incluye tarifas de moneda adaptativa dentro de
product_price. Si es falso, las tarifas se añaden por 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: Utiliza retroceso exponencial entre reintentos.
- Límites de reintento: Limita el total de reintentos (máximo de 3 a 4 intentos).
- Filtrado inteligente: Reintenta solo en fallos reintentables (por ejemplo, errores de red/emisor, fondos insuficientes); nunca reintentes rechazos duros.
- Prevención de pruebas de tarjeta: No reintentes fallos como
DO_NOT_HONOR,STOLEN_CARD,LOST_CARD,PICKUP_CARD,FRAUDULENT,AUTHENTICATION_FAILURE. - Variar metadatos (opcional): Si mantienes tu propio sistema de reintento, diferencia los reintentos a través de metadatos (por ejemplo,
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 a la marca de tiempo de autorización original para evitar un comportamiento de “ráfaga” en tu cartera.
- Ejemplo: Si el cliente inicia una prueba o mandato a la 1:10 p. m. de hoy, programa los reintentos de seguimiento a la 1:10 p. m. en días posteriores según tu retroceso (por ejemplo, +3 días → 1:10 p. m., +7 días → 1:10 p. m.).
- Alternativamente, si almacenas el último tiempo de pago exitoso
T, programa el próximo intento aT + X dayspara preservar la alineación de la hora del día.
Zona horaria y DST: utiliza un estándar de tiempo consistente para la programación y convierte solo para la 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 son corregibles por el usuario, consulta la
Fallos de Transacción documentación.
Directrices de implementación (sin código)
- Utiliza un programador/cola que persista marcas de tiempo precisas; calcula el próximo intento en el mismo desplazamiento de hora del día (por ejemplo,
T + 3 daysa la misma HH:MM). - Mantén y referencia la última marca de tiempo de pago exitoso
Tpara calcular el próximo intento; no agrupe múltiples suscripciones al mismo instante. - Siempre evalúa la última razón de rechazo; detén los reintentos para rechazos duros en la lista de omisión anterior.
- Limita los reintentos concurrentes por cliente y por cuenta para evitar picos accidentales.
- Comunica proactivamente: envía un correo electrónico/SMS al cliente para actualizar su método de pago antes del próximo intento programado.
- Utiliza metadatos solo para observabilidad (por ejemplo,
retry_attempt); nunca intentes “eludir” los sistemas de fraude/riesgo rotando campos irrelevantes.
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
Crear en modo de prueba
Utiliza tu clave API de prueba para crear la suscripción con
payment_link: true, luego abre el enlace y completa el mandato.Activar un cargo
Llama al endpoint de cargo con un pequeño
product_price (por ejemplo, 100) y verifica que recibas payment.succeeded.Solución de problemas
- 422 Solicitud Inválida: Asegúrate de que
on_demand.mandate_onlyse proporcione en la creación yproduct_pricese proporcione para los cargos. - Errores de moneda: Si anulas
product_currency, confirma que sea compatible con tu cuenta y cliente. - No se recibieron webhooks: Verifica tu URL de webhook y la configuración del secreto de firma.