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.
Gateways retry webhooks. Apps retry purchase events when a receipt screen is slow. If both sides use a weak join key — email, a cart total, a timestamp rounded to the minute — conversion tracking grows ghost orders. We have sat with logs where a single captured payment produced three in-app purchases and one refund confusion the following morning.
A join key that survives retries is usually the gateway’s own payment identifier, stored when intent is recorded, and echoed on every later event including failure. Do not mint a new identifier on the thank-you screen. That screen may never load. The webhook may arrive first. The shopper may screenshot a spinner and leave.
Order of arrival is not order of truth. We treat the webhook as a claim and the settlement line as the later verdict. If your warehouse job “fixes” conversion by inserting events from webhooks without checking whether the in-app event already exists, you will double-count on the quiet days and still miss the timeouts.
Bring a webhook sample covering the same dates as your event log to a session. The first duplicated identifier is more instructive than a slide about architecture.