Payment Pending, Failed, or Returned: What the Status Means and When to Retry
Understand the difference between a payment obligation and an individual attempt, why a return page is not settlement, and how to retry without paying twice.

A payment can involve a redirect, a provider checkout, a webhook, and a later status inquiry. The browser is only one participant. That is why the screen you return to is not, by itself, proof that money settled or that an order is ready for fulfillment.
Two basic records: intent and attempt
A collection intent is the business obligation: the amount and currency that must be collected for an order, top-up, or customization payment. A payment attempt is one try to fulfill that obligation through a provider.
One intent can have more than one attempt over time. For example, a hosted checkout can expire before payment, after which a new attempt is created. The attempts remain separate so the system can reconcile late provider messages safely.
Pending means wait for an authoritative outcome
A pending state means the provider journey has started but no terminal result is confirmed yet. The customer may still be completing authentication, a local method may settle asynchronously, or Labelix may be waiting for a signed provider observation.
Do not assume pending means failed. Refresh or use the available sync action before creating a new payment journey.

Failed means that attempt cannot complete as submitted
A failed attempt does not automatically cancel the underlying order or obligation. It means that particular try reached a failure outcome. You may be able to select an available method again and create a fresh attempt.
Read the customer-facing message. Correct actionable issues such as an expired session or rejected input. Operational provider details are intentionally not exposed when they would reveal internal account or risk information.
Returned means the browser came back
A provider return page tells Labelix to check or display the current state. It does not create the truth. Payment settlement is accepted only after provider evidence passes identity, currency, amount, and business checks.
Closing the tab before the return page also does not necessarily cancel the remote payment. Signed webhooks and reconciliation can still settle a valid attempt.
Why retries do not overwrite old attempts
A retry gets a new immutable attempt identity. The old attempt remains available for reconciliation in case a delayed provider event arrives. This prevents one response from being mistaken for another and helps ensure only one successful settlement grants the business effect.
Safe retry sequence
- Open the business payment page from the order, top-up, or draft.
- Check the current aggregate status.
- If an attempt is pending, wait or sync rather than opening another checkout.
- If it is failed or expired and the page offers methods again, select one and continue.
- After returning, verify the local payment and business status before retrying.
When to contact support
Contact support when your bank or provider shows a completed charge but Labelix remains unpaid after a reasonable reconciliation window, when two completed charges appear for one obligation, or when the page cannot resume an available payment path. Include the order/request reference and provider transaction time, but never send full card credentials.
Treat the status on the Labelix payment or order page as the current business record, and allow provider reconciliation to finish before repeating a charge.
Frequently asked questions
- Does reaching the provider return page prove my payment succeeded?
- No. It proves the browser returned. Labelix settles only after authoritative provider evidence passes identity, amount, currency, and business validation.
- Should I retry immediately when a payment is pending?
- No. Pending is not failure. Wait or use the available status sync first, because asynchronous methods and delayed provider confirmation can still complete the active attempt.
- Why does a retry create a new payment attempt?
- Each try needs an immutable identity so late provider messages can be matched safely. The old attempt remains reconcilable, while only one valid successful settlement grants the order or wallet effect.