Recurring payments

Create plans, subscriptions, invoices, and billing cycles through the public API. Each collection is a normal payment intent, and the payer approves it whenever their payment method requires it.

1. 1
   Model the offer

   Create a customer, then a plan with its amount, currency, billing interval, and any trial days. A plan has no start date: billing periods start when the subscription's activation is confirmed, or when its trial ends, and repeat at the plan's interval. The plan's anchor_day is recorded with its terms but does not set a charge day, so read current_period_start and current_period_end from the subscription instead of calculating dates. Then POST /v1/subscriptions with the plan, customer, rail, return URLs, and an optional amount cap. Keep the IDs it returns.

2. 2
   Collect the payer's consent

   Send the payer to the one-time enrollment checkout. They check the consent box themselves, which records the terms version, amount, billing frequency, payment method, checkout, and first payment before the subscription can start.

3. 3
   Act on confirmed status

   Treat the subscription as active only after a success event or a server-side read. Use test clocks only in Sandbox, and read the new status after a pause, resume, cancel, or re-consent.