Use a request ID to investigate a paid API failure
Guides
Keep the request ID beside the purchase reference, route and settlement evidence so support can trace one operation without asking for wallet secrets.
A request ID is a correlation label for one server operation. It helps an operator find the matching gateway, payment, execution and delivery records. It is not a payment authorization, a transaction receipt or proof that the result reached the buyer.
Save the request ID as soon as the server returns it. Keep it beside the exact route, HTTP method, approximate time, purchase reference and any payment response or transaction reference. These fields let support narrow the search without guessing from an amount alone.
Preserve the original logical request separately, but do not send sensitive input by default. A domain, keyword or report target may itself be confidential. Start with identifiers and timing; provide request content only through an approved support channel when it is necessary for reconciliation.
Never send a private key, seed phrase or a fresh payment signature to prove ownership. A support team should be able to investigate from the server-side reference and existing settlement evidence. If additional wallet proof is required, use only the documented challenge flow for that service.
Reusing a request ID does not make a new payment safe. After an ambiguous response, first determine whether the original payment settled and whether a result was stored. Keep the purchase unresolved until those records agree; do not create another authorization merely because the response was lost.
A useful support reply states what is confirmed and what remains unknown: payment observed, execution attempted, result stored, response delivered or still unresolved. This prevents a technical identifier from being presented as evidence for a stage it cannot prove.