Webhook reconciliation

Webhooks provide timely notification but are not a complete reconciliation mechanism. A webhook endpoint can be unavailable beyond the retry window, and your application can fail after acknowledging an event.

Recovery strategy

Run a scheduled process that:

1. retrieves every page of the funding account statement for the UTC posting period, de-duplicating entries by entryId;
2. for entries with relatedResourceType: PAYOUT, retrieves the payout using relatedResourceId as paymentId, even if locally recorded as COMPLETED;
3. also retrieves locally pending or unresolved payouts, including those with no statement movement; and
4. repairs missing or stale records and reconciles settlement debits and related credits separately.

Settlement can post while a payout is still processing. A later return can produce new movements for a previously completed payout, so neither the payout's creation date nor its local status should exclude a statement entry from recovery.

The payout list does not support an updated-time filter. If you need to rebuild local state, paginate through it without assuming a time range. Checkpoint statement cursors or completed UTC date ranges only after every page has been processed, and retain the previous period for replay. The process must be idempotent.

Identifier roles

• Event id de-duplicates a webhook delivery.
• paymentId identifies the Axiym payout across events and reads.
• externalReference joins the payout to your business record.
• accountId identifies the funding account affected by the payment.
• relatedResourceType: PAYOUT identifies payout-related statement entries; their relatedResourceId matches the payout's paymentId.
• Statement entryId de-duplicates ledger movements when replaying pages or periods.

Do not use event arrival as the sole proof that a payout completed. Treat the current payout resource and posted account movements as the reconciliation evidence.

See Reconcile payouts for the full business and ledger workflow.