How do refunds reach Metrunio?

A refund is a correction to a purchase, not a new measurement in the browser. Your shop server reports it through the Server Events API; a shop integration such as the Shopify app does this by itself.

POST /v1/server/events
Authorization: Bearer <server key>

{
  "site_id": "site_…",
  "events": [{
    "event_id": "refund-12345-1",
    "event_type": "refund",
    "occurred_at": "2026-09-29T10:15:00Z",
    "order_id": "12345",
    "value": "10.00",
    "currency": "EUR"
  }]
}

What “matching” means

• The same order number as the purchase, character for character. “#1001” and “1001” are two orders.
• The same environment: a test refund finds no purchase from production.
• The same currency. A refund without an amount applies to the whole purchase and needs none.
• A separate event_id per refund. The same event_id twice counts once; that protects against double delivery. Two partial refunds of the same amount therefore need two different event_ids.

When the refund arrives before the purchase

This happens: two webhooks overtake each other, a historical import runs in any order, or the purchase is stuck in a retry. Metrunio then waits up to 24 hours for the purchase: every half minute at first, later once an hour. When it arrives, the refund is applied as if it had come afterwards. The 24 hours count from the first processing attempt, not from receipt; after an outage the period does not start out already expired.

If no matching purchase arrives in that time, Metrunio does not apply the refund and deletes it. Under “Data status”, the finding REFUND_WITHOUT_PURCHASE counts how many refunds were discarded this way per website and day. Metrunio keeps no order numbers or other identifiers for this, because such a refund often belongs to a purchase that could not be stored. You can find out which ones they were in your shop by the day. The most common cause is order numbers written differently for the purchase and the refund. If the purchase does arrive later, send the refund again with a new event_id. The same event_id counts as already received.

How you can tell it has been applied

• Conversions: the order shows as “refunded” or “partly refunded”, with the refunded amount.
• Overview: “Revenue measured” is calculated after refunds; the tile’s explanation gives the amount before refunds and the total refunded. Attributed revenue and the figures per channel and campaign are also calculated after refunds.
• Export and read API: the column “wert” (value) is the original purchase value, “erstattet” (refundedValue) the sum of refunds, and “status” says refunded or partially_refunded. Nothing is subtracted inside the column; the refund sits next to it, so you can reconcile both against your shop.

In the demo shop

The demo shop simulates refunds in the bundled demo tenant, in full or in part. It reports “Erstattung angenommen” (refund accepted) once the collector has accepted it; the demo shop speaks German only. The refund is applied when the order shows as refunded under “Orders & goals”. If the shop measures in your own tenant, the button is locked: there the tracking script reports the purchase from the browser, and refunds would come through your tenant’s Server Events API. The demo shop does not have the server key for that.