Flujo de pago con tarjeta
Sigue los estados de compra, autorización, 3DS, revisión, captura, anulación y reembolso de la tarjeta, sin mezclar la autenticación con el éxito del pago.
En esta página
Los pagos con tarjeta utilizan un modelo de compra de un solo paso o un modelo de autorización y captura de dos pasos. Consulta el valor actual en payment.data.statussi el pago está dentro de una respuesta de pedido, lea order.payment.data.status.
Utiliza esta página para la ruta específica de la tarjeta. Para cada definición de estado y transición directa permitida, consulta Flujo y estados de pago.
Compra y autorización#
La conexión configurada con el procesador determina si DEUNA realiza una compra o una autorización. Un desafío 3DS puede preceder a cualquiera de las operaciones.
| Estado | Significado | Acción del comerciante |
|---|---|---|
pending | El pago con tarjeta existe, pero el enrutamiento, la autenticación o el procesamiento pueden no haberse iniciado. | Seguir next_action cuando esté presente y mantén la ejecución bloqueada. |
pending_3ds | La autenticación del emisor está incompleta. | Completa el desafío y luego evalúa el nuevo estado del pago. |
processing | Una solicitud de compra está en curso. | Esperar processed o cualquier resultado autorizado. |
authorizing | Una autorización de dos pasos está en curso. | Esperar authorized o cualquier resultado autorizado. |
processed | Una compra se ha completado y los fondos se han recogido. | Aplica la política de cumplimiento; el pago aún puede ser reembolsado. |
authorized | Los fondos se han reservado, pero no se han recogido. | Realiza la captura o la anulación dentro de los límites de la conexión con el procesador. |
3DS y OTP
La autenticación solo permite que continúe el flujo con la tarjeta. No demuestra que una compra o autorización se haya completado. Después del desafío, espere a processed, authorizedu otro estado de pago informado.
Algunos adaptadores de procesador utilizan pending_otp internamente. El procesamiento de pagos actual normaliza ese resultado al público. pending y proporciona los metadatos necesarios para la siguiente acción. Si un informe o filtro de búsqueda anterior contiene pending_otp, trátelo como si estuviera esperando la acción del cliente, no como si el pago fuera exitoso.
Revisión de riesgos y reintentos#
manual_review hasta que una decisión de riesgo produzca un nuevo estado de pago. Una revisión aprobada puede continuar con processed o captured; una revisión rechazada puede producir denied. Ver Flujo de trabajo y estados de fraude para los campos y decisiones de fraude separados.
denied describe el intento fallido, pero la máquina de estados de pagos puede redirigir o reintentar el mismo pago en pending, pending_3ds, processingo authorizing. No complete un intento denegado, y no modele denied como un estado de pago en el terminal.
Capturar una autorización#
Capturar convierte los fondos reservados en fondos recaudados. El procesador, el importe autorizado restante, los límites de tiempo y la configuración del comerciante determinan qué operaciones de captura son elegibles.
La máquina de estados también puede recibir captured o partial_captured directamente sin exponer el estado "en curso". Las notificaciones son instantáneas autoritativas, no una secuencia garantizada de eventos.
Para los modos de captura parcial, la concurrencia, los límites de tiempo y final_capture, ver MPC: capturas parciales múltiples.
Anular una autorización#
Anular libera los fondos reservados. Esto es diferente de una devolución, que devuelve fondos que ya se han recaudado.
El estado de API nula devuelve HTTP 204 No Content. Cuando el procesador completa de forma asíncrona, use el estado de pago posterior como resultado.
Devolver fondos recaudados#
Una compra exitosa, una captura completa o una captura parcial pueden devolverse cuando la conexión y el importe restante lo permitan.
Una devolución fallida puede restaurar processed, capturedo partial_captured. Conserve el pago exitoso y el intento de devolución fallido por separado. Consulte MPR: Reembolsos parciales múltiples para los modos nativos y agregados de DEUNA, límites de tiempo, concurrencia y comportamiento del saldo restante.
Lista de verificación de integración#
- Mantenga el cumplimiento bloqueado para
pending,pending_3ds,processing,authorizingymanual_review. - Consider la autenticación y la aceptación de la solicitud como evidencia intermedia, no como confirmación financiera.
- Almacene los montos confirmados e identificadores de operación con cada actualización de estado.
- Recupere el pago autorizado después de un tiempo de espera o una respuesta tardía del proveedor.
- Usa la referencia de transición validada cuando se manejan los reintentos o las rutas de conciliación que no se muestran en el flujo normal.