Balakong · payment-enabled apps
The gateway returned a code. Conversion is whether money actually moved.
Gateway Pulse Hub sits with one live app at a time and maps authorisation, 3-D Secure, capture, and settlement against the events your checkout already fires. We do not sell a dashboard. We write a findings pack you can argue with.
Flagship work
A gateway conversion audit for one production app
Most teams we meet already have an event named checkout_success. It often fires on authorisation, sometimes on the thank-you screen, occasionally on a webhook that arrived twice. The audit treats that event as a claim and tests it against the gateway’s own states and a sample settlement file.
The engagement covers the payment methods you actually offer in Malaysia and nearby markets — cards with 3-D Secure, FPX, DuitNow, and the e-wallets already live — not a catalogue of methods you might add later. You leave with a written map, a list of leaks named in gateway language, and a working session in Balakong or over video.
Where conversion usually breaks
Four places a payment-enabled app loses the trail
These are not product modules. They are the rooms we walk through when a weekly conversion number and a Friday settlement refuse to agree.
-
Authorisation treated as done
The issuer said yes. Capture never ran, or ran after the shopper left. The app counted a sale the settlement file later omitted.
-
A 3-D Secure hop with no return event
The shopper opened a bank app, waited, and came back on a different connection. The checkout only listened for an immediate success callback.
-
FPX and wallet timeouts labelled as quits
The bank clock expired. The app recorded abandonment. Finance saw a decline. Nobody had a timeout state to reconcile.
-
Webhooks joined on a weak key
Retries duplicated a purchase event, or a late webhook created a ghost order after the receipt screen had already closed.
Related work
Other engagements we take when the audit is not the first need
Hands-on setup
Payment funnel instrumentation
We sit with your checkout and name the events that should fire on card, FPX, and e-wallet paths so a drop-off can be blamed on a real gateway step.
Live leak investigation
Drop-off diagnosis
When conversion slipped after a gateway change, we reconstruct the week from logs, webhooks, and a settlement sample rather than guessing at a percentage.
Before a new method ships
Launch-week tracking review
A pre-release check that conversion events survive the store-review build, fire on the new method, and still agree with the first settlement file.
“The audit showed our ‘successful checkout’ event firing on authorisation, two steps before capture. We had been celebrating a number that the settlement file quietly contradicted every Friday.”
Journal
Notes from conversion tracking work
-
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.
-
What a 3-D Secure challenge does to a Malaysia-facing checkout
Challenge windows, issuer apps, and a shopper returning on a different network all look like abandonment if the app only listens for a success callback.
-
Matching gateway webhooks to in-app purchase events
If the webhook arrives after the shopper has left the receipt screen, your funnel will count a ghost. We walk through a practical join key that survives retries.
Bring the app name and the gateways already live
Write from the contact page with the payment methods you offer and a week when conversion and settlement disagreed. We reply within two working days and will say plainly whether an audit, a diagnosis, or a launch-week review is the right first step.