powered by

How payments and subscriptions work

Updated Sep 30, 2026
AnythinkPay runs Stripe and Apple in-app purchases behind one subscription and entitlement model, so your app checks access one way for both.

AnythinkPay is Anythink's built-in payments and subscriptions system. It takes one-off payments and runs recurring subscriptions through Stripe (web and non-digital mobile purchases) and Apple in-app purchases (iOS digital goods), and gives your app one entitlement check that works regardless of which provider a subscriber paid through.

This page is the mental model. To take your first payment, start with Sell a subscription in 15 minutes.

The moving parts

Part What it is
Plan A subscription product you define once: name, price, billing interval, trial length, and (optionally) an Apple product id. Stored on your project as anythink_subscription_plans.
Subscription One subscriber's instance of a plan: status, current period, provider, and the user it's linked to.
Payment A single charge — a one-off payment, or a subscription's recurring invoice — with amount, status and provider fee.
Subscription event An append-only history entry for a subscription: created, renewed, cancelled, refunded, plan changed, and so on. Powers the timeline in AnythinkPay › Subscriptions.
Offer A referral or promotional programme: personal codes, redemption rules, and rewards (bonus trial days or account credit).
Entitlement The answer to "can this user access the paid feature right now" — one read that works across providers and includes the app's own free trial.

Plans, payments and subscriptions are visible in your project as read-only-by-default entities (anythink_subscription_plans, anythink_payments, and so on) so you can list, filter and build materialised views over them like any other data — see Payments recipes.

One model, two providers

A subscriber can pay through Stripe or through Apple; from your app's point of view, both produce the same shape: a Subscription row with a provider (stripe or apple), a status, and a current_period_ends_at.

  • Stripe runs through Stripe Connect, so payments settle directly into the project owner's own Stripe account — Anythink is a connected platform, not the merchant of record. See Take payments with Stripe.
  • Apple in-app purchases verify StoreKit 2 signed transactions server-side and bind them to the calling user. See Verify Apple in-app purchases.

Whichever provider a subscription came from, the same access rule decides whether it currently grants access:

Status Access
active, trialing, grace_period Yes
cancelled (auto-renew off), in_billing_retry / past_due Yes, until current_period_ends_at passes
revoked, expired, unpaid No
Anything else No — an unrecognised status fails closed

Your app doesn't need to reimplement this table: call GET /org/{orgId}/integrations/anythinkpay/subscriptions/me/entitlement and read has_access. See Offer codes, free trials and entitlements.

The payments service and the main API

AnythinkPay is split across two services, and the split matters for what each one does:

  • The main Anythink API (the one every other /org/{orgId}/... endpoint in this documentation uses) holds your plans, checks your project's permissions, and is what the dashboard, CLI and your app call. It proxies subscription, payment and offer operations through to the AnythinkPay payments service and merges the result with project-local data — for example, which of your users a subscription is linked to.
  • the AnythinkPay payments service is Anythink's dedicated payments service. It holds the subscription, payment, offer and balance ledger, talks to Stripe and Apple directly, and receives their webhooks. You never call the AnythinkPay payments service directly — every request goes through the main API, which is where your permissions and row-level security are enforced.

This split is why a payments feature can be briefly unavailable even when the rest of your project works fine: if the AnythinkPay payments service is unreachable, subscription and payment endpoints return a 502 rather than silently failing. Plan creation and listing don't depend on the AnythinkPay payments service being reachable, since plans are stored on the main API; anything that touches a live subscription, payment or offer does.

Webhooks and notifications

Provider events land on the AnythinkPay payments service, not on your project:

  • Stripe webhooks (checkout.session.completed, customer.subscription.updated, invoice_payment.paid, payment_method.attached, account.updated, and others) update the subscription or payment row, then AnythinkPay relays a matching workflow event (PaymentSucceeded, PaymentFailed) to your project so a workflow can react. See Take payments with Stripe and Payments recipes for a worked example.
  • Apple App Store Server Notifications (V2) (DID_RENEW, EXPIRED, REFUND, DID_CHANGE_RENEWAL_STATUS, and others) update the matching subscription by its Apple originalTransactionId, append a subscription event, and record a payment for revenue-generating notification types. See Verify Apple in-app purchases.

You configure your own Stripe account and Apple credentials; Anythink doesn't see or store your customers' card details, and Apple's private key is encrypted at rest.

Limits

Limit: Apple in-app purchases are iOS-only. Android has no equivalent purchase provider in AnythinkPay today — Android and web both go through Stripe checkout.

Limit: Team and per-seat subscriptions (one buyer, multiple entitled users) aren't supported. Every subscription belongs to one subscriber; sharing access to a subscription happens through the subscription's user list (PUT /subscriptions/{id}/users), not through a billing-level seat count.

Limit: Re-syncing a subscription's live status from the provider (AnythinkPay › Subscriptions › Resync) only works for Stripe subscriptions today. Apple subscriptions rely on App Store Server Notifications arriving; there's no on-demand Apple status pull yet.

Note: A subscriber's /me/entitlement call doesn't depend on the AnythinkPay payments service for users who have never subscribed — the app engagement trial is resolved entirely from project data. Once a user has subscribed at least once, entitlement needs the AnythinkPay payments service to be reachable.

Next steps

How payments and subscriptions work | Anythink Docs