Events and retries
Payment payloads and delivery semantics.
Event payload
Illustrative identifiers; the actual event ID is generated by the gateway. Webhook bodies are sent directly and do not use the API response envelope.
{
"id": "evt-example-001",
"event": "PAYMENT_SUCCESS",
"environment": "TEST",
"transactionId": "TXN-EXAMPLE",
"data": {
"transactionId": "TXN-EXAMPLE",
"referenceId": "INV-EXAMPLE",
"orderId": "order-20261110-0001",
"environment": "TEST",
"status": "SUCCESS",
"amount": "10000",
"currency": "LAK",
"paymentMethod": "LDB_QR",
"paidAt": "2026-11-10T05:00:00.000Z",
"metadata": {}
}
}Events are named PAYMENT_ followed by the new transaction status. Handle PAYMENT_SUCCESS, PAYMENT_FAILED, PAYMENT_EXPIRED, PAYMENT_CANCELLED, and PAYMENT_AMOUNT_MISMATCH. The portal simulator supports success, failed, expired, and cancelled; it does not offer amount mismatch. paidAt can be null; orderId and referenceId can be null; amount is a decimal string.
Delivery and acknowledgement
The signed outbox attempts delivery at most 10 times. Each HTTP attempt times out after 20 seconds. Non-2xx responses, redirects, network failures, or an unavailable/disabled destination count as failures. Respond promptly after durable acceptance and process fulfillment asynchronously.
Failed attempts schedule exponential delays starting at 2 seconds, capped at one hour; the worker scans approximately every 5 seconds, so these are not exact delivery times. Retries reuse the same event ID and payload but refresh the timestamp and signature. Delivery may repeat if the response or acknowledgement is lost. Do not assume ordering or exactly-once delivery.
After exhaustion, automatic delivery stops. Keep your own event logs, check Transactions, and contact the gateway operator for reconciliation. There is no merchant self-service redelivery route documented here. Disabled destinations are not a reliable way to pause events indefinitely.