How payments and subscriptions work

AnythinkPay is the payments and subscriptions system built into every project. It takes one-off payments and runs recurring subscriptions through Stripe (web, Android and non-digital purchases) and Apple in-app purchases (iOS digital goods). Both end up as the same subscription record, so your app asks one question, "does this user have access?", whichever provider they paid through.

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

The moving parts

A subscription copies its price, interval and trial length from a plan when you create it in the dashboard. Apple subscriptions are matched to a plan by the plan's Apple product ID.

One model, two providers

From your app's point of view a Stripe subscriber and an Apple subscriber look the same: a subscription with a provider, a status and a current_period_ends_at. One rule turns the status into access.

You don't re-implement this table. Call GET /org/{project_id}/integrations/anythinkpay/subscriptions/me/entitlement and read has_access. The same rule decides it for both providers. See Offer codes, free trials and entitlements.

The lifecycle of a Stripe subscription

1. You connect Stripe and create a plan. See Sell a subscription in 15 minutes.
2. A subscription is created for a subscriber, and they complete Stripe Checkout. The subscription is incomplete until they pay.
3. Stripe tells Anythink the subscription is trialing or active. Anythink updates the subscription, records its history and raises Subscription Activated in your project.
4. Each renewal, Stripe reports the paid invoice. Anythink records a payment against the subscription.
5. If a renewal fails the status becomes past_due, and the subscriber keeps access until the period ends. If Stripe gives up it becomes unpaid.
6. If the subscriber cancels, auto-renew switches off and they keep access until the period ends. When Stripe ends the subscription its status becomes canceled, and Subscription Expired is raised.

The lifecycle of an Apple subscription

1. The subscriber buys in your iOS app, and StoreKit 2 returns a signed transaction.
2. Your app sends it to POST .../subscriptions/apple/verify. Anythink verifies it, links it to the signed-in user and returns the subscription with has_access.
3. Apple sends App Store Server Notifications to the URL you registered once. Renewals, refunds, expiries, billing retries and plan changes update the status and add subscription events.

Card numbers stay with Stripe and never reach Anythink. Apple's private key is stored encrypted and never read back.

Where the money goes

For Stripe, payments are paid out to your connected Stripe account, minus Stripe's processing fee and Anythink's platform fee.

To see the fees that apply to your project and try an amount, open Settings › Payments and choose the Fees & Calculator tab. This page doesn't repeat them, because that tab always shows the current figures.

Apple's payouts and fees are handled between you and Apple.

Webhooks into Anythink

You don't build a webhook endpoint for payments. Provider events arrive at a payments service that Anythink runs.

• Stripe sends events for your connected account. Anythink verifies each one, then updates the matching payment, subscription or saved payment method. Events it doesn't act on are acknowledged and ignored.
• Apple sends App Store Server Notifications V2 to a URL you register once in App Store Connect. Anythink shows the URL on the Apple tab of Settings › Payments.

For the list of Stripe events, the Apple setup steps and the workflow events they raise, see Webhooks.

Events your workflows get

After Anythink records a Stripe change, it raises a matching event in your project and delivers it with a signature your project checks. Start a workflow from one with an Event trigger. See Triggers and scheduling.

For these events $anythink.trigger.id is 0, so read everything from $anythink.trigger.data. Field names are snake_case. A payment has id, type, provider, amount, currency, status, description, reference, paid_at, metadata and payable_id, the id of the Anythink user it is attributed to. A subscription has id, name, type, amount, currency, billing_interval, status, provider, current_period_ends_at, trial_ends_at and subscriber_id, the id of the subscriber.

If your project can't be reached when an event is delivered, Anythink retries up to five times, waiting 30 seconds, then 1, 2, 4 and 8 minutes.

Payments recipes has workflows for the common cases.

What your app calls

Your app calls AnythinkPay through your project's API, as the signed-in user, never straight to the payments service. Every call below needs only the anythink_subscription_plans:read permission, so a subscriber's own token works and your app never needs an administrator key or an API key.

Every path starts /org/{project_id}/integrations/anythinkpay. Give the role your subscribers use the permission first. Payments recipes shows how.

What the entitlement call returns

If a user has several subscriptions, the call returns the strongest one: one that grants access first, then the one that runs longest. A user who has never subscribed is resolved from the app's free trial, which needs no call to the payments service.

The app's free trial

Separate from a plan's own trial, you can give every user who has never subscribed one free window of access. Turn it on under Growth › Engagement and set its length in days. It starts the first time that user calls the entitlement endpoint, runs once per user and never restarts. A promo code with a trial reward adds days to it. Payments recipes has a worked example.

Limits

Next steps