American Express reason code A02 means no valid authorization. The merchant should answer it with the actual authorization record for the disputed charge: request, response, approval code if one exists, amount, timing, and the capture that followed. Proof that the customer received goods does not create a valid authorization after the fact.
American Express publishes A02 in its dispute reference materials, but the live merchant portal and current regulations should control the practical response. Reconstruct the authorization path before writing any narrative.
List every authorization attempt
For the order or service, export each authorization attempt with timestamp, amount, status, and transaction reference. Mark which attempt corresponds to the disputed charge. This is essential when an initial attempt failed and a later one succeeded.
Do not let the order's final paid status erase earlier declines. A reviewer needs to see the authorization that specifically supports the presented charge.
Match approval to the captured amount
Compare the approved amount with the capture. If the amount changed, document the adjustment path and any later authorization where applicable. Keep the processor reference beside each event.
If the merchant cannot tie a valid approval to the disputed capture, treat that as a core weakness. Shipping, signature, or customer messages do not solve the authorization gap.
Check expired, reversed, or voided approvals
Review reversals, voids, expired authorizations, and retries. A once-valid approval may not support a later transaction in the way the merchant assumes, and a voided attempt should not be presented as the active authorization.
Use the payment provider's status definitions. Avoid interpreting an internal label such as 'authorized' without confirming whether it remained valid for the transaction that settled.
Keep fulfillment separate from authorization
Commercial evidence can identify the order, but the A02 issue is authorization. Lead the packet with payment-system records and add fulfillment only if it helps map the charge to the order or the live case requests it.
A long statement about the customer's satisfaction or prior purchases can distract from the missing or valid authorization question.
Use a one-page authorization bridge
Show attempted authorization, response, valid approval if any, capture, reversal/void, and final settlement in sequence. Each line should include the processor reference. This exposes mismatches quickly.
Write the cover note from that bridge. State the decisive authorization fact and cite the source record instead of repeating the reason-code definition.
Fix the workflow if A02 is valid
If the merchant captured without a valid authorization, identify whether the cause was terminal behavior, API logic, retry handling, staff action, or a retention gap. Review similar transactions from the same path.
Use current American Express merchant regulations and the live case before filing. A process fix is more valuable than repeatedly contesting unsupported authorizations.
Example: Amex A02 after approval on the wrong payment attempt
An order has two payment attempts. Attempt A is declined; attempt B is approved. Staff accidentally captures attempt A because the commerce platform displays both under one order. A02 analysis should expose that the approval code belongs to B, not the disputed capture.
The case is not repaired by showing that the customer received the goods. The payment integration needs attempt-level capture safeguards.
Distinguish no authorization from an authorization that does not support the final charge
For Amex A02, first determine whether there is no valid approval at all or whether the merchant is pointing to an approval that does not match the challenged charge. Compare authorization reference, timestamp, merchant, amount, currency, transaction type, and final submission. A screenshot showing some approval is not enough if it belongs to a different attempt.
If the transaction retried after a timeout, preserve every attempt rather than only the successful-looking one. Attempt-level reconciliation can reveal a genuine merchant processing defect and prevent the team from contesting the wrong presentment.
Build an Amex authorization bridge from request to final charge
For A02, list every authorization attempt and assign each one a result. Include amount, timestamp, approval or decline, reversal or void, and the transaction reference that later connects to capture. Then identify the exact approval the merchant says supports the disputed charge. An approval on a different amount, different attempt, or earlier transaction should not be presented as though it automatically supports the final settlement.
The amount bridge is critical. If the original approval was for $200 and the final charge was $260, identify any later approval, incremental authorization, or documented adjustment that supports the difference under the merchant's payment flow. If no supporting authorization exists, delivery evidence does not repair the payment defect. Keep the technical issue visible rather than burying it inside a large order packet.
Expired, reversed, and voided approvals need status-level proof. A commerce platform may show 'authorized' even after the processor reversed the hold. Use the payment provider's transaction history and timestamps. If staff retried after a decline or approval expired, show the new attempt separately. This prevents the case from looking like the merchant selected whichever approval code was easiest to find after the dispute arrived.
Use A02 to improve payment-state controls. Prevent capture against unsupported authorization states, make approval-to-capture links immutable, and alert on large amount differences or stale approvals. Log manual overrides with an owner and reason. The dispute team should not need to reverse-engineer basic authorization state from screenshots; the payment system should preserve a clear bridge by design.
Use A02 exceptions to validate gateway-to-commerce state synchronization
A commerce platform may mark an order paid after receiving an asynchronous event even when the authorization state later changes. Compare gateway status with the commerce order state for A02 cases. If the systems disagree, determine which event caused fulfillment to proceed and fix the synchronization rule.
Create an alert when orders move to fulfillment without a payment state that your integration considers capturable. This reduces the operational temptation to force a later payment after goods or services have already been released.
Prevent order fulfillment from using an approval belonging to a prior cart
If customers retry checkout or modify the cart after authorization, make sure the final order references the approval created for that final payment attempt. Reusing an earlier approval tied to a different amount or cart can make the commerce system look paid while the settled transaction lacks a clean authorization bridge. Store authorization-to-order links immutably and invalidate the link when the payment attempt is abandoned or materially changed.
No-valid-authorization cases should be checked for stale approvals and cart changes. A customer may obtain an approval, then change the order amount, add items, alter gratuity, or complete a later transaction that no longer matches the original authorization. Preserve the approved amount, time, transaction reference, and the capture that followed. If the merchant reused an order or payment object, verify that the approval belongs to the final sale rather than to an abandoned cart or prior attempt. Where the business legitimately uses estimated or incremental authorization, show the approved sequence instead of a single screenshot. This audit prevents an application-level “authorized” flag from masking a mismatch between the approval the system remembers and the charge that actually settled.
VERIFY CURRENT RULES
Primary references
Processor interfaces, reason-code mappings, filing windows, and network rules can change. Check the active dispute notice and current official documentation before submitting.