Unity IAP Receipt Validation Fails on Google Play Billing 5+ - Plugin and Backend Fix - How to Fix

Problem: Purchases succeed in Google Play, but your Unity app or backend reports receipt validation failure after Billing 5+ migration.

Common symptoms:

Purchase callback fires but entitlement is not granted
Backend returns invalid receipt or purchase token errors
Subscriptions appear paid in Play Console but locked in-game
Validation works in test build, then fails in production rollout

This is usually a contract mismatch between Unity IAP payloads and backend verification expectations.

Root cause

Most failures come from one of these gaps:

Unity IAP / Google Billing package mismatch after upgrade
Backend still parsing legacy fields instead of Billing 5+ token flow
Wrong package name or product ID sent to Google verification endpoint
Service account permission or API scope issues in Play Developer API
Missing acknowledgement/consume flow leading to repeated invalid states

Billing upgrades often keep the purchase UI working while silently breaking validation contracts.

Quick fix checklist

Confirm Unity IAP package and Billing dependency versions are compatible.
Log and inspect raw purchase payload from device before backend transform.
Verify backend uses current purchase token fields for Google validation.
Confirm Play Developer API credentials and package/product IDs match exactly.
Validate acknowledgement logic for non-consumable and subscription flows.

Step 1 - Align Unity IAP and Billing versions

In Package Manager, ensure:

Unity IAP is on a version that supports your Billing target
Any custom Gradle overrides do not pin older billing libraries
Android resolver output does not include duplicate billing artifacts

If version alignment is off, receipt schema differences can break your parser without obvious compile errors.

Step 2 - Capture raw purchase payload before backend mapping

Before sending to backend, log:

product ID
transaction ID
purchase token
package name
purchase timestamp

Do this in a development build (without exposing secrets).
You need to verify what Unity emits versus what your backend expects.

Step 3 - Update backend validation contract

For Billing 5+ flows, ensure backend validation uses:

current purchase token field
correct endpoint path for one-time product vs subscription
exact package name and product ID from the app

Do not rely on legacy receipt assumptions from older Billing integrations.

Step 4 - Verify Google Play Developer API setup

Check backend credential wiring:

service account has Play Console access
linked project/API is enabled
package app is granted proper permissions
environment points to production or test project intentionally

A valid token with wrong API auth context still returns verification failures.

Step 5 - Validate acknowledgement and entitlement sequencing

Correct order:

receive purchase
verify token server-side
grant entitlement
acknowledge/consume as required

If acknowledgement is skipped or delayed incorrectly, state divergence appears as validation instability.

Verification checklist

Run this flow on internal test track and production-signed build:

Make one consumable test purchase
Make one non-consumable or unlock purchase
If applicable, test subscription renewal state
Confirm backend validation response is success for each
Confirm entitlement persists after app restart

Success target:

No invalid token/receipt errors
Entitlements granted exactly once
Purchase states stable across restart and restore flows

Alternative fixes

If only subscriptions fail

Split backend handlers for products and subscriptions, and verify each calls the correct Google API path.

If sandbox works but production fails

Check production package name, signing, and service-account project binding.
Mismatched environments are a common hidden cause.

If validation fails intermittently

Add retry with short backoff for transient API errors, but keep idempotent entitlement writes.

Prevention tips

Pin and document Unity IAP + Billing versions per release branch.
Add a pre-release purchase validation smoke test in QA checklist.
Keep one backend schema contract doc for mobile purchase payloads.
Alert on validation error-rate spikes after store updates.

FAQ

Can I trust client-side receipt checks only

No. Treat client checks as UX hints. Final entitlement should be backend-verified.

Should I grant entitlement before backend validation

Not for durable purchases. Validate first, then grant, then acknowledge.

Do I need different logic for consumables and subscriptions

Yes. Token lifecycle and verification endpoints differ, so handlers should be explicit.