End Trial Now
End a TRIALING subscription’s free trial immediately and charge the first paid period now.
Converts the subscription straight to ACTIVE (the normal outcome), or to
PAST_DUE if the first charge declines, or ACTIVE_UNSETTLED if the charge needs
async completion (3DS / ACH). The resulting state on the returned subscription
is how the caller tells success from a decline or a pending 3DS step — this
endpoint returns 200 in all three cases, because the trial really did end.
This brings the scheduled trial->active conversion forward: it reuses the same
activation path as POST /{subscription_id}/activate, differing only in that it
sets trial_end = now first so the conversion actually runs today instead of at
the original trial end.
Only valid while the subscription is TRIALING. Calling it on an already-converted (or otherwise non-trialing) subscription returns 409, which also makes a repeat call safe: the second call 409s instead of charging a second time.
Works for both User and API Key authentication. Account access is automatically validated via endpoint dependency.
Authentication
Bearer authentication of the form Bearer <token>, where token is your auth token.
Path parameters
Response
The possible states of a subscription.
Most are self-explanatory: it starts INCOMPLETE (created, not yet paid for), or TRIALING / SCHEDULED, becomes ACTIVE once paid, and can end up PAUSED, PAST_DUE (a payment failed), or CANCELLED.
ACTIVE_UNSETTLED is the unusual one, added for slow bank rails like SEPA where the money does not arrive until days later. It means: “we already let the customer in at checkout, but their payment has not actually settled yet.” A subscription is created straight into this state — nothing ever moves INTO it from another state. It has exactly two ways out: it becomes ACTIVE if the payment settles, or CANCELLED if the payment fails, times out, or is later reversed (a chargeback).
INCOMPLETE_EXPIRED is terminal, and is where a subscription ends up when its first payment never completed. It exists to say something CANCELLED cannot: this subscription was never really bought. A cancellation is a customer leaving something they had; an expiry is a purchase that never happened. Keeping the two apart stops “never converted” being counted as churn, and — because it is terminal — takes the subscription out of the duplicate-product guard, so the customer is free to try that purchase again.
Free-text note attached to this subscription. Additive to description: read/written inline here as a convenience, and backed by the same /notes record (one note per object).
Refund options when cancelling a subscription.
- NONE: Cancel with no refund (current behavior)
- FULL: Refund full current period amount
- PRORATED: Refund unused portion of current period
- CANCEL_UNPAID: Use dunning_end_behavior for unpaid invoices
Details about why a subscription was cancelled.
All fields are optional — callers can provide any combination. Stored as JSONB on the subscription entity.
Per-processor FULL statement descriptor override map (Adyen and Checkout.com), keyed by processor id.
ID of the processor that last successfully charged this subscription. Historical record only — the next charge is routed by the payment method’s own processor attempt history, which may differ if the payment method has since changed.
ID of the subscription this was split from (cross-interval plan change).
IDs of subscriptions created from this one (cross-interval plan change).
Custom field values. Only included when expand=custom_fields is specified.