Aglet

How to triage an ambiguous payment retry at checkout

An ambiguous payment result is a state problem before it is a retry problem. Triage should record what the shopper saw, what the order and payment records show, and whether a later status arrived. Never infer that a timeout means no charge or that a second attempt is safe without evidence.

Establish what is happening

  1. Capture the attempt

    Record a redacted attempt identifier, order state, displayed message, timestamp, currency, amount, and the last checkout step. Keep secrets out of the report. Note whether the browser was closed, refreshed, or left waiting after the first response.

  2. Compare known outcomes

    Run safe fixtures for an explicit decline, a controlled timeout, a pending state, and a confirmed success. Compare the UI, order creation, payment ledger, and retry control. Keep each state separate so a generic error cannot hide distinct recovery rules.

  3. Mark retry safety

    Identify whether the system can prove no captured payment and no created order before offering a retry. If status is unknown, record the lookup path and owner instead of suggesting repeated submission. Capture delayed updates as a separate observation.

What to carry forward

Triage is complete when the attempt has an evidence-backed state or an explicit unknown state, a clear retry safety condition, and an owner for unresolved payment status. Stop short of calling the shopper's second attempt harmless.

Keep the decision with the work.

Use a Work Item in Aglet to record the problem, the evidence you have, and the next decision. Add an owner and priority, then keep updates in the discussion so the next person can follow the reasoning.

Create an account See the product workflow