A recurring payment charges the same payer the same amount on a schedule. Each occurrence mints a payment link and emails it to the payer, so the payer confirms every charge in their bank - there is no stored mandate pulling funds silently.
Under the hood each recurring payment is an auto-generated workflow, which is why the identifier you work with is a definition_id and why occurrences show up as workflow runs.
Creating and editing
Create is find-or-create: a payload whose amount, recipient, project, and description match an existing recurring payment re-schedules that one instead of creating a duplicate. That makes a retried create call safe.
The cadence is expressed as day_of_month plus hour and minute. PATCH edits amount, recipient, and cadence in place on an existing definition.
Pausing, resuming, retrying
| Action | Effect |
|---|---|
disable | Stops future occurrences. Run history is kept. |
enable | Resumes a previously disabled recurring payment. |
retry | Mints a fresh checkout link for an outstanding occurrence and emails the payer a reminder with a retry link. |
GET /recurring-payments lists your definitions and takes a status filter of active, disabled, or all.
In this section
| Endpoint | What it does |
|---|---|
POST /recurring-payments | Create a recurring payment, or reuse a matching one |
GET /recurring-payments | List recurring payments, filterable by status |
GET /recurring-payments/{definition_id} | Fetch one recurring payment |
PATCH /recurring-payments/{definition_id} | Edit amount, recipient, or cadence |
POST /recurring-payments/{definition_id}/disable | Stop future occurrences |
POST /recurring-payments/{definition_id}/enable | Resume |
POST /recurring-payments/{definition_id}/retry | Retry an outstanding occurrence |