El estado del pago y el del pedido se relacionan, pero no son el mismo registro
La pasarela comunica lo sucedido al pago; tu aplicación decide qué hacer con el pedido. Nunca entregues a partir de un webhook sin verificar, ni retrocedas un pedido tras un evento posterior, ni trates un importe excepcional como pagado sin una política explícita.
No se envían solicitudes, webhooks, transferencias, reembolsos ni cambios de pedidos a OxaPay. Los datos permanecen en el navegador; la respuesta real de API es la referencia.
Muestra transiciones probables y acciones comerciales; no crea pagos, no llama a la API, no verifica transacciones reales ni sustituye Payment Information.
Cómo utilizar el simulador de estados de pago
Este simulador ayuda a comercios y desarrolladores a entender cómo afecta un evento de pago a un pedido. Elige un escenario o ajusta importe, vencimiento, confirmaciones, modalidad de pago y webhooks. Es un modelo educativo: no comprueba transacciones reales ni se conecta a OxaPay.
Estado de pago y estado del pedido no son lo mismo
La pasarela informa del pago; el comercio decide por separado si mantiene el pedido pendiente, lo entrega o lo revisa. Detectar una transferencia no equivale a aceptar el pago. La entrega irreversible requiere un estado final verificado y autorizado. Los webhooks repetidos o fuera de orden nunca deben duplicar la entrega.
Importes insuficientes y plazos
El déficit aceptable se calcula con el importe solicitado y la tolerancia configurada. Un pago demasiado bajo, una transferencia tardía o una modalidad incompatible exige una política comercial, no entrega automática. Los depósitos a direcciones fijas requieren asociar cliente y transacción. Cero confirmaciones no sustituye el estado final comunicado por la pasarela.
Webhooks y recuperación
Los casos incluyen duplicados, HMAC inválido, eventos desordenados, primer intento fallido y reintentos agotados. Verifica la firma sobre el cuerpo original, identifica el pedido, procesa los cambios de forma idempotente y consulta Payment Information o Payment History cuando existan discrepancias. El JSON del ejemplo no es una respuesta de API real.
Límites de la simulación
Pedidos, hashes, horas y cargas útiles son ficticios. Los estados, límites y reintentos de OxaPay pueden cambiar; consulta la documentación vigente antes de programar sistemas reales. El simulador no envía fondos, reembolsos, webhooks ni credenciales.
Estados documentados de OxaPay
El déficit aceptable se calcula con el importe solicitado y la tolerancia configurada. Un pago demasiado bajo, una transferencia tardía o una modalidad incompatible exige una política comercial, no entrega automática. Los depósitos a direcciones fijas requieren asociar cliente y transacción. Cero confirmaciones no sustituye el estado final comunicado por la pasarela.
new- Factura creada; falta elegir la moneda de pago.
waiting- Moneda elegida; a la espera del pago.
paying- Se procesa un intento de pago o una transacción.
paid- La factura está totalmente pagada.
manual_accept- El comercio aceptó manualmente la factura.
underpaid- El pago parcial no satisface la factura.
refunding- Se inició un reembolso.
refunded- El pago se ha reembolsado.
expired- La factura venció sin un pago aceptado.
Documentación vigente de OxaPay
Consulta estados de pago, parámetros de factura, búsqueda de pagos y webhooks.