Native Subscriptions vs. Bolt-On Apps: The Real Cost
The monthly fee is the cheapest part of a subscription app. The expensive part is keeping two systems agreeing about the same customer.
Every subscription app is priced as a monthly fee plus a percentage. That number is on the pricing page, it’s easy to compare, and it is not where the cost is.
The cost is that a bolt-on subscription app keeps its own copy of your customer, its own copy of the payment method, and its own copy of the order — and then spends the rest of its life trying to agree with your commerce platform about all three.
Two systems, one customer
Here’s the shape of the problem. A buyer subscribes. The subscription app creates a customer record and vaults a card with its processor. Your commerce platform also has a customer record, with its own ID, and its own view of that buyer’s order history.
Now the buyer updates their card.
Which system did they update it in? If it was the storefront account page, does the subscription app know? If it was the app’s portal, does your platform’s customer record reflect it? When your support team looks up “why did this renewal fail,” which of the two records are they reading, and is it the one that’s authoritative?
Multiply that by address changes, cancellations, refunds, failed payments, plan changes, and churn. Every one is a state transition that has to propagate correctly across a boundary between two systems that were designed independently and are connected by webhooks that occasionally retry, occasionally arrive out of order, and occasionally don’t arrive.
This is where the money goes. Not the $500 a month. The engineering time spent building reconciliation, the support time spent resolving disagreements between the two systems, and the revenue lost to failures nobody noticed because the two dashboards disagreed and everyone assumed the other one was right.
What “native” changes
Native doesn’t mean the feature list is longer. It means there is one record.
When the subscription engine is part of the commerce engine, a subscriber is a customer — the same row, the same ID, the same order history. The card vaulted at checkout is the card that renews. There is no sync, because there is no second copy to sync with.
Concretely, in Throttle: the buyer pays once through the checkout embed, the card is vaulted during that payment, and the renewal cron reuses it. The subscription, the original order, the renewal orders, and the customer are the same objects your other integrations already read. Your fulfillment system doesn’t need to learn a second order shape.
That’s the whole argument. Everything below is consequence.
What that gets you
Dunning that knows about the order. When a renewal fails, the retry schedule runs on [1, 3, 7] days and emits subscription.payment_failed. Because the payment, the subscription, and the customer are one system, the failure carries the context to act on it.
A backup payment method. If the primary card fails, Throttle tries the customer’s backup before entering dunning at all. That’s only possible when payment methods are a first-class part of the customer record rather than a copy inside a separate app.
Real proration. A plan or seat change sent with effective: 'now' credits the unused portion of the period the buyer already paid for and charges the net — skipping the charge entirely when the credit covers it. The response includes the breakdown, so you can show the buyer exactly what happened. Send effective: 'period_end' instead and the change is scheduled for the next renewal with no charge now.
One webhook stream. subscription.created, subscription.renewed, subscription.plan_changed, subscription.paused, subscription.payment_failed, subscription.backup_pm_used. Same signing secret, same delivery guarantees, same endpoint as your order and payment events.
Trial-fraud protection. An eligibility check runs before a trial is granted, so the same buyer can’t cycle free trials indefinitely. Bolt-ons usually can’t see enough of your customer history to make that call.
What Throttle does not do yet
This is the part most comparison posts skip, which is exactly why it’s worth including.
No-card free trials. Trials require a vaulted card up front. “Subscribe now, add a card later” isn’t supported.
Net30 recurring. Net terms work for one-time orders. Invoicing a subscription every period instead of charging a stored card is not in the current subscription surface.
Recurring discounts. Promotion codes apply to cart-backed checkout totals. An ongoing per-cycle discount is deferred.
Configurable dunning curve. The retry schedule is fixed at [1, 3, 7] days. Per-merchant overrides are deferred.
Direct browser-to-Throttle buyer calls. The React package proxies through your backend, which holds the secret key and enforces ownership. Customer-scoped tokens that would let the browser call us directly aren’t built yet.
If any of those is load-bearing for your business, a specialised bolt-on may genuinely be the better tool right now. That’s a real answer, and we’d rather you get it from us than discover it in week three of an integration.
How to actually evaluate this
Ignore the pricing pages. Ask four questions about any subscription system you’re considering:
Where does the customer record live, and how many are there? If the answer is two, everything else is downstream of that.
Which system owns the vaulted card? If it’s the subscription app, then leaving that app means asking every subscriber to re-enter their card — a migration most businesses never recover from, and the real source of the lock-in.
What happens on a failed renewal? Trace the whole path: retry schedule, notification, what your fulfillment system sees, what your support team sees. Count the systems involved.
Do renewal orders look like normal orders? If your ERP, 3PL, and analytics need special handling for subscription orders, you’ll be maintaining that fork indefinitely.
The last one is the tell. In a native system it’s not a meaningful question — a renewal produces an order, and an order is an order. In a bolt-on, it’s usually the first thing someone has to build.
If you’re weighing this, the subscriptions documentation is specific about both the API and the limits above. The migration playbook covers moving an existing subscriber base — including the vaulted-card constraint, which is the part with a lead time.