What This Tutorial Covers
By the end, a refund in your payment processor or affiliate network will trigger a correction that reaches both ad platforms: Google gets a conversion adjustment that retracts the sale, and Meta gets a refund event that tells its model the purchase came undone. The result is an ad account optimizing on net conversions, the ones that stayed sold, instead of gross conversions that include everyone who churned back out.
You will need:
- Conversion tracking already sending sales to Google and Meta, each carrying an order ID (this is the anchor the whole loop depends on)
- Access to your refund data: the payment processor webhook, the network IPN, or a report you can pull on a schedule
- A way to upload to Google: the Google Ads UI, or the Data Manager API (offline conversion imports and adjustments moved to the Data Manager API as of June 15, 2026)
- A Meta Conversions API connection, the same one you send purchases through
Why a Logged Refund Isn't a Reconciled Refund
The trap here is thinking that because your tracker or your books recorded the refund, the job is done. It isn't. Your ad platforms live in a separate world, and they never see your refund report. Unless you send them a correction, the conversion you reported at the sale stays on the books forever.
The loop most setups leave open: the refund is logged in your systems but never sent back to the ad platforms, so they keep optimizing on a sale that no longer exists.
Step 1: Report Every Conversion With an Order ID
This step happens at the sale, not the refund, but it is the one that makes reconciliation possible, so it comes first. When you send the original purchase to Google and to Meta, include a stable order identifier: the order ID, transaction ID, or receipt number from the payment processor or network. Send the same value to both platforms.
That identifier is what you will use later to point at the exact conversion you need to reverse. Google explicitly recommends adjusting by order ID rather than by click identifier plus timestamp, because it is unambiguous. Meta uses it to match your refund event to the original purchase. If you only ever sent a click ID and a value with no order ID, you can still adjust on Google by gclid plus conversion time, but it is fragile, and on Meta you lose the clean match entirely.
Failure point one: not sending an order ID on the original conversion. You cannot retroactively add it. If your current setup reports purchases without a stable order identifier, fix that first, because every refund before you fix it is unreconcilable.
Step 2: Catch the Refund Event
You need a trigger. The refund happens in one of two places: your payment processor (Stripe, PayPal, a merchant checkout) or your affiliate network (ClickBank, a CPA network, JVZoo). Both can tell you.
The clean way is a webhook or IPN that fires the moment a refund, chargeback, or cancellation is processed, carrying the original order ID and the refunded amount. ClickBank's INS sends a refund and chargeback notification; most processors have a charge.refunded style event. If you cannot get a real-time hook, the fallback is a scheduled pull: every day, query the last 30 to 60 days of transactions and diff them against what you have already reconciled to find new refunds. Real-time is better, but a daily reconciliation job closes the loop tightly enough for ad optimization.
Failure point two: only listening for full refunds. Partial refunds and chargebacks change what the sale was worth without erasing it. Decide up front whether a partial refund should retract the conversion or restate its value, and make sure your refund catcher passes the amount, not just a boolean.
Step 3: Send Google a Conversion Adjustment
Google has a clean, native mechanism for this: conversion adjustments. There are two types, and you pick based on what the refund did.
- RETRACTION. Use this for a full refund or chargeback. It negates the conversion, sets its value to zero, and removes it from your conversion count. This is the one you will use most.
- RESTATEMENT. Use this for a partial refund. It changes the conversion's value to the new net amount without removing the conversion entirely.
Identify the conversion by the order ID you sent in Step 1, the conversion action, and the original conversion time. Upload the adjustment through the Google Ads UI or the Data Manager API, which is where offline conversion imports and adjustments now live as of June 15, 2026. One hard rule to remember: once a conversion is retracted, or restated to zero, it is final. You cannot adjust it again, and later attempts are silently ignored. So get the direction right before you send it.
Step 4: Send Meta a Refund Signal
Meta has no one-click button that un-does a purchase for ad optimization, so this step is about sending a corrective signal, not deleting a record. Through the same Conversions API connection you use for purchases, send a refund event carrying the original order ID and the refunded value. There are two practical ways teams use it:
- A refund or return custom event tied to the original order ID, which lets you build an exclusion audience of refunders and keep the algorithm from prospecting toward them.
- Value-based correction, where your reporting to Meta reflects net purchase value rather than gross, so value optimization is trained on the revenue you actually kept.
The key discipline is consistency: the refund event must carry the same order ID as the original purchase so Meta can associate the two, and you should send it through the server-side connection, not a browser pixel, because the refund happens long after the visitor's session is gone. A refund three weeks out has no browser to fire from. The server is the only place it can originate.
Reconcile net, not gross. The goal of both the Google adjustment and the Meta refund event is the same: move your ad platforms from optimizing on gross conversions, which count everyone who ever bought, to net conversions, which count only who stayed. That single shift changes which customers the algorithms go looking for next.
Step 5: Verify the Correction Landed
Do not assume a correction worked because you sent it. Confirm it, because a silent failure here looks exactly like success and quietly poisons your optimization for weeks.
On Google, open the conversion action and check that your conversion count and total value dropped after the adjustment upload, and review the diagnostics for adjustment errors like unmatched order IDs. On Meta, check the Events Manager for your refund events arriving and matching, and confirm your exclusion audience of refunders is populating. Trace one real refund end to end: find a specific refunded order, confirm the RETRACT reached Google and the refund event reached Meta, and watch both platforms reflect it. One clean end-to-end trace tells you the loop is closed.
What Good Looks Like
A properly reconciled ad account has four properties: every conversion is reported with a stable order ID; refunds are caught in real time or on a daily job; each refund pushes a RETRACT or RESTATEMENT to Google and a refund event to Meta, keyed to that order ID; and both platforms' numbers visibly move when a refund lands. When all four hold, your ad platforms optimize on the customers who stayed, not the ones who churned back out, and your cost per real acquisition stops drifting upward for reasons you cannot see on a sale-only dashboard.
The piece almost everyone skips is that this has to be automatic and continuous, because refunds arrive on their own schedule, days or weeks after the sale, long after you have moved on to the next campaign. A one-time manual cleanup does not hold. That is exactly the job a purpose-built tracker automates: ClickerVolt's Refund Sync watches for the reversal, matches it to the original conversion by order ID, and fires the RETRACT to Google and the refund signal to Meta and TikTok on its own, so the loop in this guide stays closed without you running it by hand every week.
Whatever you use, wire the refund half of your tracking with the same care you gave the sale half. A conversion you can report but never retract is a signal that only ever tells your ad platforms good news, and good news that isn't true is the most expensive kind.
See how ClickerVolt's Refund Sync closes the loop
FAQ
How do I remove a refunded conversion from Google Ads?
Upload a conversion adjustment of type RETRACTION, identifying the conversion by its order ID, conversion action, and original conversion time. It sets the conversion value to zero and removes it from your count. For a partial refund, use RESTATEMENT instead to lower the value without deleting the conversion. Adjustments upload through the Google Ads UI or the Data Manager API.
Can you send refunds to Meta's Conversions API?
Yes, through the same server-side Conversions API you use for purchases. Meta has no automatic reversal, so you send a corrective refund event carrying the original order ID, then use it to exclude refunders from prospecting and to report net rather than gross purchase value. Send it server-side, since a refund happens long after the browser session ends.
Why does the order ID matter so much for refunds?
Because it is the only stable link between the sale and the refund. Google recommends adjusting by order ID rather than click ID plus timestamp, and Meta needs it to match your refund event to the original purchase. If the original conversion was reported without an order ID, the refund cannot be cleanly reconciled, so send one at the sale.
How often should I reconcile refunds?
Real time is ideal, via a processor webhook or network IPN that fires when the refund is processed. If that is not available, a daily job that pulls the last 30 to 60 days of transactions and diffs them against what you have already reconciled is enough for ad optimization. The point is that it runs continuously, because refunds keep arriving after you have moved on.
