Reenviar notificaciones de pago confirmado

POST /api/v1/webhooks/resend

Solicitar autenticación

Incluye X-Bolt-Key, X-Bolt-Timestamp y X-Bolt-Signature. Utilice un milisegundo actual timestamp y fírmelo junto con el cuerpo exacto de la solicitud.

Cuándo reenviar

Utilice este punto final cuando su sistema necesite otra notificación de un pago confirmado. El reenvío no cobra el pago, no concilia una transferencia ni crea un pedido.

Solo se pueden reenviar sus propios pedidos CONFIRMED o COMPLETED. PENDING, PAID y otros estados no son elegibles.

Se requiere una configuración Webhook activa y disponible. Si no persiste ninguna tarea de entrega, el punto final devuelve un error en lugar de QUEUED.

01. Parámetros de solicitud

application/json

externalOrderIdObligatorio

String

Envíe al comerciante externalOrderId proporcionado al crear el pedido, no a orderToken. Solo puede reenviar notificaciones de pedidos que pertenezcan a la clave API actual.

Valor de ejemplo

{"externalOrderId": "INV-20260209-99281"}

Cadena obligatoria, entre 6 y 64 caracteres. Se permiten letras, dígitos, guiones bajos (_) y guiones (-).

Body

02. Campos de respuesta (data)

application/json

notifyUrlString

Dirección de devolución de llamada registrada en el pedido; puede ser null. La entrega prefiere esta dirección y recurre a la configuración Webhook asociada para pedidos anteriores sin una.

externalOrderIdString

Pedido del comerciante ID asociado con este reenvío, que coincide con la solicitud externalOrderId.

triggerTypeEnum

Siempre MANUAL en la respuesta de este punto final, lo que indica un reenvío solicitado por el comerciante. Este no es el tipo de liquidación de pago.

statusEnum

Reenviar estado de solicitud. QUEUED significa que la tarea persistió; no es el estado del pago ni el comprobante de entrega.

QUEUED indica que la tarea de envío se ha guardado para su envío asíncrono, no que la notificación haya llegado. Revisa los registros del panel del comerciante y la respuesta HTTP 2xx del receptor.

🚀

Manejo de destinatarios

Verifique X-Bolt-Webhook-Timestamp y X-Bolt-Webhook-Signature, luego elimine los duplicados mediante eventId o el pedido comercial ID antes del cumplimiento. Devuelva HTTP 2xx para notificaciones duplicadas que ya se manejaron correctamente.

triggerType: MANUAL aparece en los registros de respuesta de reenvío y de entrega del panel. El cuerpo de solicitud actual Webhook no contiene triggerType; no dependa de él para identificar un reenvío.
Cada llamada exitosa crea una tarea de entrega independiente. Las solicitudes repetidas pueden enviar múltiples notificaciones. Consulte los registros de entrega antes de volver a enviar. Las repeticiones conservan el eventId lógico.
Este punto final reutiliza el destino de devolución de llamada del pedido y no acepta un nuevo URL. Cambiar la configuración predeterminada del panel no reemplaza una dirección ya guardada en el pedido.

Safe

Errores comunes

Estos son casos comunes. Utilice el estado actual de HTTP y el código/mensaje de respuesta para diagnosticar fallas. Una respuesta de error no es un resultado de pago.

401: verifique la clave API, la firma del cuerpo sin formato y el milisegundo actual timestamp (dentro de los 5 minutos del reloj del servidor).
404: el pedido falta, pertenece a otro comerciante o está fuera del historial permitido por su plan.
400: el pedido no es CONFIRMED / COMPLETED, o falta una configuración de Webhook disponible y una tarea de entrega almacenada correctamente.