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.
Elements-collected subscription	Custom signup page with card, Apple Pay, or Google Pay and an immediate first payment.	Your frontend owns the form; Paypercut hosts secure card and wallet collection.	Customer, recurring Price, SDK 1.4.1, Elements in `subscription` mode, and backend creation with `error_if_incomplete`.	Payment Method, first payment, and active Subscription after successful authorization.	`customer_id`, `payment_method_id`, `subscription_id`, `price_id`, invoice IDs.	Authenticated active create response and invoice events.	You need a trial/deferred first charge with a freshly collected method, or want Paypercut to own the complete signup form.
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 payment details and you have not implemented an Elements or Checkout collection step.
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 Elements with direct API creation when you need card or wallet collection on your own page and the first payment is due immediately. Use the direct API by itself 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.

Elements-collected subscriptions

Use Elements when you need to own the signup page and collect a new card, Apple Pay, or Google Pay method before your backend creates the Subscription. Create the Elements Group with mode: 'subscription'; the mode prepares authentication for off-session renewal use but does not create a Subscription, attach a Customer, or charge the customer.

Use @paypercut/checkout-js 1.4.1 or later for subscription-mode Express Checkout. The backend must use error_if_incomplete with an immediate, non-zero first payment to prepare the fresh method for recurring use. This flow does not cover trials or deferred first charges. See Create subscriptions with Elements for both wallet and card collection paths.

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 Elements with direct creation if:

the customer is providing a new card or wallet method on a custom signup page;
your backend has or can resolve the Paypercut Customer;
your frontend can use Elements in subscription mode;
your backend can create the Subscription with an immediate first payment and error_if_incomplete, and process invoice events.

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