Limitations

OpenBilling is intentionally narrow in its current MVP.

Current scope

Supported today:

• Stripe
• Dodo Payments
• Hosted checkout creation
• Hosted billing portal or customer portal links
• Webhook verification
• Narrow webhook normalization

Provider-specific caveats

Stripe:

• Checkout currently requires priceId
• productId is not treated as a substitute
• Webhook normalization only covers a small Stripe event set

Dodo:

• Checkout currently requires productId
• priceId is not treated as a substitute
• The product determines recurring vs one-time behavior
• Webhook normalization only covers a small Dodo event set

Narrow normalized event surface

Only these normalized event types are currently available:

• payment.succeeded
• subscription.active
• subscription.cancelled
• unknown

Unsupported events are not treated as application crashes. They fall back to unknown and preserve the original payload in raw.

Intentionally unsupported features

These are not part of the documented or implemented MVP:

• Invoices
• Refunds
• Disputes
• Taxes
• Usage billing
• Seat billing
• Payout flows
• Marketplace or Connect-style payments
• Analytics dashboards
• Entitlement systems

Demo marketing copy is not API support

The demo UI includes marketing-style text about capabilities such as invoices, taxes, and usage-based billing.

That copy should not be treated as a source of truth for SDK support.

For current support, rely on:

• The package entrypoints
• The current tests
• The demo route behavior
• These docs

What to expect from the MVP

OpenBilling is a good fit if you want:

• A small shared contract for checkout and portal flows
• Consistent webhook verification entrypoints
• A stable normalized event layer for a few common billing events

It is not a complete abstraction over all provider billing features.