Authorisation is not conversion
A gateway can return an approved authorisation while the app never records a completed order. The gap usually lives in capture timing, not in the decline table.
When a payment-enabled app reports conversion, someone in the room usually means “the gateway said yes.” That yes is often an authorisation. Authorisation is the issuer agreeing that the card or the account may be charged. It is not the charge. Capture may happen in the same message, or minutes later, or not at all if the shopper never returned from a challenge.
We keep seeing checkout_success attached to the authorisation callback because it is the first cheerful message in the log. Finance then receives a settlement file with fewer lines. The missing lines are not mysteries: they are captures that never ran, captures that ran after a refund, or authorisations that expired. Marketing and finance are both telling the truth about different hops.
A practical test: pick seven days. Join in-app orders to settlement on a key that is not the shopper’s email. Count how many authorised events lack a capture. That gap is the first paragraph of an audit, and it is usually enough to retire the habit of treating an approval code as a completed purchase.
If you need the rest of the map — challenge hops, retries, wallet clocks — that is what the gateway conversion audit is for. The point of this note is narrower: stop naming authorisation as conversion in the event dictionary, even if the gateway’s example code does so.