Google Play's Billing Choice Program: What Tax Compliance You Now Own

On June 30, 2026, Google rolled out a restructured fee schedule and expanded availability for its Billing Choice Program across the US, EEA, and UK. Most of the coverage has focused on the fee numbers — what almost nobody is writing about is the tax liability that comes with the switch. This guide covers both, plus a working code sample for the tax side.

What June 30, 2026 Actually Changed

The right to use a billing system other than Google Play's own isn't new. It's been available in the EU/EEA for years under the Digital Markets Act, and in the US since 2025, when Google lost its appeal in the Epic Games v. Google antitrust case (the Ninth Circuit upheld the injunction requiring Google to allow alternative billing and external payment links for US developers).

June 30, 2026 is when Google restructured how it charges for the choice. Instead of one combined commission, Google now splits its fee into two parts:

• Service fee — starts at 10% on your first $1M of annual revenue, rising in higher tiers. This applies to every transaction, regardless of which billing system processes the payment.
• Billing fee — an additional 5% (in the US, UK, and EEA) that applies only if the transaction is processed through Google Play's own billing system.

Use alternative billing and you skip the 5% billing fee — that's the entire economic pitch. Rollout is staggered by market: US/EEA/UK from June 30, 2026; Australia from September 2026; Japan and Korea from December 2026; remaining markets through 2027.

The Part Google's Fee Announcement Doesn't Mention: Tax

Google's fee-restructuring announcement is entirely about commission percentages. It says nothing about VAT, sales tax, or GST — because that's governed by a separate document, the tax section of Google's Play Console Help and the Developer Distribution Agreement (DDA).

The rule, confirmed directly from Google's own documentation: when a customer pays through Google Play's billing system, Google is the merchant of record and handles VAT/sales tax collection and remittance in most markets. When a customer pays through your alternative billing system, you become the merchant of record — responsible for determining, charging, collecting, and remitting the tax yourself.

This is confirmed explicitly, in Google's own words, for three markets:

• United Kingdom — UK VAT
• EU/EEA — VAT across member states
• Japan — Japanese Consumption Tax (JCT)

For the United States, Google's dedicated alternative-billing enrollment page is silent on tax — it covers fees and eligibility only. The liability shift there rests on the DDA's general default clause ("except in certain countries/territories," the developer is responsible for tax), not a page dedicated to US sales tax. If you sell into the US, don't assume the exact same wording applies as in the UK/EU — verify against the current DDA for your account.

Not Every Alternative Billing Setup Leaves You Exposed

This is the part most coverage of this topic misses, and it matters for deciding whether you actually need a separate tax tool.

If your alternative billing processor is a Merchant of Record — Paddle and FastSpring are the two most common examples — they absorb VAT/sales tax compliance as part of their service, the same way Google used to. If this is your setup, the tax gap this article describes largely doesn't apply to you.

If your processor is not a Merchant of Record — Stripe direct, Braintree, or your own card processing — you inherit the full tax burden with nothing bundled in. Stripe Tax, for instance, calculates and collects tax at checkout, but it doesn't register you in a jurisdiction, file returns, or remit on your behalf. That gap — registration, ongoing compliance, and the calculation itself — is what a tax layer needs to cover.

Integration: Passing Google Play Order Data to a Tax Calculation API

There's no Google-specific connector to build here. Whatever tells you a sale happened — a Real-Time Developer Notification (RTDN) followed by an Orders API lookup, or your alternative billing processor's own webhook — gives you the same two things a tax calculation call needs: the customer's location and the cart contents.

Step 1 — Get the buyer's location from the Orders API

After an RTDN fires, call the Google Play Developer API's purchases.products.get or the relevant Orders endpoint to retrieve order details, including buyerCountry and, for markets where it's populated, buyerState and buyerPostcode.

Step 2 — Call the tax calculation API

Pass the buyer's location and the transaction amount to a tax calculation endpoint. Here's what that looks like against Clearvo's API — the same call works whether the order came from Google Play, TikTok Shop, or your own checkout, since the API doesn't care about the source platform.

const response = await fetch('https://api.clearvo.io/v1/tax/calculate', {
  method: 'POST',
  headers: {
    'x-api-key': process.env.CLEARVO_API_KEY, // csk_live_...
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    commit: true,
    idempotencyKey: order.orderId, // Google Play's own order ID is a safe idempotency key
    currency: order.priceCurrencyCode,
    seller: { country: 'IE', taxId: 'IE1234567T' },
    customer: {
      address: {
        country: order.buyerCountry,
        region: order.buyerState || undefined,
        postalCode: order.buyerPostcode || undefined,
      },
    },
    lineItems: [
      { id: order.orderId, amount: order.priceAmountMicros / 1_000_000, productName: order.productTitle },
    ],
  }),
});

const result = await response.json();
// result.summary.totalTax, result.summary.totalAmountWithTax — store against your own order record

Use commit: false instead if you want to quote tax before the purchase completes (e.g. showing a price breakdown), and re-run with commit: true once the sale is final. See the full Tax Calculations integration guide for refund handling, error codes, and product classification.

Step 3 — Find out where you might already owe tax

If Google has handled your tax silently until now, you likely don't know which jurisdictions you're already close to a registration threshold in. Clearvo's Compliance Radar (always free) backfills from your transaction history and flags registration gaps before you cross a threshold — worth checking before you calculate a single rate.

What to Do, In Order

• 1. Check your payment processor. Merchant of Record (Paddle, FastSpring) or not (Stripe, Braintree, direct)? This determines whether any of this applies to you.
• 2. Identify which markets you sell into. The tax shift is confirmed for UK, EU/EEA, and Japan. Check the current DDA for other markets rather than assuming.
• 3. Run Compliance Radar to see where you may already have an undetected registration obligation.
• 4. Wire tax calculation into your order flow using the pattern above, before your first alternative-billing transaction in an affected market.

None of this requires switching payment processors, building a Google-specific integration, or a sales call. Get a free API key and the first 1,000 calculations a month cost nothing.