Eventos

Paymos publica 16 tipos de evento: 8 de facturas, 5 de retiros y 3 de canales de pago. La suscripción se hace por categoría en el endpoint; los nombres de evento dentro de una categoría no se pueden seleccionar por separado.

Eventos de factura

Evento	Significado	Final
invoice.awaiting_payment	Una reorganización profunda eliminó todas las transferencias contabilizadas y la factura retrocedió a la espera de pago. La transición inicial a ese estado no emite este evento	No
invoice.confirming	Se ha detectado un pago y espera la finalidad requerida en la blockchain	No
invoice.underpaid_waiting	El importe recibido es inferior al esperado y la factura todavía puede aceptar pagos	No
invoice.paid	Se pagó el importe esperado	Sí
invoice.paid_over	Se pagó más del importe esperado; se abona íntegro el importe recibido	Sí
invoice.underpaid	La factura alcanzó un estado final de pago insuficiente	Sí
invoice.expired	La factura venció sin un pago válido	Sí
invoice.cancelled	El comercio canceló la factura	Sí

Eventos de retiro

Evento	Significado	Final
withdrawal.created	El retiro se aceptó y se creó	No
withdrawal.processing	La transacción saliente se observó en cadena y su hash está disponible	No
withdrawal.completed	La transacción saliente se completó en cadena	Sí
withdrawal.failed	El retiro falló y alcanzó un estado final	Sí
withdrawal.cancelled	El retiro se canceló antes de completarse	Sí

Eventos de canal de pago

Evento	Significado	Final
payment_channel.deposit.confirming	Llegó una transferencia a una dirección del canal y espera la finalidad requerida en la blockchain	No
payment_channel.deposit.reorged	Una reorganización de la cadena tumbó la transacción. Si vuelve a entrar en un bloque, el mismo depósito regresa a confirming	No
payment_channel.deposit.confirmed	El depósito quedó liquidado y su importe neto se abona a tu saldo	Sí

No hay evento de fallo: cuando la transacción no vuelve a ningún bloque, el depósito se queda en reorged y no llega ningún evento más.

Reglas de procesamiento

• Enruta por el event_type exacto; ignora sin riesgo los tipos futuros desconocidos y avisa para revisarlos.
• Lee data.status y data.is_final del contenido en lugar de reconstruir el estado a partir del nombre del evento.
• No des por hecho un orden de entrega. La entrega en paralelo y los reintentos pueden hacer que llegue antes una instantánea más reciente del recurso.
• Un evento final es definitivo para la máquina de estados de ese recurso. Recibir de nuevo el mismo event_id sigue siendo un duplicado, no otra transición.
• Descarta los duplicados de estado de negocio por el id del recurso dentro de data (inv_…, wdr_…, pcd_…), que es el mismo en cada transición y en cada endpoint. event_id identifica una entrega, no un pago.

Consulta el contrato del contenido para el sobre común y los campos del recurso.