Guide to Apple In-App Purchase Integration for Game SDK Development
This guide walks game SDK developers through Apple’s In‑App Purchase integration, detailing product types, the three‑step purchase flow, receipt acquisition and server‑side verification, order binding and retry mechanisms, duplicate handling, subscription restoration, and comprehensive error handling to ensure reliable revenue management.
The article explains Apple's In-App Purchase (IAP) system as a core component of game SDK development, focusing on the user and payment systems, with emphasis on the payment system's relevance to revenue and risk.
It outlines four product types: consumable, non‑consumable, auto‑renewable subscription, and non‑auto‑renewable subscription, giving examples such as game currency, permanent levels/lifetime cards, and monthly/annual memberships.
The basic purchase flow is described: add a transaction observer (SKPaymentTransactionObserver) to the payment queue, fetch product details via SKProductsRequest using product IDs, create an SKPayment from the SKProduct and add it to the queue, then handle the transaction in the observer to obtain a receipt.
Two methods for obtaining the receipt are presented: (1) per‑transaction receipt and (2) iOS 7+ aggregated receipt (including subscriptions), with notes on using SKReceiptRefreshRequest to get the latest receipt.
Receipt verification must be performed on the server side, sending a Base64‑encoded receipt to Apple’s verification endpoint; client‑side verification is discouraged to avoid man‑in‑the‑middle attacks.
After successful verification, the game server delivers the purchased item to the user.
The advanced section covers order binding (matching receipts to internal order IDs using a stack keyed by product ID, stored via sandbox/keychain), a补单机制 (retry queue for failed receipt uploads), handling duplicate receipts by tracking transaction IDs, and specifics for non‑consumable and subscription products (restoreCompletedTransactions, expiration dates, introductory/ promotional offers).
Exception handling distinguishes network errors (NSURLErrorDomain) from IAP errors (SKErrorDomain), detailing cases such as device unable to pay, product request failures, payment cancellation/failure/deferral, and provides guidance on appropriate user feedback.
The article concludes by summarizing the three‑step IAP workflow—publish product, purchase product, provide product—and notes that understanding this flow helps developers manage both common and edge‑case scenarios in game SDK integration.
37 Interactive Technology Team
37 Interactive Technology Center
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.