One payments API. Many providers.
A modular payments system for SaaS, stores, and donations — the same interface whether the provider is Stripe, Polar, or the next one.
- Stripe
- Polar
- Subscriptions
- Wallets
Problem
Every product reinvented checkout: Stripe here, another provider there, webhooks copied, memberships glued on. Switching providers meant rewriting the app.
What we did
We built Bridge: one API for customers, methods, orders, subscriptions, invoices, receipts, webhooks, and memberships. The app talks to Bridge. Bridge talks to providers.
Product
Teams connect payments without becoming a payments company. Notside.com and pubflow.com already run on it.
Outcome
Bridge is live for our own products. Docs at bridgepayments.dev. Source at github.com/pubflow/native-payments. Public access on platform.pubflow.com is coming.
What the system does
Payments
Methods, customers, addresses, guest checkout, and conversion to an account.
Catalog
Products, subscriptions, orders, invoices, and receipts — SaaS, stores, and donations.
Memberships
Who has access, on the same API as who paid.
Webhooks and embeds
Events back into the product, and checkout surfaces you can drop in.
Admin
Organizations, projects, module hub, renewals, billing schedules, and cost tracking.
In production
The payments system behind notside.com and pubflow.com. Public use on platform.pubflow.com is next.