Built on StoreKit 2, so this rail covers iOS 15+, iPadOS 15+, and macOS 12+. Older StoreKit 1 receipts are not required. CashSDK works directly with the signed transactions StoreKit 2 issues.
Apple App Store
Connect App Store Connect so StoreKit 2 purchases and subscriptions are verified server-side and resolve to CashSDK entitlements.
The App Store (through StoreKit 2) is the billing rail for in-app purchases and subscriptions on iOS, iPadOS, and macOS. CashSDK verifies every StoreKit transaction and every App Store Server Notification against Apple on your server, so an entitlement is only ever granted from a signed, authentic purchase and never trusted on the device alone.
How it works#
1
StoreKit runs the purchase
The iOS SDK presents the offering and drives Apple's native
purchase sheet. StoreKit returns a signed Transaction.
2
CashSDK verifies it server-side
The SDK forwards the transaction to CashSDK, which validates Apple's signature with the App Store Server API before granting anything.
3
Notifications keep it current
Apple sends App Store Server Notifications V2 to CashSDK for every renewal, refund, grace period, and cancellation, so entitlements stay accurate for the whole subscription lifecycle, even when your app is closed.
Prerequisites#
- A paid Apple Developer Program membership.
- An app record in App Store Connect with a bundle ID.
- The Account Holder or an Admin role, so you can create an App Store Connect API key and edit agreements.
- A signed Paid Applications Agreement (App Store Connect → Business). In-app purchases will not load until it is active.
Connect App Store Connect#
CashSDK talks to Apple with an App Store Connect API key, a .p8 private key
plus its issuer ID and key ID. This lets CashSDK verify transactions and read the
subscription status of your customers.
1
Create an In-App Purchase API key
In App Store Connect, go to Users and Access → Integrations → App Store
Connect API and create a key with the In-App Purchase role (this is the
key type scoped for the App Store Server API). Download the .p8 file now. Apple
only lets you download it once.
2
Add it to CashSDK
In your CashSDK dashboard, open Settings → Billing → Apple App Store and
enter your Issuer ID, Key ID, and upload the .p8 file. It is
stored encrypted at rest and is never exposed to your app.
Also set your Bundle ID and, for App Store Server Notifications, your
Apple App ID (the numeric 1234567890 from the App Information page).
The dashboard's setup checklist confirms each field is valid before you go
live.
3
Point App Store Server Notifications at CashSDK
Copy the notification URL from Settings → Billing → Apple App Store in your dashboard. In App Store Connect, open your app → App Information → App Store Server Notifications and paste it into both the Production Server URL and the Sandbox Server URL, selecting Version 2 notifications.
Prefer not to click through it? The CashSDK onboarding wizard and the
MCP server can drive this end to end. The
request_apple_test_notification tool even asks Apple to send a test
notification so you can confirm the connection before shipping.
Create your products#
Create your in-app purchases and subscriptions in App Store Connect, then map them to CashSDK.
1
Create products in App Store Connect
Under Monetization → Subscriptions (or In-App Purchases), create each
product and give it a Product ID, for example pro_monthly. Fill in the
price and localizations, and submit them for review with your next build.
2
Map them to entitlements in CashSDK
In CashSDK, create a product with the same
identifier and attach the entitlement it unlocks
(for example pro). You can sync the catalog automatically:
bash
sync_catalog_from_app_store(store="app-store", dryRun=true)
Run it without dryRun to import your App Store products as CashSDK products
in one step.
Integrate the SDK#
Once the catalog is mapped, the iOS SDK does the rest: purchase, verification, and entitlements, with no App Store plumbing in your app code.
swift
import CashSDK
CashSDK.configure(publishableKey: "csk_pk_…")
switch try await CashSDK.shared.purchase("pro_monthly") {
case .success(let entitlements):
if entitlements.isActive("pro") { unlockPro() }
case .pending, .userCancelled:
break
}
Under the hood the SDK verifies the StoreKit transaction server-side before the
entitlements in that result are returned. See
Receipt validation for what happens on the server.
Test in the sandbox#
1
Create a sandbox tester
In App Store Connect, go to Users and Access → Sandbox → Testers and add a sandbox Apple ID. On the device, sign in under Settings → Developer → Sandbox Apple Account.
2
Run a purchase from a development build
Configure the SDK with your csk_pk_… key, the same key you ship. A build
run from Xcode or TestFlight transacts against Apple's sandbox automatically,
so purchases complete without a real charge, and renewals run on Apple's
accelerated sandbox clock (a month renews in minutes), the fastest way to
watch the whole lifecycle.
3
Confirm entitlements and notifications
Verify the purchase grants pro, then check Events in your dashboard for
the incoming purchase.completed and, on renewal, subscription.renewed
events driven by the sandbox App Store Server Notifications.
Sandbox and production notifications use separate URLs in App Store Connect. Set both. CashSDK records the true environment on each transaction, so sandbox purchases never mix into your production revenue. See Testing.
Go live#
Before you ship:
- The Paid Applications Agreement is active.
- Products are Approved (or submitted with your build).
- The Production App Store Server Notification URL is set to V2.
- The app's numeric App Store App ID (
appleAppId) is set: Apple rejects every Production purchase without it.
The dashboard's setup checklist (get_setup_checklist) turns green when each of
these is satisfied.