E-commerce & SaaS

Subscriptions that handle
a declined card without losing the customer

The part of subscription commerce that actually determines revenue has little to do with checkout. It is what happens when a card fails to renew. A platform without a proper dunning flow loses subscribers it did not have to lose. A simple retry and a timed email would have recovered many of them.

from$7,000
Timeline6 to 10 weeks
What is includedRecurring billing with plan tiers and proration on upgradesDunning sequence for failed payments: retries, card update prompts, timed emailsPause, skip and cancel flows that do not require contacting supportSubscriber portal for managing plan, payment method and addressAdmin dashboard: active subscribers, churn, failed payments, MRR
10-20%of failed renewals typically recovered by a proper dunning sequence instead of a single retry
6 to 10 weekstypical time from a locked plan structure to a live subscription platform
0subscribers silently dropped from billing without at least one recovery attempt

Who actually needs this

A subscription commerce platform fits a business selling on a recurring basis: a subscription box, a membership, a recurring service. The hard problem is not the first sale. It is keeping the subscriber paying month after month. It fits a business currently handling failed payments manually, or losing subscribers silently to expired cards. It does not fit a one-time-purchase store, where recurring billing infrastructure is unnecessary complexity.

What the platform actually handles

Recurring billing handles proration correctly when a subscriber upgrades or downgrades mid-cycle. They get charged or credited the right amount, instead of a flat new price. A dunning sequence retries a failed charge on a sensible schedule. It prompts the subscriber to update their card before giving up, and only cancels after those attempts are exhausted. Self-service pause, skip and cancel flows exist because a subscriber forced to email support to pause often cancels outright instead. An admin dashboard shows the metrics that actually matter: active subscribers, churn, and how many failed payments the dunning sequence is recovering.

How we sequence the build

We start with the plan structure and billing rules. Proration, trial periods and plan-change logic need deciding before the billing code is written, not patched in after the first upgrade request breaks something. The dunning sequence gets built and tested against real failure scenarios: a card that is simply expired, versus one that is actually being declined for fraud review. Treating every failure the same wastes retries on cases that will never succeed. The subscriber portal is built so changing a plan or updating a card takes a subscriber under a minute. Friction here is exactly where subscribers give up and cancel instead.

Where subscription billing actually breaks

Proration is the single most bug-prone part of subscription billing. A mistake here either overcharges a customer, who notices and complains, or undercharges silently, which nobody notices until a revenue audit months later. We test every upgrade, downgrade and mid-cycle plan change against real scenarios before launch, not just the simple case of a subscriber who never changes plans. The dunning sequence carries its own risk. Too aggressive, and it reads as spam, pressuring a customer who genuinely cannot pay right now into cancelling out of irritation. Too passive, and a recoverable failed payment quietly becomes a lost subscriber. We tune the sequence’s timing and tone to the specific product, instead of using one aggressive default for every subscription type. The third trap is webhook reliability. A payment provider’s webhook that fails to deliver, or arrives out of order, can leave a subscriber’s status out of sync with what they actually paid. We build idempotent webhook handling that tolerates retries and out-of-order delivery, instead of assuming every webhook arrives exactly once, in order, on time.

Timeline and price

Option Price What it covers
MVP from $7,000 Single plan tier, basic retry on failed payment, manual cancellation
Production from $12,000 Multiple plan tiers with proration, full dunning sequence, subscriber self-service portal, admin dashboard
Full control (handover-ready) from $13,000 Everything in Production plus usage-based billing support, architecture documentation, and 90 days of support

Running cost after launch depends on hosting and, where relevant, model usage, typically $20 to $150 a month for a project at this scale.

What stays yours

You own the subscription platform’s code and database, with billing synced to your own payment provider account under your name. Subscriber data, plan history and payment status are yours to export or migrate at any point. No proprietary lock-in keeps the business running on us. This is the same handover standard on every store or marketplace we build. The platform account, every payment and delivery credential, and the full order history stay in your name from the first day, not just after a dispute. A written handover document explains what each integration does and why. A future developer, ours or someone else’s, can pick up the system without reverse-engineering it from the code alone.

See the development service page for our full build process. This pairs with SaaS billing and tenant system, Digital goods marketplace. For the engineering detail, see Subscription billing with dunning, Subscription box commerce. For a real build, see ProBay: our own marketplace, Supplements store Balkans sales x10.

Want this built for your business? Get in touch and we will scope it with a fixed price.

FAQ

How much does a subscription commerce platform cost?

From $7,000 for a platform with recurring billing, dunning and a subscriber portal, 6 to 10 weeks. A platform with multiple plan tiers, proration logic and usage-based billing runs $12,000 to $18,000.

What is dunning and why does it matter?

Dunning is the sequence that runs when a renewal payment fails. It retries the charge on a schedule, prompts the subscriber to update their card, and only cancels after those attempts are exhausted. Without it, a subscriber with an expired card simply disappears, instead of being given a chance to stay.

What is the stack?

FastAPI or Node on the backend, depending on your existing systems. Integration with your payment provider's subscription and webhook APIs, Stripe or a regional equivalent. A subscriber-facing portal in Next.js.

Can subscribers pause instead of cancelling?

Yes. A pause and resume flow is built in by default. A subscriber who can pause for a month often comes back. One forced to fully cancel often does not.

Who owns the subscriber and billing data?

You. Subscriber records, plan history and payment status live in your own database, synced with your payment provider's systems but never locked inside a tool only we control.

Start here

Tell us the problem.
We bring the system.

A 30-minute call, then a written plan with numbers within 48 hours. No obligation. If we are not the right fit, we will say so and point you to someone who is.

LIKE WHAT YOU SEE?

This site is our work.
Want one like it?

Ten languages, no page builder, launched in 2026 by a team working since 2015. We can build the same quality into your site.

  • 10 languages
  • Since 2015
Get a site like this →