You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The work is split into two independent PRs for receiving and sending recurring payments, followed by a shared integration PR that builds on both. Each PR documents its own implementation details and remaining work.
Enable receiving and tracking recurring payments, with persistent records linking offers to their payers. This includes payment progress, pending claims, cancellation status, and lookup and list APIs.
The implementation preserves progress across restarts and event replay, prevents duplicate payments for the same period, and allows already accepted payments to settle after cancellation.
Outbound Recurrence
Enable sending and tracking recurring payments through manual operations to initiate a relationship, pay the next period, retry failed payments, and cancel future payments.
Persistent records retain the offer, payment settings, progress, and continuity state needed for subsequent payments. Lookup and list APIs let applications inspect and manage these relationships across restarts.
Shared Integration
Build on both directions to complete the recurrence lifecycle. This work follows once the inbound and outbound PRs are stable.
The scope includes restart reconciliation, payment-window tracking, missed and completed transitions, and optional automatic outbound payments. It also exposes recurrence functionality through UniFFI and adds end-to-end coverage across both directions.
The inbound (#1205) and outbound (#1207) recurrence PRs are independent and can be reviewed and merged in either order. The third PR, covering shared logic for restart reconciliation, payment-window tracking, and recurrence scheduling, will build on both.
Would love your thoughts on whether I should start the shared PR now to get a complete draft of the recurrence implementation ready, or wait until the design of the first two has settled to reduce potential rework.
Activity
shaavan commentedon Oct 26, 2026
@tnull
Following up on the offline discussion:
The inbound (#1205) and outbound (#1207) recurrence PRs are independent and can be reviewed and merged in either order. The third PR, covering shared logic for restart reconciliation, payment-window tracking, and recurrence scheduling, will build on both.
Would love your thoughts on whether I should start the shared PR now to get a complete draft of the recurrence implementation ready, or wait until the design of the first two has settled to reduce potential rework.