Google Play Integration Guide
Clearvo has no dedicated Google Play connector — it doesn't need one. Whatever tells you a Google Play sale happened (a Real-Time Developer Notification followed by an Orders API lookup) already gives you everything a tax calculation call needs: the buyer's location and the cart contents. This guide covers the tax-liability background specific to Google Play's Billing Choice Program, then the integration itself.
Tax liability by market
This only applies to transactions processed through your alternative billing system, not transactions still going through Google Play's own billing.
| Market | Merchant of record for alternative billing | Source |
|---|---|---|
| United Kingdom | You (developer) | Confirmed explicitly in Google's Play Console Help |
| EU / EEA | You (developer) | Confirmed explicitly in Google's Play Console Help |
| Japan | You (developer), for JCT | Confirmed explicitly in Google's Play Console Help |
| United States | Likely you, under the Developer Distribution Agreement's general default | DDA §3.5 (Transaction Taxes) — not a dedicated tax statement for this program |
Getting the buyer's location
After a Real-Time Developer Notification (RTDN) fires for a purchase, call the Google Play Developer API to retrieve order details. The response includes buyerCountry and, for most markets, buyerState and buyerPostcode.
buyerState/buyerPostcode are absent from the response, that's Google's own signal that it's still acting as merchant of record for the transaction. Don't submit that transaction to a separate tax calculation call — Google is already handling it.Calculating tax
Pass the buyer's location and the transaction amount to POST /v1/tax/calculate. This is the same endpoint used for every other sales channel — there's nothing Google-specific about the call itself.
const response = await fetch('https://api.clearvo.io/v1/tax/calculate', {
method: 'POST',
headers: { 'x-api-key': process.env.CLEARVO_API_KEY, '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
Use commit: false to quote tax before the purchase completes, and re-run with commit: true once the sale is final. See the Tax Calculations integration guide for refund handling, error codes, and product classification, and the full field reference for every request/response field.
Finding registration gaps
If Google has handled your tax silently until now, you may already be close to a VAT/sales tax registration threshold in a jurisdiction you've never registered in. Compliance Radar (always free) backfills from your transaction history and flags registration gaps before you cross a threshold — worth checking before wiring in tax calculation.
FAQ
Do I need this if I'm still on Google Play's own billing system?
No. Google continues to handle VAT/sales tax as merchant of record for transactions processed through Google Play Billing, in the markets where it does so today. This guide only applies to transactions processed through an alternative billing system.
What if my alternative billing processor is Paddle or FastSpring?
Those are Merchant of Record processors — they generally absorb VAT/sales tax compliance themselves. This guide is aimed at developers using a processor that is not a Merchant of Record, such as Stripe or Braintree, where the tax responsibility genuinely lands on the developer.
Does this work for Apple App Store purchases too?
The same /v1/tax/calculate call works regardless of platform. Apple doesn't expose an equivalent alternative billing program with the same buyer-location data, so the mechanics of getting that location differ — but once you have the customer's country/state/postcode from any source, the tax calculation call is identical.