SCA successful, payment still pending: what to check
Successful authentication does not prove that a payment settled. If a customer returns from their bank but the payment is still pending, preserve the original payment reference, check its status with the provider, and establish whether the result is known before creating another payment.
Scope: A provider-neutral investigation guide for developers, support and payment operations. Status names and finality differ by provider and destination. The timeline below is synthetic, not a ZILLQ incident report.
Start with these checks
- Find the original attempt.Collect the internal order ID, provider payment ID, idempotency key or equivalent deduplication reference, amount, currency and intended recipient. Check whether more than one payment was created.
- Read the authoritative status.Use your backend’s authenticated provider status API or a verified provider event. A success URL, browser query parameter or HTTP 200 on a page is not payment evidence.
- Read that provider’s status definition.“Accepted,” “executed” and “settled” may describe different points. Some integrations cannot observe settlement into an external account.
- Check event processing.Inspect signature validation, delivery attempts, response codes, deduplication and event order. Compare event timestamps with when your service received and processed them.
- Resolve uncertainty before a new attempt.A network timeout can happen after the provider accepted the request. Follow its retrieval and retry contract; do not replace an unknown result with a fresh payment and hope the first failed.
What different signals establish
| Observed signal | What to establish next |
|---|---|
| Customer returned from bank | Was authentication completed, abandoned or interrupted? Retrieve the original payment. |
| Authentication completed | Was the payment submitted and accepted? Follow its payment status. |
| Payment accepted / processing | What transitions remain possible, and which evidence can this integration observe? |
| No webhook received | Is the provider still processing, or did delivery or your event handling fail? Query status as the contract permits. |
| Confirmed failure | Read the failure reason and retry rules. Preserve the failed attempt if a new one is authorized. |
| Confirmed settlement / credit | Reconcile it to the expected order, amount, currency and recipient before fulfilment. |
A concrete example of why vocabulary matters: TrueLayer’s payment status documentation distinguishes authorized, executed and settled. In its documented model, executed is terminal for payments into an external account but does not establish credit to that account. settled is available for payments into its merchant account. These are TrueLayer definitions, not universal SEPA status codes.
Its webhook reference also separates authorization, execution and settlement events. Build your status mapping against the actual provider contract and destination, rather than translating every successful event to “paid.”
An example timeline with a missing callback
| Time | Observation | Safe next action |
|---|---|---|
| 10:00:00 | Payment created; provider reference recorded. | Show the current step and keep the same attempt ID. |
| 10:00:18 | User completes the bank journey and returns. | Retrieve payment status; do not infer settlement from the redirect. |
| 10:00:19 | Provider reports processing. | Show “Payment processing.” Avoid a second pay button for the same unresolved attempt. |
| 10:00:23 | Provider event delivery fails. | Investigate callback handling; continue the provider’s supported status-retrieval path. |
| 10:01:00 | Backend retrieves a confirmed outcome. | Apply the documented state transition and reconcile once; process a later duplicate event safely. |
The times explain ordering, not a settlement SLA. An instant-payment scheme’s time requirements and an application’s delayed notification are different questions. See the EPC’s SCT Inst overview for the scheme context.
Protect against duplicates and premature refunds
Scope deduplication to the right customer and logical payment. When retrying the same operation, reuse the provider’s required idempotency mechanism within its documented retention window. A changed amount or recipient must not silently reuse an old approval. If the provider does not support a safe automatic retry for an uncertain request, reconcile or escalate it.
Make event handling safe to repeat. A duplicate notification should not fulfil an order twice or consume a mandate budget twice. An older event should not overwrite a newer confirmed state; respect allowed transitions rather than sorting labels alphabetically or trusting arrival order.
Pending does not mean refundable. Cancellation of an in-flight payment, a refund after completion and revocation of future agent authority are different operations. Check which is supported at the recorded state. Revoking an agent mandate does not reverse an already accepted payment.
These are recommended engineering controls. Use the retry and concurrency test cases to make your expected behavior explicit.
To watch a lost response, a retry and repeated or delayed notifications play out, open the payment retry simulator. It keeps the provider’s state separate from what the application has actually observed.
A useful support and engineering handoff
Record the order and attempt references; provider reference; expected amount, currency and recipient; most recent provider status and retrieval time; callback IDs and validation outcome; retry history; and the next reconciliation action. Keep credentials, raw access tokens and unnecessary customer data out of the ticket.
Suggested customer wording while unresolved: “Your bank step is complete. We are confirming the payment result. Please keep reference [reference] and avoid starting another payment for this order while we check.” Only show this when you have evidence the bank step completed.
Assign a review time based on the provider’s documented behavior and your operations policy. An indefinite spinner gives neither the customer nor the team a next step. For the earlier authority checks, see consent, SCA and agent mandates; for terminology, use the reconciliation glossary entry.
Testing a new integration? The payment API checklist connects this investigation to consent, recipient checks and account evidence.
Put the questions to a sandbox.
ZILLQ is an independent European payments sandbox with synthetic accounts and funds, agent mandate mechanisms, OAuth2/OpenID Connect authentication and EUDI wallet emulation. Use these references to frame your investigation; they do not certify that every control described here is implemented.
See the platform and its boundaries → · Open the synthetic sandbox →