Price history
Recorded standalone sale prices and the latest available store price, in USD. Historical dots use the sale start date and its recorded offer price. Prices can change during a sale; this is not a daily price log. Bundle prices and upcoming offers are excluded. History covers up to the 100 most recent recorded offers.
Lowest recorded standalone price in this history: $34.99. The latest store price is $34.99, matching the lowest recorded price shown here.
View 2 recorded prices
| Sale start / price check | Price | Observation |
|---|---|---|
| $34.99 | Latest store price | |
| $34.99 | Unity First Price 2026-06-20 2026-06-27 |
Sale and bundle history
The 1 most recent recorded offers including this asset. Past offers may no longer be available. Bundle prices cover a package, not this asset alone.
About OSL IAP Receipt Verification - Client & Backend
- Tools, Systems & Learning > Game Templates & Systems
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.
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.