1. Developers Portal
  2. Engineering Blog

Subscriptions with Open Payments, a Test Network PoC

Written by Adi Boros

Open Payments is already a strong fit for one-time checkout. The more interesting technical question is what happens when a payment is no longer a single event, but a continuing authorization and billing relationship: a buyer authorizes once, a merchant needs to initiate charges again later, and the surrounding platform has to manage renewals, failed collections, re-authorization, and state visibility without weakening user trust.

That question is the basis for this proof of concept.

This work started as an implementation-driven investigation. If Open Payments can support recurring payments with clear authorization semantics, durable billing state, and safe re-authorization behavior, it becomes substantially more credible as infrastructure for merchant use cases beyond one-time payments.

Why explore subscriptions now?

One-time payments dominates the online retail market, and most payment infrastructure is still optimized around the one time payment purchases. In this flow, the core question is immediate and transactional: can the buyer authorize and complete payment successfully now?

Subscription systems introduce a different class of requirements. The first checkout is only the entry point into a longer-running billing relationship, and the complexity emerges after that initial authorization has been granted. A recurring commerce implementation needs to answer a set of harder protocol and platform questions:

These are not incidental implementation details. They are the difference between a payment demo and a subscription-capable system.

That is why the Open Payments grant model is particularly relevant here. In this PoC, subscription behavior is anchored to the Outgoing Payment Grant interval field. Because that field uses the ISO 8601 recurring interval format, recurrence is represented in a form that is both standardized and machine-interpretable. The result is that subscription cadence is not merely stored in merchant metadata or reconstructed from application logic; it is carried by the authorization structure itself. Combined with grant-scoped amount constraints, this creates a clearer foundation for reasoning about recurring payment authority over time: what can be charged, on what cadence, and under what bounded authorization conditions.

That distinction is the real motivation for the Test Network experiment. The goal is to evaluate whether Open Payments provides the primitives needed to model recurring billing in a way that remains easy to read at the protocol level, enforceable at the platform level, and understandable to both merchants and payers.

Baseline Test Network architecture before subscriptions

Before this experiment, Test Network already had two visible product surfaces:

For simplicity the we don’t surface a store backend to manage the product catalog and orders.

The baseline architecture looked like this:

The Test Network Architecture Diagram View full image

In that initial shape, the system was already useful, but the commerce side was intentionally simpler.

That meant the order and payment lifecycle remained bounded to one buyer interaction.

One-time payment flow in the baseline system

The one-time boutique purchase flow is:

The Test Network One Time Payment Boutique Baseline Flow Diagram View full image

This flow is important because it highlights the boundary of the original design: the business object is the order, and the order exists to complete one checkout attempt. Once the payment succeeds or fails, the flow is effectively over.

That is very different from subscriptions, where the first authorization has to survive past the first payment and support future billing attempts that happen later and often without the buyer being actively in the storefront.

What the subscription PoC tries to prove

The subscription PoC asks whether Open Payments can support a recurring billing model rather than only a one-time checkout flow, without requiring the surrounding commerce system to replace its existing order and payment ledger.

More concretely, the experiment tries to prove that subscriptions can be built coherently on top of Open Payments and still:

Test Network is the environment used to run this experiment end to end. The goal is not to declare the production architecture finished. The goal is to test how a subscription engine could be built on top of Open Payments.

PoC system overview

The experiment introduces a new long-lived business object, a renewal processor, and a stronger runtime connection between Boutique and Wallet.

The Test Network Open Payments Subscriptions Architecture Diagram View full image

The key architecture change is that Boutique becomes the source of truth for subscription lifecycle state, while Wallet composes boutique subscription data with wallet transaction data to present buyer and merchant views.

That is an important design choice. We did not introduce a separate subscription system owned by Wallet. We extended Boutique’s commerce domain and allowed Wallet to consume and present it.

Data model and ownership changes

The PoC adds recurring-commerce concepts without replacing the existing order and payment model.

Two design decisions make the model more practical.

Subscription activation flow

The first subscription purchase deliberately mirrors the existing one-time checkout where possible, but adds a durable subscription record before the buyer leaves the boutique UI.

Subscriptions Activation Flow Diagram View full image

This sequence does two things that the baseline system never needed to do.

That is the point where recurring commerce stops being a checkout variation and becomes a lifecycle problem.

Renewal and past-due recovery

Once a subscription is active, the system needs to bill again later without forcing the buyer through the full interactive flow each time.

The PoC handles that with a subscription processor in Boutique. It checks for due subscriptions, locks one subscription row, creates the next order, and reuses stored authorization to bill again.

Operationally, the branch behaves like this:

The recovery flow is explicitly split between authorization repair and actual money movement.

Subscriptions Retry Flow Diagram View full image

This separation is a strong property of the PoC. Re-authorization refreshes the buyer’s grant, but does not automatically charge them as a side effect. The actual retry remains a distinct action. That keeps user intent clearer and reduces the risk of surprising money movement after an authorization repair.

That separation is also visible in the wallet UI, where subscription status, billing context, and recovery actions are shown together instead of being hidden behind backend state alone.

Subscription detail view in a PAST_DUE state with separate re-authorize and retry actions

Subscription detail view showing a PAST_DUE subscription with re-authorize and retry presented as separate user actions.

Subscription state model

The lifecycle now spans multiple user interactions and background jobs instead of a single checkout.

Subscriptions State Model Flow View full image

Compared with one-time purchases, this is the real architectural jump. The system must now reason about durable status, scheduled work, token lifetime, recovery behavior, and explicit user actions over time.

Component changes across the platform

Boutique backend

Boutique frontend

Wallet backend

Wallet frontend

This is where the PoC becomes concrete for users: the wallet does not just expose that recurring billing exists, it exposes the exact subscription state and the payment history that explains how that state was reached.

Subscription detail view with payments history

Subscription detail view showing a daily subscription service with daily payments in the payment history section.

Development wiring

Why this PoC is meaningful for Open Payments

The value of this experiment is not that it adds another product type to the boutique catalog. The value is that it exercises the parts of Open Payments capabilities that are not used by the one-time payment flow that the boutique checkout flow had.

Subscriptions force the platform to answer harder questions:

In that sense, subscriptions are a better systems test than one-time payments. A successful one-time flow proves interactive authorization and payment execution. A successful subscription flow proves that the same ecosystem can support long-lived commercial intent, asynchronous renewal, and explicit recovery without collapsing into unclear ownership or unsafe automation.

Benefits, trade-offs, and open questions on the PoC build on top of Test Network platform.

The experiment branch introduces clear benefits.

It also introduces real trade-offs.

And the PoC still leaves follow-up questions and TODOs for anyone who wants to build an Open Payments enabled subscription system later.

Closing

I believe this Open Payments subscription PoC is relevant because it shows the Open Payments support for recurring payments.

This PoC implementation is available in the Test Network repository in the subscriptions-poc branch. It is experimental and intended as a reference for the architecture and flows described here, not as a production-ready subscription framework.

As we are open source, you can easily check our work on GitHub. If the work mentioned here inspired you, we welcome your contributions. You can join our community slack or participate in the next community call, which takes place each second Wednesday of the month.

If you want to stay updated with all open opportunities and news from the Interledger Foundation, you can subscribe to our newsletter.