Recurring Payments

Status: conceptual, last checked 2026-11-02. No recurrence support exists.

A business bills a client 200 USDC on the first of each month for a year.

The pattern

The first design choice is who authorizes what:

Model	How it works	Trade-off
New invoice each period	The issuer signs a new SPORE and the payer approves each one	Simple, but needs an approval every time
Standing authorization	The payer signs once with an amount, schedule, recipient and end date	No repeat approvals, but it needs strong limits and easy revocation

Each period needs its own identifier, so a retry in March can’t pay February again or pay March twice.

Rules

Time decides state. A scheduled job checks elapsed time against the due date and moves an unpaid period to overdue. Don’t count attempts.
No polling providers. Payment state arrives through webhooks or chain events, and the scheduled job handles only reminders and give-ups.
Limits apply per period and in total. A standing authorization can’t be used to take a catch-up lump sum unless the terms allow it.
Expiry and revocation are checked before every period’s action.
Quote changes during a period need new approval if they exceed the signed limits.

Reminders, payment status and approvals across many periods are the job of the invoice manager in the product. The protocol only defines what is signed and verified.

Explore invoicing: Programmable Invoicing