Skip to main content
Unmatched bank payin webhooks notify your system about incoming bank transfers that reached one of your pooled receiving accounts but could not be automatically attributed to any payin order — and about how they are eventually resolved. These events allow you to:
  • Detect held funds that require manual attention as soon as they arrive
  • Drive your own back-office flow for assigning or rejecting the payin
  • Link the resolution to the resulting payin order when funds are credited
  • Keep your reconciliation records in sync with the final outcome

​
Unmatched Bank Payin Lifecycle

An unmatched bank payin follows this state flow:

​
State Definitions

​
Available Events

​
Unmatched Reasons

The data.reason field explains why the automatic matching failed:

​
Payload Fields

All three events share the same data structure:
  • id — Numeric identifier of the unmatched bank payin. Use it with the unmatched bank payin endpoints.
  • state — Current state: PENDING, ASSIGNED or REJECTED
  • reason — Why the transfer could not be matched (see table above)
  • amount / currency — Transferred amount in minor units, and its currency
  • concept, senderName, senderAccount, rail — Details of the incoming transfer, when available
  • accountId — Account the payin was attributed to. Only on unmatched_bank_payin_assigned.
  • orderId — The regular payin order created by the resolution. Only on unmatched_bank_payin_assigned.
  • rejectReason — Free-text reason provided at rejection. Only on unmatched_bank_payin_rejected.
  • resolvedAt — ISO 8601 timestamp of the resolution. Present on assigned and rejected events.
When a payin is assigned, the funds are credited through the standard payin flow — you also receive the regular payin events for the resulting order. Use orderId to correlate both.