Skip to content

Guide 38 · Ecommerce · GA4 + Tag Manager

Send the add_payment_info event: the payment choice, with the payment_type that needs a custom dimension to report on

Checked 11 November 2026 · Verification: reference file checked in Python (figures recomputed from the worked example) · Steps traced to Google's developer docs and Analytics Help, opened 11 November 2026 · 5-minute read

The checkout journey has a payment step that only this event fills: send add_payment_info when the visitor submits payment details, with the method in payment_type.

Expected signal

After step 4, DebugView shows an add_payment_info event with payment_type Credit Card and value 30.03. After about 24 hours, the Checkout journey report shows the Add payment step, and — once the custom dimension is registered — purchases break down by payment type.

Download the reference: the add-payment-info-event reference (JSON) (1287 bytes, MD5 d2708eb91a1c05d07736fbcfc45e24e9). It holds the event parameters, the worked example, and the recomputed figures.

What you need

  • The Google tag on the site. The event is sent through the Google tag; the install guide covers it.
  • Access to the website source code, or a Tag Manager container. The event fires when the visitor submits payment information.
  • The payment methods the store accepts. The worked choice is Google's example, Credit Card, on the single-item cart worth 30.03.

The trace

  1. Fire the event when payment information is submitted. The add_payment_info event signifies a user has submitted their payment information in the checkout, so it belongs on the payment step submit, not on the payment page load. Send gtag("event", "add_payment_info", { currency: "USD", value: 30.03, coupon: "SUMMER_FUN", payment_type: "Credit Card", items: [...] }) with the full cart in the items array.
  2. Send the payment type as a plain label. The payment_type is a free-text string, and Google's example is Credit Card. Use the store's own method names and spell them the same way every time, because the dimension groups by exact string. Never send card numbers, expiry dates, or any payment credential in this or any other parameter.
  3. Keep the cart value the same as the earlier checkout steps. The value is the items total: 10.01 × 3 = 30.03. Do not include shipping or tax; those are separate parameters on the purchase event. The discount is recorded on the item: 2.22 per unit, 6.66 for the three tees.
  4. Register payment_type as a custom dimension to report on it. Payment_type is a recommended event parameter, but it has no prebuilt dimension. In Analytics, go to Admin, then Data display, then Custom definitions, then the Custom dimensions tab, and create a dimension named Payment type, scope Event, event parameter payment_type. The dimension becomes usable 24 to 48 hours after the data was sent and the dimension was created, and only for events after registration.
  5. Check it in DebugView. Turn on debug mode, submit the payment step, and open DebugView (Admin, then Data display, then DebugView). Select the add_payment_info event and check payment_type reads Credit Card and the value reads 30.03. One payment submit must produce one event.
  6. Confirm the reports after about 24 hours. The Checkout journey report has four steps — Begin checkout, Add delivery, Add payment, Purchase — and the Add payment step is fed by this event alone. A checkout journey with an empty third step is telling you this event is missing.

Dead ends

DEAD END — PAYMENT DETAILS IN THE EVENT. Payment_type takes a label such as Credit Card. Card numbers, security codes, and expiry dates must never be sent to Analytics; Google prohibits sending personal information, and payment credentials are the worst case. Send the method, nothing more.

DEAD END — THE UNREGISTERED DIMENSION. Payment_type arrives in the event but appears in no report until it is registered as an event-scoped custom dimension. The registration is not retroactive, so orders placed before registration can never be broken down by payment type. Register the dimension the same week the event ships.

DEAD END — THE EVENT ON THE PAYMENT PAGE LOAD. A visitor who loads the payment page but never submits payment details has not added payment information. Firing the event on page load inflates the Add payment step and hides the real drop-off between shipping and payment.

End state

Every payment submit sends one add_payment_info event with payment_type Credit Card, the full cart, and value 10.01 × 3 = 30.03 with currency USD. The Payment type custom dimension is registered with scope Event, so purchases break down by method after 24 to 48 hours. DebugView shows the event the same minute, and after about 24 hours the Checkout journey counts the Add payment step.

Sources

Checked 11 November 2026. The event definition above is the one in Google's recommended events reference, opened 11 November 2026, and the custom dimension steps are the ones in Analytics Help, opened the same day. No step was run inside a live Analytics property, because that needs a Google sign-in and this site does not sign in as anyone. The figures were recomputed in Python: 10.01 × 3 = 30.03, and the item discount 2.22 × 3 = 6.66. The reference file was checked the same way.