The easy half and the hard half
On 1 October 2026, card surcharging ends in Australia. The Reserve Bank has removed its prohibition on no-surcharge rules, and eftpos, Mastercard and Visa have each confirmed they will ban surcharging on their networks from that date. American Express, which sits outside the RBA's formal regulation, has confirmed it is doing the same.
Nearly everything written about this so far has been written for finance and operations teams: turn the setting off, review your merchant agreements, work out whether you absorb the cost or lift your prices.
That advice is correct, and it is also the easy half.
The harder half is that for a lot of Australian ecommerce and booking businesses, the surcharge is not just a line on a receipt. It is sitting inside the number your analytics platform records as revenue, inside the conversion value you send to Google Ads, and inside the purchase value you send to Meta. When it disappears on 1 October, those numbers fall — with no change in demand, no change in customer behaviour, and no warning light anywhere in your reporting.
This post is about how to find out whether that applies to you, and what to do about it before the date.
What actually changes
Narrowly: surcharges applied because a customer chose to pay by card are removed across eftpos, Mastercard and Visa, covering debit, credit and prepaid cards.
What is not in scope matters just as much:
That exclusion list is why this is more complicated than it first looks. If your checkout applies a card surcharge and a booking fee — common in accommodation, events and travel — then only part of the additional value disappears on 1 October. The rest stays. You are not looking for a clean before-and-after. You are looking for a partial change to a composite number.
Alongside the surcharge removal, the RBA is also lowering interchange caps and introducing new fee transparency requirements for card networks and large acquirers. Relevant to your cost base, not to your tracking.
Is your surcharge inside your purchase event?
There is no universal answer. It depends entirely on the order in which your checkout calculates the total and fires the purchase event. Three broad patterns:
Platform-native checkouts. The surcharge is typically applied as a payment-method fee at the payment step, after the cart total is assembled. Whether it lands inside the purchase event depends on whether your tracking reads the order's grand total or its pre-payment subtotal. Both are common.
Custom or headless checkouts. The purchase event is usually built from an order object in your own code. Whichever field the developer chose — total, total_price, order_total, subtotal — is the field you have been reporting on ever since, and almost nobody currently remembers which one it was.
Booking engines and PMS platforms. Accommodation, travel and events are the highest-risk group. Surcharge settings often live in the booking engine rather than the website, are configured per payment channel, and the tracking layer sits downstream of a confirmation page that may or may not reflect the surcharged total. These setups also frequently carry booking fees alongside the surcharge, which is exactly the partial-change problem above.
You cannot reason your way to the answer. You have to look.
How to check, in order of effort
The reconciliation check
About fifteen minutes. Take a clean recent period — a full month is ideal, and avoid any promotional spike.
Pull three numbers for that period: total purchase revenue from your analytics platform, total order value from your ecommerce or booking platform, and total surcharge collected from your payment provider's reporting.
Then compare. If analytics revenue tracks your platform's gross order value including surcharge, the surcharge is inside your purchase event. If it tracks the value excluding surcharge, you are already reporting net and 1 October changes nothing for you.
The gap you're looking for is small — often under 1.5% — so this only works if your analytics and platform revenue normally reconcile closely. If they're already 8% apart for other reasons, this test tells you nothing and you should skip to the next one. If they are 8% apart, that's a separate and considerably more urgent conversation.
The single-transaction inspection
About thirty minutes, and this is the one that actually settles it.
Put your tag manager into preview mode and your analytics platform into debug mode, then run a real transaction through the checkout using a card that triggers a surcharge.
On the confirmation step, inspect the purchase event payload directly and compare four numbers:
- The
valuein the purchase event - The order subtotal
- Subtotal plus shipping plus tax
- The grand total the customer was actually charged
If value matches the grand total, the surcharge is inside. If it matches subtotal plus shipping plus tax, it is not.
Do this for each payment method you accept. It is genuinely common for a surcharge to be included on one path and excluded on another, because the paths were built at different times by different people. Card-present, online, pay-by-link and booking-engine payments should each be checked separately if you take payments through more than one.
The downstream check
The one people forget. Confirming your analytics platform is only the first destination — your ad platforms may be receiving a different number entirely.
Check each of these independently:
- Google Ads conversion value. If conversions are imported from your analytics platform, the value follows whatever you found above. If you run a separate Ads conversion tag, it may be reading a different variable. Check it directly.
- Meta purchase value, both browser pixel and Conversions API. Server-side and browser events are built from different sources more often than people expect, and they can disagree.
- Any offline or CRM-based conversion imports, which usually carry the value from your order system rather than your tag.
- Refund and cancellation events, which need to be consistent with the purchase value or your net revenue drifts over time regardless of any of this.
A setup where the analytics platform reports net and Google Ads reports gross is entirely possible. It means 1 October affects your bidding but not your reporting, or the reverse. Worth knowing which.
What to do before the date
Annotate it. In your analytics platform, in Google Ads, and in whatever your leadership team actually reads. Cheapest thing on the list and the one that saves the most time in November.
Calculate your adjustment factor now. From your payment provider's reporting, work out surcharge collected as a percentage of total revenue for September. That percentage is what you subtract from pre-October figures to make them comparable to post-October figures. Calculate it now while the data is clean — it is much harder to reconstruct in December. It's a blended figure, because surcharge rates vary by card type and your card mix shifts month to month.
Decide your bidding position deliberately. If your conversion values are about to fall, your achieved ROAS falls with them, and tROAS campaigns will respond by pulling back spend. You have three options: leave targets alone and accept a temporary pullback, lower targets by the equivalent proportion on 1 October, or freeze target changes for a fortnight and act on real data. All three are defensible. Drifting into one by accident is not.
Brief whoever reads the dashboard. The person who asks why October revenue is down should already know the answer before they ask.
A 1.5% shift sounds like nothing right up until you remember that's the range automated bidding makes budget decisions inside. The algorithm can't tell the difference between a bad month and a definitional change. It just reacts.
What deliberately not to do
Three things not to do
Do not restate your historical data. Retroactively stripping surcharge out of prior periods so the series looks continuous will cost you the ability to reconcile against anything else. The adjustment factor gets you the same comparability without corrupting the record.
Do not change your value definition on 1 October as well. If you have been meaning to move from gross to net, or to start passing profit instead of revenue, do it in November or do it in September. Two changes on one date and you will never separate them.
Do not react to the first week. The first fortnight contains the definitional change, any price increases you or your competitors have made, and normal volatility, all at once.
Reading the first fortnight
The useful thing about this change is that it has a signature, and you can tell it apart from a real demand change if you look at the right metrics.
A definitional change looks like: order count flat, conversion rate flat, revenue per order down by roughly your surcharge percentage, sessions flat.
A demand change looks like: order count down, conversion rate down, revenue per order roughly unchanged.
A price increase looks like: revenue per order up, conversion rate down slightly, order count down slightly.
If you absorbed the cost into your prices, you will see the third pattern layered on top of the first, and they move revenue per order in opposite directions. That is why the adjustment factor from September matters. Without it, the two changes net out into a number that looks like nothing happened, and you will draw the wrong conclusion about your price change.
The broader point
This is a small change with a disproportionate ability to mislead, and that is exactly the category of thing that quietly damages decision-making. A 1.5% shift is well inside the range where automated bidding makes real budget decisions, and well inside the range where a board deck says "October was soft".
The businesses that handle this well won't be the ones that got the compliance right. Nearly everyone will, because their payment provider will handle it for them. They'll be the ones who knew, on 30 September, exactly what their purchase event was made of.
We build measurement and attribution infrastructure for Australian businesses. If you want a second pair of eyes on your purchase event before 1 October, get in touch.