Method
We read a payment path in the order money actually moves
Conversion tracking for a payment-enabled app is not a list of screens. It is a chain: the shopper commits, the issuer or bank answers, a challenge may interrupt, capture may wait, and settlement arrives later as a file. This page is the sequence we use on every audit.
The sequence
Five hops we refuse to collapse into a single success event
-
Intent
The shopper taps pay. We record that as intent, never as conversion. If the app skips this hop, every later decline looks like the shopper never tried.
-
Authorisation
The issuer or the bank path answers. An approval here is permission, not money. Malaysia-facing card traffic often still has a 3-D Secure challenge sitting between this hop and capture.
-
Challenge and bank hops
3-D Secure, FPX bank selection, and e-wallet confirmation each have a clock. We require a timeout state and a return state. A missing return is not automatically a quit.
-
Capture
The amount is claimed. Some gateways capture with authorisation; others wait. If your checkout_success fires before this hop, the settlement file will humble you.
-
Settlement
The acquirer file is the last word we accept for “money moved.” Refunds, delayed presentments, and partial captures live here. We match a sample week, not a marketing total.
What we ask you to bring to the first session
A list of live payment methods, not a wishlist. One week of event logs. A webhook sample covering the same dates. A settlement extract with PAN already truncated. The name of the person who can explain why a retry was sent.
If those pieces cannot be produced, we will recommend waiting rather than inventing a story from a staging build. Staging is useful for walking a challenge hop. It is a poor substitute for Friday’s file.
