Error Handling
Phase 1: Understand
With raw Google Play Billing you enumerate every BillingResponseCode, split them into retriable and non retriable groups, and build backoff retry logic. RevenueCat collapses this into a single type you deal with: PurchasesError.
Key facts you rely on:
PurchasesErrorCodeis a cross platform enum with stable, readable codes.error.messageis a technical string. It belongs in logs, not in the UI.awaitPurchase()throwsPurchasesTransactionException, which adds auserCancelled: Booleanflag.- Every other
await*call (awaitOfferings,awaitGetProducts,awaitCustomerInfo,awaitRestore) throwsPurchasesException. - The SDK already retries transient billing and network failures internally. Any error that reaches you has exhausted the SDK retry budget. You do not add your own backoff loop. The only retry you implement is a user triggered "Try Again" button.
Phase 2: Plan
Before writing a catch block, decide three things:
- Which
await*call are you wrapping? That picks the exception type. - Which codes have specific handling? Everything else falls into a generic branch.
- What user facing string does each handled code map to?
Use this table to categorize PurchasesErrorCode values and pick the UX response.
Exception type decision:
Phase 3: Execute
Purchase errors
Check userCancelled first and return silently. Then branch on error.code.
Non purchase errors
Catch PurchasesException and branch on the code. Use offline or cached fallbacks where you have them.
Map codes to user facing strings
Keep a single mapping function. Never pass e.error.message to the UI.
Checklist
- You picked
PurchasesTransactionExceptionforawaitPurchaseandPurchasesExceptionelsewhere. - You checked
userCancelledbefore any branching onerror.code. - You handled
PaymentPendingError,ProductAlreadyPurchasedError, andNetworkErrorwith their specific flows. - You logged
error.messageand showed a mapped string fromuserFacingMessageto the user. - You did not add retry loops around SDK calls. Retries are user initiated only.


