1. Developers Portal
  2. Engineering Blog

Subscriptions with Open Payments, a Testnet 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 rather than as an extension of an existing reference design. At the time we began, there was no readily available Open Payments subscription proof of concept in this area that we could run, inspect, or extend. Test Network already provided a practical environment for experimenting with wallet flows, boutique checkout, and end-to-end integrations using test money, so it became the natural place to evaluate whether recurring commerce could be layered onto Open Payments in a way that was both technically coherent and operationally understandable.

From a protocol perspective, subscriptions are interesting because the recurring dimension is not purely an application-side construct. This PoC relies on the Outgoing Payment Grant interval field, as defined by the Open Payments authorization server API. That field follows the ISO 8601 recurring interval format, which means subscription cadence can be represented directly in the grant using a standardized machine-readable expression rather than inferred informally from merchant-side billing logic. In practice, this gives the authorization object explicit temporal structure: the grant can communicate not only how much value may be moved, but also the recurring interval against which that authorization should be interpreted. This is a significant property for subscription systems because it ties recurring billing behavior to protocol-level authorization semantics, rather than leaving cadence entirely to local implementation conventions.

Intro summary

Global ecommerce is large enough that even relatively narrow payment design questions have meaningful practical implications. Most of the sales volume is still driven by one-time purchases, where checkout begins and ends in a single user session. Subscription commerce is smaller in absolute terms, but it places pressure on very different parts of the payment lifecycle. The center of gravity shifts from initial authorization success to durable lifecycle management: recurring collection, grant reuse, expiry handling, retry policy, user visibility, and recovery after failure.

That makes subscriptions a useful systems-level test for Open Payments. A one-time checkout flow can demonstrate that the protocol works. A subscription flow tests whether the protocol can support a longer-lived commercial relationship with explicit state transitions, bounded authorization, and understandable recovery paths. 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-off 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 Testnet experiment. The goal is not simply to show that repeated charges can be scheduled. The goal is to evaluate whether Open Payments provides the primitives needed to model recurring billing in a way that remains legible at the protocol level, enforceable at the platform level, and understandable to both merchants and payers.

Those are exactly the kinds of questions that turn a checkout flow into a meaningful systems experiment.

Why Testnet is the right place for this PoC

Testnet started as an Open Payments proof of concept and has since become the practical environment we use to exercise integrations before they go live. It is also the workspace we can reuse for demos and hackathon-style builds because it already combines a wallet, a merchant surface, and Open Payments-backed money movement in one place.

Testnet is an open Interledger network that works with test money and is designed for account servicing entities to test their Interledger integration. In practice, that makes it more than a demo environment: it is the place where we can validate cross-service behavior, integration boundaries, and user-facing flows before treating them as production-ready ideas.

That matters for subscriptions because recurring billing is not just another checkout button. It introduces long-lived authorization, background processing, recovery paths, and multi-step user journeys that need a realistic environment with more than one service boundary.

Baseline Testnet architecture before subscriptions

Before this experiment, Testnet 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 Testnet 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 was:

The Testnet 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:

Testnet 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 whether Open Payments can credibly support subscription setup, renewal, and recovery, and whether the required system boundaries, grant handling, and user recovery paths are viable enough to justify deeper investment.

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 Testnet 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 Testnet 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.

If the payment model works only for one-time purchases, Open Payments remains useful but narrow. If it can also support subscription setup, renewal, visibility, and recovery across multiple services, then it starts to look like infrastructure that can support a broader class of merchant experiences.

Testnet is the right place to ask that question because it already gives us a realistic playground: wallet flows, boutique checkout, Open Payments integration, and enough architectural surface area to expose the hard parts early.

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.