Model plans, trials and offers once, then take payment through Stripe or Apple in-app purchases without writing receipt-validation code.
Every task works three ways, and all of them change the same project. Here's one: a monthly plan with a seven-day free trial.
The Anythink dashboard
Fill in the plan once. It syncs to Stripe when Connect onboarding is complete.
The Anythink CLI
Plans go through the AnythinkPay API, so a script can create them.
$ anythink fetch /integrations/anythinkpay/subscription-plans --method POST --body \'{"plan_name":"Pro monthly","name":"Pro monthly","description":"Full access","type":"recurring","amount":9.99,"currency":"gbp","billing_interval":"month","interval_count":1,"trial_period_days":7,"is_active":true}'Claude, through MCP
Describe the plan. It calls the same API and reports what it created.
you › “Create an AnythinkPay subscription plan called Pro monthly at £9.99 a month with a 7-day trial.”
Idempotent by design
Apple receipt verification keys off the purchase's original_transaction_id. Re-verifying the same purchase, or a renewal coming back around, updates the existing row instead of creating a second subscription.
A timely reason to avoid extensions
After that date, Firebase Extensions can't be installed or edited, which pushes Stripe and Apple IAP handling on Firebase into custom Cloud Functions. Anythink's payment handling is native, not an extension that can be deprecated.
| Capability | Anythink | Supabase | Firebase |
|---|---|---|---|
| Stripe subscriptionsSupabase: Stripe sync engine or a webhook recipe. | Built in | Add-on, extension or DIY recipe | |
| Apple in-app purchasesFirebase: via the RevenueCat extension, which Extensions sunsets 31 March 2027. | Built in | Not available | Add-on, extension or DIY recipe |
| Server-side receipt verification | Built in | Not confirmed | Add-on, extension or DIY recipe |
| Admin recovery (status override, resync) | Built in | Not confirmed | Not confirmed |
● Built in◐ Add-on, extension or DIY recipe– Not available? Not confirmed
Sourced from each vendor's own docs as of 28 September 2026. "Addon" means an extension, plugin or code recipe rather than a feature of the core platform.
Plans, trials, discount codes, Stripe and Apple in-app purchases, all on the same subscriber record.
Define subscription plans with billing intervals and trial periods, then layer on offer and discount codes for redemption and referral programmes.
Take card payments and recurring billing through Stripe, or split funds across a marketplace's sellers with Stripe Connect. Webhooks are handled for you.
Receipts are verified against the real App Store Server API, not trusted from the device. Verification is idempotent, upserting by the transaction's original_transaction_id, so a renewal or a retried request never creates a duplicate subscription.
Apple verification checks the purchase's appAccountToken against the account that submitted it. A receipt replayed against a different account is rejected, closing a common in-app purchase replay gap.
Your app asks a subscriber-scoped /me endpoint whether the signed-in user has access, offer codes, referrals and balance. These routes use a subscriber permission, not an admin one, so you can call them directly from a client app.
When a payment provider and your data disagree, an admin can override a subscription's status, relink it to the right subscriber, or resync it from Stripe, from the Anythink dashboard.
In practice
POST https://api.my.anythink.cloud/org/{org_id}/integrations/anythinkpay/subscription-plans Content-Type: application/json { "plan_name": "pro-monthly", "name": "Pro Monthly", "description": "Full access, billed monthly", "amount": 19.00, "currency": "gbp", "billing_interval": "month", "trial_period_days": 14 }
What you can build
Sell a subscription through Apple in-app purchase. Anythink verifies the receipt against the App Store, binds it to the signed-in account, and keeps renewals from duplicating the entitlement. Your app just asks /me whether access is active.
Set a trial period on the plan, so new subscribers get full access for 14 days before the first Stripe charge. Offer codes extend a trial or discount the first invoice for a referral programme.
Route a buyer's payment to a seller through Stripe Connect and take a percentage automatically. Configure the split once; every transaction after that follows it.
Yes. Anythink verifies App Store receipts server-side against Apple's real App Store Server API, not just by trusting the device. Verification is idempotent, so renewals and retried requests don't create duplicate subscriptions, and each purchase is bound to the account that made it.
For the core job, yes: server-side Apple IAP verification with account binding, plus Stripe subscriptions, in one backend. Bulk Apple subscription status syncing and team (seat) subscriptions are planned.
Yes. The /me endpoints are scoped to a subscriber permission rather than an admin one, so your client app can call them directly to check entitlement, offer codes, referrals and balance for the signed-in user.
An admin can override a subscription's status, relink it to a different subscriber, or resync it from Stripe, all from the Anythink dashboard. For an Apple purchase, re-verifying the receipt brings the subscription back in line.
Yes, with Stripe Connect. Configure the split in Anythink and payments route to your sellers with your platform fee taken automatically.
Still have questions?
Get in TouchEvery feature reads from the same data model, so each one you add works with the rest.
The dashboard, the CLI, MCP and the SDK, plus guides for moving from other platforms.
How founders, agencies and enterprise teams use Anythink.
Guides and reference at docs.anythink.cloud.
Connect Stripe, create plans and offers, and verify Apple in-app purchases, all in the same project as your data.
