How add_payment_info works
This is the GA4 event for the payment stage of a checkout. It fires when the shopper submits card details or picks a payment method, and it sends the basket contents, the total and the currency along with one field the other checkout events do not have: the payment type — the name of the method chosen, such as card, bank transfer, a mobile wallet or cash on delivery.
Note what it does not mean. It records that payment details were entered, not that money moved. A shopper can complete this step and still fail at the bank, so this event and the purchase that should follow it are separate records with a real gap between them. Never send it in place of a purchase, and never send card numbers or any personal detail with it.
Why add_payment_info matters
It isolates the last thing that can go wrong. If shoppers reach the payment step and then disappear, the problem is not your prices, your delivery charges or your product pages — they accepted all of those to get this far. It is the payment itself: a method they cannot use, a gateway that fails on mobile, a redirect that loses the session, a bank verification step that times out.
The payment type field makes this concrete. It shows which methods your customers actually reach for, which is often not what the shop owner expects. For Nepali shops, it separates the people trying to pay online from those choosing cash on delivery, and those two groups behave differently — different order values, different cancellation rates, different follow-up needed. Knowing the split is a business decision, not an analytics detail.
Common mistakes with add_payment_info
The most damaging is firing it on the confirmation of a successful payment, which makes the step look flawless and hides every failure. It belongs at submission, before the outcome is known. The opposite error is firing it when the payment form merely appears, which makes the step meaningless in the other direction.
A quieter problem is the redirect. When payment happens on a gateway’s own domain and the shopper is sent back afterwards, the session can break and the purchase can be attributed to the gateway as a referral. That does not corrupt this event, but it does corrupt what comes after it, so add the gateway’s domain to your referral exclusion list. And do not collect anything identifying here — the payment type label is the only extra detail this event needs.
How to act on it
Measure the fall from this step to the completed purchase and treat anything wide as a payment failure until proven otherwise. Break it down by payment type and by device, then reproduce the worst combination yourself with a small real order. Most gateway problems are obvious the moment you try them on a phone.
Use the payment type mix to decide what to add or remove. A method almost nobody selects is not worth the integration cost; a method people select and then fail on is worth a conversation with the provider. If you are unsure whether the drop is a genuine failure or a measurement artefact, check the event order and timing in DebugView, or have the whole checkout reviewed as part of an analytics and tracking engagement before you rebuild anything.