Recursos · 47
Pagos inciertos: recuperar checkout sin pedidos duplicados
Concilie retrasos en la red, devoluciones del navegador, notificaciones y estado del negocio en lugar de tratar cualquier señal como suficiente.
Actualizado · 3 min
Lo que esta guía ayuda a lograr
- Separar intento, pago y pedido
- Manejar devoluciones retrasadas o faltantes
- Deduplicar notificaciones y solicitudes
- Explicar la incertidumbre sin volver a pedir a los usuarios que paguen
Comprobación rápida
- ¿Qué fuente confirma el pago?
- ¿Cerrar el navegador cambia el estado del negocio?
- ¿Un evento repetido prepara dos órdenes?
- ¿Se verifican las firmas de eventos?
- ¿Cómo encuentra soporte una operación incierta?
Método paso a paso
- 1
Definir los estados
Carrito separado, intento, autorización, pago confirmado, pedido y reembolso. Escribir transiciones, fuente autorizada y acciones permitidas. Siga el proveedor y los métodos de pago reales; No todos los métodos confirman inmediatamente.
Entregable: diagrama de estado y contrato comercial.
- 2
Identificar la operación
Conectar un intento a un pedido e identificadores de proveedor. Utilice la regla de idempotencia documentada para la repetición de la misma operación. Un nuevo propósito o parámetros modificados necesitan una decisión explícita en lugar de una reutilización de claves ciegas.
Entregable: identidad estable y reglas de recuperación.
- 3
Manejar el retorno del navegador
Muestra el estado desde una comprobación del lado del servidor adecuada al proveedor. Una redirección a una página de éxito por sí sola no es prueba de pago. Cubre un navegador cerrado, falta de retorno, autenticación interrumpida y red lenta.
Entregable: viaje de regreso y mensajes por estado.
- 4
Verificar notificaciones
Verificar la autenticidad según la documentación del proveedor, registrar la identidad del evento y manejar las repeticiones sin efectos duplicados. Los eventos pueden llegar tarde o fuera de orden. Cuando sea necesario, recupere el objeto de referencia antes de una transición irreversible.
Entregable: handler testado y trazas libres de datos bancarios.
- 5
Conciliar discrepancias
Comparar operaciones, pedidos y cumplimiento de proveedores. Aislar pagos sin pedido, pedidos sin confirmación, doble procesamiento y reembolsos no propagados. Dar a cada discrepancia un propietario y procedimiento; no repita automáticamente un cargo incierto.
Entregable: cola de conciliación y decisiones.
- 6
Prueba de recuperación completa
En modo de prueba del proveedor, tiempo de espera de reproducción, duplicado, evento retrasado, orden invertido y devolución faltante. Verifique una transición comercial, corrija la información del cliente y soporte la visibilidad. Los detalles de idempotencia difieren entre proveedores.
Entregable: evidencia de no duplicación y criterios de implementación.
Ejemplo trabajado ficticio
Situación ilustrativa
Situación ilustrativa: el pago se realiza correctamente, pero el cliente pierde la conexión antes de la confirmación y llegan dos notificaciones después.
Decisión y pruebas esperadas
Un pedido está confirmado. La recuperación muestra el estado verificado y el soporte puede conciliar la referencia sin solicitar datos bancarios.
Distinguir los mecanismos
| Mecanismo | Propósito | Verificación o limitación |
|---|---|---|
| Retorno del navegador | Informar y reanudar la interfaz | Puede faltar o estar interrumpido |
| Webhook verificado | Recibir un cambio de estado de proveedor | Puede repetirse, retrasarse o estar fuera de servicio |
| Conciliación de servidores | Comparar estado de pago y pedido | Necesita una regla de resolución de discrepancias |
Indicadores de gestión
| Indicador | Qué mide | Primera acción |
|---|---|---|
| Estados inciertos | Operaciones no resueltas dentro del retraso previsto | Comprobar el estado de referencia |
| Efectos duplicados | Órdenes o procesamiento realizados dos veces | Arreglar la deduplicación empresarial |
| Brechas cerradas | Casos conciliados con decisión y prueba | Manejar casos más antiguos y críticos |
Errores comunes
- Confirmar solo desde una URL de éxito
- Tratar el tiempo de espera como fallo de pago
- Suponiendo que los eventos lleguen en orden
- Repetir un cargo antes de comprobar
Preguntas frecuentes
¿Un tiempo de espera significa fallo?
No. Significa que no se recibió la respuesta dentro del plazo. Verifique el estado de la operación antes de crear otra.
¿Es suficiente la idempotencia del proveedor?
No. La creación, el cumplimiento y las notificaciones de pedidos también deben tolerar el procesamiento repetido sin efectos comerciales duplicados.
¿Qué se le debe decir al usuario?
Explique que la verificación está en curso, proporcione una referencia segura y una forma de recuperar el estado. Evite solicitar otro pago mientras el anterior sea incierto.
Referencias oficiales
Las referencias respaldan el método. Adapte los controles a su contexto; no constituyen certificación. Los títulos de referencia originales y los documentos fuente pueden estar en otro idioma.
