Subscriptions and recurring payments
July 30, 2026
Recurring billing with FlowAlp Pay subscriptions: subscription checkout, renewal webhooks, API management — and when tokenization fits better.
A subscription bills a customer automatically at a fixed interval: the customer authorizes the payment once on the hosted checkout, and FlowAlp Pay executes the renewals for you. This guide explains the subscription checkout, the webhooks around renewals, and how to manage running subscriptions through the API.
How subscriptions work
- You create a Gateway with the subscription parameters below; the customer authorizes the first payment on the hosted checkout.
- FlowAlp Pay debits the following installments automatically at the configured interval.
- Your system stays in sync through subscription webhooks — activation, renewals, failures and cancellations.
- You adjust or end the subscription via API or dashboard when plans change.
| Parameter | Description | Example |
|---|---|---|
subscriptionState | Enables subscription handling for the Gateway | true |
subscriptionInterval | Billing interval (duration string as in PHP DateInterval) | P1M = monthly |
subscriptionPeriod | Total duration of the subscription | P1Y = one year |
subscriptionCancellationInterval | Notice period within which the customer can cancel | P1M = one month |
Create a subscription checkout
The request is a normal Gateway creation with the subscription parameters. The amount (in minor units, CHF 29.00 → 2900) is charged once per interval:
curl -X POST "https://api.pay.flowalp.com/v1.16/Gateway/?instance=demo-shop" \
-H "x-api-key: $FLOWALP_API_SECRET" \
-H "Content-Type: application/json" \
-d '{
"amount": 2900,
"currency": "CHF",
"purpose": "Pro plan (monthly)",
"referenceId": "SUB-CUST-55021",
"subscriptionState": true,
"subscriptionInterval": "P1M",
"subscriptionPeriod": "P1Y",
"subscriptionCancellationInterval": "P1M",
"successRedirectUrl": "https://app.example.com/subscribe/success",
"failedRedirectUrl": "https://app.example.com/subscribe/failed",
"cancelRedirectUrl": "https://app.example.com/subscribe/cancel"
}'Not every payment provider supports subscriptions. Whether the option is available depends on your account configuration. Subscription checkouts can also be created without code via pay links.
Track renewals with webhooks
For subscription Gateways, FlowAlp Pay sends a subscription webhook (instead of a transaction webhook) whenever the subscription status changes. The payload contains status, valid_until — the next debit date —, paymentInterval, plus invoice and contact data. Configure your endpoint as described in Configure webhooks and see Webhook events and payloads for the exact shape.
| Status | Meaning |
|---|---|
active | The subscription is running; further charges will follow |
overdue | A charge failed and is being retried |
failed | Creation failed, or the retried charge failed again |
in_notice | The customer cancelled before the end date; the remaining charges still follow |
cancelled | Cancelled by the merchant with immediate effect; no further charges |
Manage subscriptions via the API
Adjust a running subscription — a plan upgrade, for example — with a PUT on the Subscription resource. The new amount applies from the next billing interval:
curl -X PUT "https://api.pay.flowalp.com/v1.16/Subscription/1234/?instance=demo-shop" \
-H "x-api-key: $FLOWALP_API_SECRET" \
-H "Content-Type: application/json" \
-d '{
"amount": 4900,
"currency": "CHF",
"purpose": "Business plan (monthly)"
}'Subscriptions can also be created server-side from an existing contact (POST /v1.16/Subscription/ with userId, psp, amount, currency, purpose, paymentInterval, period and cancellationInterval). All operations — including retrieving single subscriptions and listing them — are documented in the Subscriptions API.
The Subscription resource is flagged as experimental in the API documentation, and a dedicated cancellation endpoint is not documented there. Check the Subscriptions API page for the current state before building cancellation flows, and use the dashboard where the API does not cover your case.
Subscriptions or tokenization?
Subscriptions fit fixed, periodic billing: same amount, same interval, automatic renewals and customer-facing cancellation rules. If amounts change from period to period, billing dates are irregular, or you want full control over retries and dunning, build on tokenization instead and trigger every charge yourself — you implement renewals and cancellations, and you must handle failed charges in your code.
Next step: the Subscriptions API reference covers the create, retrieve and update operations — and webhooks keep your entitlement data in sync.