What is subscriptionbridge?

Subscription Bridge is a backend service that sits between an app you already run and the payment processors that handle recurring subscriptions, currently Stripe and Adyen. Its whole purpose is to let your app offer subscriptions without ever having to hand your users' identities over to the payment processor, and without your app needing to know which processor is actually being used behind the scenes. The way it splits responsibility is deliberate. Your app keeps usernames, your own plan catalog, and whatever feature limits you attach to each plan. Subscription Bridge instead keeps the processor's own account identifiers, payment method references, and the state of each recurring payment. The two sides only share a small set of meaningless reference codes, like a checkout id and a subscription reference, so that even someone with access to the bridge's database cannot directly see who a real customer is. The project is upfront that if someone had access to both your app's database and the bridge's database, they could still connect the dots, since the design reduces exposure rather than making that connection impossible. Underneath, every message between your app and the bridge is signed using cryptographic keys derived from a single secret, so that a request or a callback claiming to come from one side or the other can be verified as genuine. The project maintains a formal specification document as the source of truth for exact message formats and behavior, and it ships fixture test data that other implementations of the same protocol are expected to match exactly. On the payment processor side, Stripe manages the subscription schedule directly through its own checkout and billing tools, while for Adyen the bridge itself owns the renewal schedule and handles retrying failed charges, replacing expired payment methods, and canceling subscriptions. The project describes itself as a greenfield effort still under active development, with no live production deployments yet and no promise that things will not change. It is intentionally narrow: it does not attempt to handle one-off payments, taxes, coupons, currency conversion, or multiple client apps sharing one deployment.