OSL IAP Receipt Verification - Client & Backend

OSL IAP Client is for Unity IAP projects that need to verify a purchase before granting currency, items, or subscription access. It connects Unity IAP v5 pending orders to an included .NET 10 Apple/Google verification starter, persists receipts that still need processing, and uses server-side transaction records to reduce duplicate rewards.

Why / Key Benefits

- Verify before granting: Send Apple or Google purchase data to your backend and grant only when the response explicitly allows it.

- Recover after restart: Persist pending receipt payloads with a versioned schema, last-known-good backup, and corrupted-file quarantine so unconfirmed purchases can be retried after the app restarts.

- Avoid duplicate rewards: Treat the backend database transaction record as the idempotency authority; `AlreadyProcessed` confirms the store order without granting again.

- Handle temporary failures: Retry queued verification with typed transient failures and configurable exponential backoff. Retry-exhausted entries remain recoverable instead of being discarded.

- Bind purchases to users: Prevent a pending transaction from being verified or granted under a different logged-in user.

- Reconcile server records: Fetch authoritative transaction records and compare them with your application's durable grant ledger.

- Start from working server code: Use the included .NET 10 ASP.NET Core backend starter with Apple/Google verification, SQLite/Dapper persistence, history and subscription endpoints, reconciliation data, and webhook handlers.

- Keep Unity IAP semantics: Confirm a pending order only when the backend response permits confirmation.

Typical Workflow

1. Unity IAP returns a pending order.

2. The client stores its receipt payload and sends it to the configured backend.

3. The backend checks Apple or Google and atomically records a new transaction.

4. The client grants only `ShouldGrantReward` responses and confirms only `ShouldConfirmPurchase` responses.

5. Unresolved queue entries retry after temporary failures or a later app launch.

Requirements

- Package release: 2.0.0 (2026-08-30)

- Minimum Unity Version: Unity 2021.3 LTS

- Tested Unity Versions: Unity 2021.3.45f2 and Unity 6000.3.12f1 (package-isolation import and compile)

- Purchase flow: Unity IAP `com.unity.purchasing` 5.0.0 tested

- Backend runtime: .NET 10 SDK/runtime

- Backend providers: Apple App Store and Google Play

- Optional demo UI: Unity UI; the package imports in compatibility mode when optional Unity packages are absent

Limitations / Scope

- The included backend is a starter that must be configured, secured, hosted, monitored, and adapted to your own reward and account systems.

- The default client retry limit is 10 attempts. Exhausted entries remain in a recoverable state and are reported through `OnVerificationFailed`; the package does not guarantee zero purchase loss.

- The host application must protect the reconciliation endpoint and persist transaction IDs with its own reward state. The starter cannot make a game inventory update atomic with an external store verification.

- The included database implementation is SQLite/Dapper. Other databases require an application-specific provider and SQL migration.

- This 2.0.0 release no longer supports running the included backend on .NET 8. Existing .NET 8 deployments should remain on IapClient 1.1.2 until migrated.

Documentation & Support

https://ongsoolabs.github.io/