Payment Flows - Guide to Payment Statuses, Timings & Troubleshooting
Last updated: June 12, 2026
This guide explains exactly how Ivy's payment flows work, covering payment statuses, settlement timelines, refund logic, unmatched deposits, common failure reasons, and how to use available tooling like the dashboard and webhooks to get full visibility.
1. Payment Lifecycle Overview
Key Stages:
Processing – A checkout session has been created and the customer is viewing the payment interface (selecting their bank, etc.), but they have not yet authorized the payment in their banking app. No action was taken in their bank. If the customer abandons the session without authorizing, the payment will remain in Processing until the session expires (default: 1 hour), then move to Canceled status.
Authorized – The customer confirmed the payment in their banking app. Ivy received the confirmation payload, and we’ve instructed the sending bank to execute the transfer. Funds are not yet received. Note: There is no intermediate status notification between Authorized and Finalizing - Ivy cannot track when funds are debited from the customer's account, as settlement timing is controlled by the sending bank.
Finalizing – Funds have been received and settled in Ivy's account and are undergoing final verification before release. Typically completes within minutes; may take up to 48h if flagged for compliance checks.
Paid – Payment is fully received and settled.
Canceled – Order expired before funds were received. No money will arrive or it will be refunded automatically.
Failed – Payment did not arrive in time (6 days for standard modes, 24h for instant_only). Auto-refund triggered if funds arrive late.
2. Understanding Payment Schemes
Scheme | Processing Time | Notes |
SEPA Instant | Within seconds (24/7) | Fastest and preferred; may be delayed by sending bank screening |
SEPA Credit | 1–3 business days | Standard scheme; not processed on weekends |
Faster Payments (FPS) (UK) | Within seconds (24/7) | Instant for GBP UK payments |
Once a payment is Authorized, it has been confirmed by the customer in their banking app. The final settlement depends on the sending bank.
Scheme Selection Configuration
Merchants can configure the type of payment scheme they prefer to offer to users:
instant_only – Accept only SEPA Instant or equivalent schemes. Transactions fail if an instant scheme is not available.
standard – Accept any available scheme (Instant or Credit). The system does not prioritize Instant.
instant_preferred – Attempt SEPA Instant first. If unavailable, fall back to standard SEPA Credit.
The instant_only setting filters out banks that only support SEPA Credit, which may reduce the number of available banks for customers in certain regions and can impact conversion rates where instant‑payment adoption is still developing.
To maintain fast settlement while maximizing bank availability, consider using instant_preferred; it attempts an instant payment first but gracefully falls back to standard schemes when instant options aren’t available.
This setting directly impacts the user’s experience and settlement expectations. Choose the mode based on your use case and user preferences.
3. Common Questions
Why is the transaction stuck in "Authorized"?
It has been accepted by the user, but not yet executed by their sending bank.
Possible causes: SEPA Credit delays, sending bank screening, or weekend cutoffs.
If SEPA Credit: allow 3 business days.
If SEPA Instant: should settle within minutes unless held by the bank.
Why is the payment in "Processing"?
Customer opened a checkout session but did not authorize the payment in their banking app, or abandoned the session before completing bank selection.
Causes: abandonment, trust issues, redirect problems, bank downtime.
Use webhook failure reasons to understand what happened.
Why did the payment land in "Unmatched Deposits"?
Reference or amount may have been incorrect.
A payment has been received after the original order was moved into a terminal status (i.e. canceled or failed).
For a manual bank transfer fallback, the user completed the payment, but the order expired before matching (e.g. they didn’t press "Done").
Funds are automatically returned to the user. This is the default setting with Ivy but please contact us if you would like to handle returns yourself.
Why was this Returned?
The order already had a terminal status and money arrived late; or payment details were incorrect.
Return was initiated by merchant manually or via auto-return logic.
Where can I find this payment?
Use the Ivy Dashboard to search by Order ID, reference, amount, or sender IBAN.
Filter by status (Processing, Authorized, Paid, etc.).
Click into the payment record to view the timeline of the payment journey.
To check the payment scheme type for a specific transaction (which explains its processing time): click into the transaction and view the Payment Scheme field
4. Checkout Expiry & Session Rules
Checkout sessions expire after a fixed time (configurable per merchant integration) - default is one hour.
Once expired, the order cannot be matched if it were to still arrive.
When initiating a manual bank transfer fallback users must press "Done" to keep the session active.
You can adjust your order expiration time to fit your use case. For example, shorten it to ensure payments only occur in active sessions, or extend it to accommodate slower schemes like SEPA Credit. API docs.
5. Webhooks & Failure Reasons
Webhooks provide real-time updates on payment status changes.
Use failure reason codes to diagnose user drop-off or technical issues.
Example reasons:
cancelled_by_user,bank_unavailable,invalid_referenceImportant: If you see a
timeoutfailure with the underlying codeINITIATION_PENDING_REDIRECT_AUTH, this does NOT indicate a bank timeout. Instead, it means the customer was successfully redirected to their bank for Strong Customer Authentication (SCA) but never completed the authorization or returned to finish the transaction. The system waits approximately 1 hour (typically 3600-3920 seconds) before marking it as a timeout. This indicates customer drop-off during authentication, not a technical issue.
6. Summary: How to Troubleshoot
Issue | Likely Cause | Action |
Stuck in Authorized | Bank delay or SEPA Credit scheme | Wait (up to 3 days), ask user to check with their bank |
Still in Processing | User didn’t authorize the payment | Check webhook for failure reason; if |
Returned | Order expired, late arrival or manual refund | Confirm session and refund triggers |
Unmatched Deposit | Expired session, incorrect reference or amount | Resend order, confirm auto-return setting |
Can't find payment | Dashboard filter issue | Search by sender IBAN, reference, or use webhook events |
Can't find payment | Dashboard filter issue | Search by sender IBAN, reference, or use webhook events. To check payment scheme: Navigate to Payments → Payins tab → click the transaction → view Payment Scheme field |
For further technical details, see Ivy Docs → Payin → Failure Reasons.