Choose a flow

Use this page to choose the right subscription creation path before you build.

Most beginner integrations should use Checkout-created subscriptions because Checkout collects the customer's payment details and saves a reusable payment method for future renewal billing.

What this page covers

The main subscription creation paths
Which actor owns the customer-facing step
Required prerequisites
What IDs and events matter for each flow
When not to use each path

Flow comparison

Flow	Best for	Customer-facing owner	Prerequisites	What gets created	Store	Access signal	When not to use
Checkout-created subscription	First integration, hosted or embedded signup, customer enters payment details.	Paypercut Checkout, started by your frontend or backend.	Recurring Price and a Checkout Session in `subscription` mode.	Checkout Session, subscription, reusable payment method, invoices, payments.	`customer_id`, `price_id`, `checkout_session_id`, `subscription_id`, invoice IDs.	`invoice.paid` for paid-period access; `checkout_session.completed` for Checkout completion and session retrieval.	Your backend already has a customer and reusable payment method and does not need Checkout.
Direct subscription creation	Backend-created subscriptions after the customer and reusable payment method already exist.	Your backend.	Customer, reusable payment method, recurring items.	Subscription, invoices, payments depending on payment behavior.	`customer_id`, `subscription_id`, `price_id`, invoice IDs.	Invoice events and retrieved subscription state.	The customer still needs to enter or confirm payment details.
Subscription schedule	Advanced planned changes such as future starts, intro pricing, or fixed-duration plans.	Usually your backend.	Schedule phases and subscription inputs.	Schedule first, then a linked subscription when a phase creates or manages it.	`schedule_id`, then `subscription_id` when available.	Invoice events after the subscription exists.	You only need a simple recurring plan.
Trial or future-anchor direct subscription	Delayed billing or trial access where the product policy is already defined.	Your backend.	Customer, reusable payment method, trial or anchor configuration.	Subscription before normal paid renewal begins.	`subscription_id`, billing dates, invoice IDs when created.	Depends on your trial policy and invoice events.	You have not defined whether trialing access should be granted.

Beginner recommendation

Use Checkout-created subscriptions when the customer needs to enter or confirm payment details. This path gives you a customer-facing signup flow and avoids building payment-method collection before you have the core subscription lifecycle working.

Use the direct API later when your backend already has the customer and reusable payment method. Use schedules later when the billing plan needs phases.

When each path is not a fit

Use this section to rule out paths without treating them as unsafe or advanced by default. A path is the wrong fit only when the objects you already have, the customer action you need, or the access signal you plan to trust do not match that path.

Checkout-created subscriptions

Checkout is usually the first path to build, but choose another path when:

your backend already has a Customer and reusable payment method, and there is no customer-facing signup step;
the subscription should start from a backend migration, admin action, or provisioning workflow;
the billing plan needs phase changes that should be scheduled before the subscription starts.

Even with Checkout, do not grant paid access from the success URL alone. Use checkout_session.completed to reconcile the session and invoice.paid to grant or extend paid-period access.

Direct subscription creation

Direct creation is useful when the setup work is already complete, but choose Checkout first when:

the customer still needs to enter or confirm payment details;
your backend has only a Setup Intent, setup Checkout Session, or tokenization result and has not created the subscription yet;
your frontend would show success immediately after payment-method setup instead of waiting for subscription creation and invoice/payment confirmation;
your backend is not ready to process invoice events and retrieve subscription state after creation.

A successful setup flow means the customer has provided a reusable payment method. It does not mean a subscription has started, that the first invoice was paid, or that product access should be granted.

Subscription schedules

Schedules are useful for planned billing changes, but choose a simpler path when:

the customer is buying one recurring plan that starts now;
there is no future start date, phase change, intro period, or fixed-duration contract;
your backend is not prepared to store schedule_id first and subscription_id later after activation.

Schedule creation is not paid access proof. Wait until the schedule activates a subscription and use invoice events for paid-period access.

Trials or future anchors

Trials and future anchors are useful when delayed billing is part of the product design, but choose a normal paid start when:

the product should only unlock after the first successful payment;
your team has not decided whether trialing customers receive access;
your recovery flow is not ready for missing or failed payment methods when the trial or anchor ends.

trialing is a subscription state, not a universal access rule. Decide and implement the product policy before relying on it.

Decision checklist

Choose Checkout if:

the customer is signing up from your website or app;
Paypercut should collect card or payment details;
you want a hosted or embedded payment page;
the plan can be represented by a recurring Price-backed line item.

Choose direct creation if:

your backend already has the Paypercut Customer;
a reusable payment method already exists for that customer;
you can handle payment creation failures and subscription status reconciliation.

Choose schedules if:

the subscription starts in the future;
the plan has scheduled phase changes;
you need intro pricing or fixed-duration billing;
the simple Checkout path is not enough.

How subscriptions work

Quickstart: Create a subscription with Checkout