Aglet

How to investigate a payment failed but charged case

Investigate one payment attempt across request creation, timeout handling, payment status, order persistence, and the retry path. Compare identifiers and timestamps without exposing credentials. Possible causes include a lost response, delayed state update, missing idempotency link, or UI recovery branch; establish which records support each possibility.

Build a useful investigation brief

  1. Trace attempt identity

    Map the checkout submission to its payment attempt, idempotency key, order candidate, and displayed result. Verify whether a refresh or retry reuses or creates an identifier. Record missing links explicitly, because an absent correlation is itself a recovery risk.

  2. Reconstruct timing

    Place request start, timeout, provider response if available, order write, and UI update on one timeline. Compare a confirmed success and controlled timeout. A late success after the UI error may explain duplicate retries, but treat it as a hypothesis until timestamps agree.

  3. Follow recovery state

    Test refresh, return to checkout, status lookup, and second submission with safe fixtures. Compare what the shopper can do with the order and payment records. Confirm whether the system can distinguish unpaid, pending, paid-without-order, and duplicate-order states.

What to carry forward

The investigation is ready when one attempt can be replayed as a timeline with correlated identifiers and the retry decision follows from records. Deliver unknown status transitions and missing correlations alongside the reproducible path; do not conclude from the UI message alone.

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