Net Revenue Attribution: What Refunds and Chargebacks Do to Your Channel Numbers

A refund or a dispute arrives with none of the marketing context of a purchase. There is no landing URL, no referrer, no campaign parameter, no click ID, because the customer did not come from an ad to get their money back. They contacted support, or they contacted their bank.

So the reversal has exactly one route to a channel: the identifier of the payment it reverses. If your pipeline retains that link, attribution is a join. If it does not, the reversal is orphaned and can only be reported as an unattributed total, which is precisely as useful as not reporting it.

This is why the fix is architectural rather than analytical. You cannot restate channel revenue after the fact if the link was never stored. The decision has to be made in the webhook handler, before anyone asks the question.

Whether this matters to you is an empirical question with a cheap answer: compute your overall reversal rate as reversed amount over gross amount for a period that has fully closed, then compute it separately per channel. Two minutes of SQL against your payment provider's data.

If the per-channel rates are within a point of each other, note it and move on; gross ranking is close enough for your business. If they diverge materially, you have been making budget decisions on the wrong ordering, and the size of that error is now quantified rather than assumed. Either outcome is worth the two minutes.

Do not assume the answer. Refund propensity varies with buyer intent, and buyer intent varies enormously with how someone found you. Discovery through a comparison listing, a discount-driven campaign, and a technical documentation page do not produce the same buyers.

This trips up any restatement built on the assumption that a reversal offsets its original payment exactly. Stripe's documentation lists several reasons the disputed amount can be lower or higher than the original charge.

Currency conversion is one: Stripe's example describes a purchase for 100 EUR converting to 113.74 USD on the customer's account in January, disputed in April at a changed exchange rate, arriving back at the business as 107.86 EUR rather than the original 100 EUR. Recurring payments are another: Stripe notes that when an account owner disputes multiple payments within a recurring subscription plan, their bank sometimes creates a single dispute for the total amount against one of the charges, giving the example of three 50 USD charges disputed as a single 150 USD dispute against one of them.

There are also partial disputes, where only a portion of the transaction is contested, and disputes on partially refunded charges, where the cardholder disputes the entire payment after you have already refunded part of it. Your restatement logic has to cope with a reversal that exceeds the remaining balance of the original payment without producing negative attributed revenue for the channel.

Not every dispute-shaped event is a reversal. Stripe describes an inquiry as a preliminary phase before a formal dispute, sometimes called a retrieval or a request for information, used most often by American Express and Discover, with Mastercard and Visa no longer using it. In the API these carry statuses prefixed with warning, and Stripe notes that if an inquiry remains open for 120 days without escalating to a chargeback, it is marked as closed.

Separately, early fraud warnings are messages sourced from issuer fraud reports, including Visa TC40 and Mastercard SAFE reports. Stripe's documentation states that unless the payment was covered by the liability shift rule, 80% of EFWs convert into a fraud dispute if you do nothing, but an EFW is a warning, not a money movement.

The rule for your data model: only count events that actually moved money. An inquiry that never escalates reversed nothing. Counting warnings as reversals will make your net numbers pessimistic in a way that is just as wrong as the gross numbers being optimistic.

There is a real choice here and only one answer serves channel decisions. You can book the reversal in the period it occurred, or you can restate the period of the original sale. Accounting practice often does the former; Stripe's revenue recognition documentation shows a January payment of 90 USD refunded in February appearing as revenue in January and as a refund contra-revenue entry in February.

For attribution, that is the wrong shape. You want to know what a campaign that ran in January actually produced. Booking its refunds against February makes January look better than it was and February look worse, and if spend shifted between the two months the comparison becomes meaningless.

So restate. Attribute the reversal to the period, campaign, and source of the original payment, and re-emit the corrected figure for that period. Which means your channel reports must be re-runnable rather than snapshotted, and every consumer of them must expect historical figures to move.

A number that will change should say so. The cheapest honest implementation is a maturity label on every period: provisional while inside the dispute-initiation window, settling while disputes remain open, and final once both have passed.

This costs one column and removes an entire class of argument. Nobody has to relitigate why last month's channel revenue moved, because the report said it would. It also prevents the opposite failure, where a team stops trusting the report entirely because the numbers occasionally change without explanation.

Stripe's revenue recognition documentation offers a related option worth knowing about: it describes a Record refunds separately setting, where by default the refund offsets the revenue so neither amount appears in the report, and enabling it shows both the revenue and the refund with the same net result. Showing both is generally better for diagnosis, because a channel with high gross and high refunds is a different problem from a channel with low gross.

The original payment identifier, without which no attribution is possible. The amount and currency of the reversal itself, which may not match the original. The provider's own event identifier, so that duplicate deliveries do not double-count. A timestamp for the reversal and a separate one for the original payment, since restatement needs both.

Also worth recording explicitly: the reason the reversal could not be processed, when that happens. Metrivo's provider mappers carry an exclusion reason on records they cannot use, for example when a refund arrives without the original amount, or when a dispute event is not itself a revenue movement. An excluded record with a stated reason is auditable; a silently dropped one is not.

Reversal semantics are not standardised across payment providers. Some emit a distinct refund object; some express reversals as adjustments with an action type; some report a dispute opening and its resolution as separate events and some do not report the resolution at all.

Metrivo normalises Stripe, Razorpay, Paddle, Dodo, Lemon Squeezy, Polar, and the Manual Payment API into one canonical shape so that a net figure spanning providers is computed on comparable definitions. If you are building this yourself, budget for the normalisation rather than assuming a shared vocabulary; the differences show up exactly where they are most expensive, in partial reversals and in dispute outcomes.

The general principle is the same one that applies to every cross-provider metric: normalise first, aggregate second. Aggregating provider-native shapes produces a number whose definition changes with your provider mix. The payment webhook audit checklist covers proving that the events you rely on are actually arriving and being retained.

A high reversal rate is a symptom with several possible causes, and they call for opposite responses. Expectation mismatch means the channel's messaging promises something the product does not deliver, and the fix is copy. Fraud concentration means the channel is attracting card testing or stolen-card purchases, and the fix is risk rules at checkout. Billing-descriptor confusion means customers do not recognise the charge on their statement and dispute it in good faith, and the fix is one setting in your payment provider.

The third of those is worth checking first because it is nearly free to fix and disproportionately common in SaaS, where the legal entity name on the statement often bears no resemblance to the product name the customer bought.

You can usually separate these by looking at the split between refunds and disputes. Expectation mismatch tends to produce refund requests, because the customer contacts you. Descriptor confusion and fraud tend to produce disputes, because the customer contacts their bank instead. A channel whose reversals are overwhelmingly disputes rather than refunds is telling you something specific.

Every restated figure inherits the confidence of the underlying attribution. If a payment was matched to a channel by inference rather than by a confirmed identifier, its reversal is attributed to that channel with the same uncertainty, and the net figure should carry it forward rather than laundering it into a clean-looking number.

Metrivo labels matches as confirmed, inferred, or unknown, documented under attribution confidence. A net-of-reversal figure built mostly on inferred matches is a directional indicator, not a settled fact, and presenting it as the latter is how attribution work loses credibility inside a company.

Where reversals cannot be joined to an original payment at all, report them as an unattributed reversal total. Do not distribute them proportionally across known channels; that manufactures precision and, worse, spreads a problem that may be concentrated in one channel evenly across all of them, which is the exact opposite of what you need to know.