Skip to content

Guide 39 · Ecommerce · GA4 + Tag Manager

Send the refund event: the full refund, the partial refund, and the transaction ID that ties them to the order

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

Refunds do not happen on the website, so the browser never sees them. Send the refund event from the server with the original transaction ID, or GA4 keeps reporting gross revenue as net.

Expected signal

After the refund is sent, the Ecommerce purchases report shows the refund against the item, and Total revenue drops by the refunded amount. In the worked day below, purchase revenue is 102.08 and total revenue after the refund is 60.06.

Download the reference: the refund-event reference (JSON) (1242 bytes, MD5 7c4f91c1204ee6c913c4494cdd7c4aec). It holds the event parameters, the worked example, and the recomputed figures.

What you need

  • The original transaction ID. The refund must carry the same transaction_id as the purchase, character for character. The worked order is Google's two-item order, transaction_id T_12345, value 72.05.
  • A server-side way to send the event. Refunds happen in the store admin, not in the browser, so there is no page load to fire the event from. The usual route is the Measurement Protocol or the store platform's refund hook.
  • The refunded items and amounts. A full refund returns the whole order; a partial refund returns only some items. The worked partial refund returns the two grey tees at 21.01 each.

The trace

  1. Send the refund with the original transaction ID. The call is gtag("event", "refund", { transaction_id: "T_12345", value: 42.02, currency: "USD", items: [{ item_id: "SKU_12346", item_name: "Google Grey Women's Tee", price: 21.01, quantity: 2 }] }) for the partial refund. The value is the refunded items only: 21.01 × 2 = 42.02. For a full refund, the value is the whole order, 72.05, and the items array holds both items.
  2. Send only the refunded items for a partial refund. The worked order holds three tees at 30.03 and two grey tees at 42.02, a total of 72.05. Refunding the grey tees sends only those two items. The remaining revenue on the order is 72.05 − 42.02 = 30.03, which is the three tees that stayed bought.
  3. Send the refund once, at refund time. A refund sent twice subtracts twice. The transaction ID is the link to the order, not a dedupe key for refunds, so the sender — the server, the platform hook — must guard against repeats itself.
  4. Reconcile the day, not the event. Take a worked day with two orders: the single-item order at 30.03 and the two-item order at 72.05, so purchase revenue is 30.03 + 72.05 = 102.08. After the partial refund of 42.02, total revenue is 102.08 − 42.02 = 60.06. Total revenue is purchase revenue minus refunds; purchase revenue itself does not move.
  5. Confirm the reports after about 24 hours. The Ecommerce purchases report shows refunded items, and the Monetization overview shows total revenue net of refunds. A store with no refund events shows gross revenue as if it were net, and the gap grows with every refund.

Dead ends

DEAD END — THE REFUND WITHOUT A TRANSACTION ID. Without the original transaction_id, Analytics cannot match the refund to the order. The refund arrives as a standalone event with no order to adjust, and total revenue does not move. The ID must match exactly, including any prefix or case.

DEAD END — A CUSTOM EVENT NAME FOR REFUNDS. An event named order_refunded or refund_processed is a custom event, and custom events never reach the Monetization reports. The recommended name is refund, spelled exactly that way.

DEAD END — WAITING FOR THE BROWSER TO FIRE IT. Refunds happen in the admin panel, days after the purchase, with no browser session open. No tag on the website can see them. If refunds are only ever sent from the browser, they are never sent at all.

End state

Every refund sends one refund event from the server with the original transaction_id, the refunded items only, and a value equal to price times quantity for those items (21.01 × 2 = 42.02 for the partial refund, 72.05 for the full refund). The worked day reconciles: purchase revenue 102.08, refund 42.02, total revenue 60.06. After about 24 hours the Monetization reports show the net figure.

Sources

Checked 11 November 2026. The event definition above is the one in Google's ecommerce developer guide, opened 11 November 2026. 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: 21.01 × 2 = 42.02, 30.03 + 42.02 = 72.05, 72.05 − 42.02 = 30.03, 30.03 + 72.05 = 102.08, and 102.08 − 42.02 = 60.06. The reference file was checked the same way.