Purchase recovery behavior is one of the easiest places to create support bugs if the docs are vague. AppActor exposes several similarly named flows that should not be treated as aliases.
Need implementation snippets? Start with Making Purchases, then wire Restore and Account Recovery.

​
Purchase outcomes

Depending on SDK and store behavior, purchase results can land in states like:
  • success
  • cancelled
  • pending
Some SDKs also expose deferred purchase resolution and purchase-intent events as separate streams.

​
Restore vs sync vs queue drain

These flows serve different purposes:
  • restorePurchases() is the user-facing restore path.
  • syncPurchases() is the quiet store sync path.
  • quietSyncPurchases() is kept only for backward compatibility on some wrappers.
  • drainReceiptQueueAndRefreshCustomer() is the explicit queue-drain or recovery path.
Your app should not swap them freely.
  • Put restore behind a user-triggered recovery action.
  • Use quiet sync when you need a silent reconciliation step.
  • Use queue drain only when you intentionally want to flush retryable receipt work and refresh state.

​
Receipt retry and consumables

For consumables, tokens, or credit grants, do not treat a local purchase UI success as final business confirmation. Wait until:
  1. the receipt is accepted by the backend path
  2. AppActor reports a successful receipt result or refreshed customer update
Retryable receipt failures should remain retryable, not immediately converted into irreversible backend credits.

​
Events and diagnostics

Some SDKs expose event surfaces such as:
  • customer-info updates
  • receipt pipeline events
  • promoted or deferred purchase intents
  • SDK log streams
Those are especially useful for support tooling, QA, and staged rollout validation.

​
Scenario matrix