Payment Statuses & FAQ
What every payment status means, which are final, per-rail success codes, and answers to common questions.
Payment Statuses & FAQ
A payment moves through ISO 20022 statuses as it's approved and settled at
the bank. This page is the reference for what each status means; see
Payment Status for how to read it, and Payment Webhooks to be notified
of changes.
Status reference
| Status | Meaning | Rail | Set by | Class |
|---|---|---|---|---|
INIT | Payment created, not yet completed by the user. | — | Financy | Initial |
RCVD | Received by the receiving bank. | All | Bank | Pending |
ACTC | Authentication and validation succeeded. | Masav | Bank | Pending |
ACWC | Accepted, but a change will be made. | Masav | Bank | Pending |
ACSP | Preceding checks passed; accepted for execution. | FP, Masav | Bank | Pending |
ACFC | Automatic funds check was positive. | Masav | Bank | Pending |
PATC | Needs multiple authentications; not all performed yet. | All | Bank | Pending |
PENDING | Still RCVD after finalize; awaiting additional authorizations. | All | Financy | Pending |
ACSC | Settled on the debtor's account. | FP, Masav | Bank | ✅ Success (final) |
ACCC | Settled on the creditor's account. | Zahav | Bank | ✅ Success (final) |
RJCT | Rejected by the bank. | All | Bank | ❌ Failure (final) |
CANC | Cancelled (scheduled/recurring payments only). | — | Bank | ❌ Failure (final) |
ERROR | A failure occurred in the process (see the payment's error). | — | Financy | ❌ Failure (final) |
Which status means "success" depends on the rail
The settled/success code differs by the payment's service (rail):
Rail (service) | Success code(s) |
|---|---|
masav | ACTC / ACWC / ACSP |
fp | ACSC |
zahav | ACCC |
Final vs. transient
- Final (stop polling):
ACCC,ACSC,RJCT,ERROR,CANC. - Transient (keep polling / wait for a webhook):
INIT,RCVD,ACSP,
ACTC,ACWC,ACFC,PATC,PENDING.
Rule of thumb: treat the rail's success code (orACSC/ACCC) as done-OK,and
RJCT/CANC/ERRORas done-failed. Everything else means "still in
progress."
FAQ
When is INIT set?
As soon as the payment (the payUrl / link) is created, before the user has
completed it.
What happens if the user closes the browser mid-payment?
The payment stays pending. If it's never approved it becomes RJCT, typically
within a week, and the user must start a new payment. The user must press
Approve Payment in their banking app for the transfer to complete —
returning to your redirectUrl alone doesn't finalize it.
What causes a RJCT at the end of the flow?
Commonly: a joint-account login that doesn't match the account owner,
insufficient balance, or an exceeded transfer limit. Retrying with a smaller
amount, or having the payer contact their bank, usually resolves it.
What causes an error before the bank screen loads?
Usually a mismatch between the ID on the consent screen and the account holder,
or an invalid amount (e.g. 0). These surface as request errors — see Errors.
Is there a success screen?
The hosted (Financy UI) flow shows a built-in success screen. With a custom
redirectUrl you send the user to your own page instead (Financy appends
paymentId, userId, and paymentStatus — see Initiate a Payment (Direct)).
Should I poll or use webhooks?
Prefer Payment Webhooks so you're pushed the final status; poll (see
Payment Status) only as a fallback.
How do I know a payment truly succeeded?
Match the rail's success code in the table above — don't assume RCVD or
ACSP alone means the money moved.
Updated 7 days ago