How to Set Up Recurring Billing for Your Online Store

Recurring revenue is the most reliable growth lever in ecommerce right now, but only if the plumbing works. If you want to know how to set up recurring billing without chargebacks, angry tickets, and surprise tax issues, you need to get five systems (processor, gateway, subscription engine, tax, and portal) working together cleanly.

This guide walks through the full recurring billing setup for any ecommerce stack. It covers what you need before you start, a 10-step universal setup path, platform-specific playbooks for Shopify, BigCommerce, and Swell, and the settings that separate a clean subscription program from a painful one. By the end, you will have a launch-ready configuration and a test plan.

Key Takeaways

• Learning how to set up recurring billing comes down to five building blocks: a payment processor, a gateway, a subscription engine, a tax/compliance layer, and a customer self-service portal.
• Platform choice matters. Some platforms ship with native subscriptions, others require third-party apps that charge additional transaction fees.
• Dunning configuration with smart retries, soft-vs-hard decline logic, and card account updater services can recover a meaningful share of failed recurring payments that would otherwise churn, depending on your gateway setup and customer mix.
• Mixed carts (one-time items plus subscription items in the same checkout) are table stakes for modern stores, but not every platform supports them natively.
• Always test end-to-end in sandbox mode with simulated cards, a full billing cycle, and webhook handling before launching to real customers.
• Start Day One with the right defaults for grace periods, proration, currency, and customer portal permissions. Changing them later creates billing disputes.

What Is Recurring Billing?

Recurring billing is a payment model where a customer authorizes a merchant to charge a stored, tokenized payment method on a fixed schedule: weekly, monthly, quarterly, or annually, without re-entering card details.

It differs from a one-time charge in three ways: the card is stored as a secure token (not the raw PAN), the merchant triggers the charge instead of the customer, and the system must gracefully handle failures, updates, cancellations, and plan changes over time. That lifecycle logic is what a subscription engine provides on top of a payment processor.

What You Need Before Setting Up Recurring Billing

Recurring billing is not a single product. It is a small stack. Before you configure anything, make sure you have each piece ready. Missing any one of these will block launch.

1. A Payment Processor

The processor moves money from the customer's card network to your merchant bank. Stripe, Braintree, Adyen, and Authorize.net are common choices. For recurring billing, you specifically need a processor that supports stored credentials and merchant-initiated transactions (MIT), which are card network flags that tell Visa, Mastercard, and Amex the charge was pre-authorized. Without MIT flags, recurring charges get declined more often and trigger 3D Secure challenges that break automated billing.

2. A Payment Gateway

The gateway is the software layer between your storefront and the processor. Many ecommerce platforms bundle gateway logic into their checkout so you do not pick it separately. But when you are integrating an external processor, verify the gateway integration supports recurring charges, refunds, partial refunds, and webhook events.

3. A Subscription Engine

This is the service that stores subscription plans, manages billing cycles, handles proration on plan changes, triggers retries, and emits lifecycle events. Some ecommerce platforms ship this natively; others require a third-party app. Know which you are working with before you pick processors. Third-party subscription apps may add platform or transaction costs, which vary by provider and pricing tier.

4. Tax and Compliance Stack

Recurring charges cross tax jurisdictions over time as customers move. You need a tax engine (Avalara AvaTax, TaxJar, or similar) that can recalculate tax per charge, not just at the first order. You also need PCI DSS compliance, which is dramatically easier if you use a tokenized vault from your processor instead of storing cards yourself.

5. A Product Catalog With Recurring SKUs

Every product you want to sell on subscription needs a billing interval attached to it: price, frequency (every 7 days, 30 days, 3 months), trial length, and any prepaid term discount. Some catalogs model this as a separate "plan" object; others attach it as a product option. Pick an approach early. Migrating catalogs mid-flight is painful.

6. Tokenized Payment Storage

Never store raw card numbers. Your processor issues a token (a random string) that represents the card in their vault. Your database stores only the token. When you charge, you send the token to the processor with the amount. Tokenization can significantly reduce PCI scope compared with storing raw card data directly, though exact compliance obligations depend on your implementation. Verify your platform and any subscription app uses tokens end-to-end.

Step-by-Step: How to Set Up Recurring Billing on Your Ecommerce Store

Here is the universal 10-step recurring billing setup that applies to any platform. Platform-specific playbooks follow in the next sections.

1. Choose a Platform With Native or Add-On Subscription Support

Your first decision is the biggest. Platforms with native subscriptions (built into the core product) give you one vendor, one billing model, and one support channel. Platforms that require third-party subscription apps are faster to adopt, but add a second vendor, a second billing layer, and usually a transaction fee. List your requirements (frequency flexibility, mixed carts, prepaid plans, pause/skip, multi-currency) before choosing.

2. Connect a Payment Processor and Gateway

In your platform admin, open payment settings and connect your processor. This usually involves pasting a publishable key and a secret key, then running a handshake transaction. Confirm the test mode key works before touching production keys. Many teams keep processor test keys in a .env.staging file and production keys in a secrets manager.

3. Create Your Subscription Products and Plans

In the product catalog, create the SKUs you want to sell on subscription. For each one, attach a plan object: price, billing interval, trial length (if any), and any prepaid discount tier. A common mistake is creating one product and hard-coding the interval. Instead, create the product once and attach multiple plans (monthly, quarterly, annual) so customers can pick.

4. Configure Billing Intervals and Trial Periods

Billing intervals are the frequency of the charge. Most subscription engines support at minimum: daily, weekly, monthly, quarterly, and annually. Some support custom intervals like "every 45 days," which is useful for consumables where the refill cycle is awkward. Trial periods can be free (no charge for N days) or paid ($1 for N days). Trials drop off and convert at the trial end; make sure your engine handles the trial-end event.

5. Set Dunning and Smart Retry Rules

Dunning is the process of recovering failed recurring payments. Failed payments are a meaningful source of involuntary churn, so retry logic and card updater tools matter. Configure your retry cadence (e.g., retry at 1, 3, and 7 days), soft-vs-hard decline logic (retry soft declines, stop on hard), email notifications to the customer, and a card account updater service if your processor supports one. Smart retries and card updater tools can recover a meaningful share of failed payments, depending on issuer behavior, gateway setup, and customer mix.

6. Enable a Customer Self-Service Portal

Your customers will want to pause, skip, swap products, change cards, and cancel on their own schedule. A self-service portal reduces support tickets dramatically. Configure which actions the portal allows (pause for up to N cycles, skip next delivery, swap to any SKU in the catalog, change quantity) and the URL where customers log in.

7. Configure Webhooks for Subscription Events

Webhooks are HTTP callbacks that fire when something happens: a charge succeeds, a charge fails, a subscription is paused, or a customer cancels. Point webhooks at your backend so downstream systems (email, analytics, fulfillment) react in real time. At minimum, subscribe to relevant subscription lifecycle and payment-failure events documented in your platform's event reference, covering things like charge success, charge failure, subscription creation, updates, and cancellation.

8. Set Up Tax, Currency, and Compliance

Configure your tax settings so tax is recalculated on each recurring charge, not just the first order. Enable multi-currency if you sell internationally, and confirm your subscription engine locks the currency at subscription creation so a EUR subscription stays EUR even if the customer's browser later geolocates differently. Review PCI compliance scope and GDPR/CCPA obligations for stored payment data.

9. Test End-to-End in Sandbox Mode

Do not skip this. In the processor's sandbox, run a full cycle: create a subscription with a test card, let it renew (most sandboxes offer time-warp or short-cycle tools), trigger a failure with a card number that simulates a decline, recover via the dunning flow, and cancel. Verify every webhook fires as expected. A dry run in a sandbox saves dozens of real-world support tickets.

10. Launch and Monitor

Flip the toggle on production keys, then watch the first week of real subscribers closely. Build a dashboard (or use your platform's built-in subscription reports) that tracks active subscriptions, MRR, churn, failed-payment rate, and dunning recovery rate. If the failed-payment rate creeps above 7-8%, revisit your retry schedule.

Step-by-Step: Setting Up Recurring Billing on Shopify

Shopify has added native subscription tooling in recent years, but the out-of-the-box functionality is still limited compared to most purpose-built subscription engines. Here is the honest setup path.

1. Confirm Your Gateway Is Supported

First, confirm your gateway is supported by the Shopify Subscriptions app. Shopify currently lists Shopify Payments, PayPal Express, Authorize.net, Adyen, and Stripe for select merchants, though availability varies by region and store eligibility.

2. Pick a Subscription App

Second, pick a subscription app. The dominant options are Recharge, Bold Subscriptions, Skio, and Appstle. Each may add its own platform or transaction costs on top of your processing fees, which vary by app and pricing tier. Depending on the subscription app and integration model, subscription orders may use Shopify's native flow or an app-managed checkout experience, which means any checkout customizations you built may need to be revisited inside the app.

3. Create Subscription Widgets on Product Pages

Third, create subscription widgets on product pages. Most apps inject a "Subscribe and save" widget via a theme edit. Confirm the widget is accessible, price-accurate, and mobile-responsive.

4. Configure the Customer Portal

Fourth, configure the customer portal. Each subscription app provides its own portal, separate from the Shopify customer account. Expect to spend time on branding and on training your CS team on a second admin.

5. Test in the Sandbox

Fifth, test in the sandbox. Shopify offers a "Bogus Gateway" for test transactions, but subscription apps each have their own test modes. Use the app's test mode, not just Bogus Gateway, or you will miss webhook-related bugs.

6. Plan Around Mixed-Cart Limitations

One limitation to plan around: mixed carts (one-time items plus subscription items in the same checkout) are inconsistently supported across subscription apps on Shopify. Some support them, some do not, and some only support them at the higher plan tier.

Step-by-Step: Setting Up Recurring Billing on BigCommerce

BigCommerce does not ship a native subscription engine. BigCommerce relies on third-party apps for recurring billing. Current marketplace options listed by BigCommerce include ReCharge, PayWhirl, Rebillia, MiniBC, Ordergroove, and others.

1. Choose and Install a Subscription App

Start by choosing and installing the app from the BigCommerce app marketplace. Bold has deep BigCommerce integration; Chargebee is the choice for more complex billing (usage-based charges, hybrid pricing). Installation connects the app to your BigCommerce storefront and catalog via OAuth.

2. Create Subscription Plans in the App Admin

Next, create subscription plans inside the app admin. This is a separate UI from BigCommerce's own product admin, and the plan data lives in the app, not BigCommerce. You map BigCommerce products to app plans via SKU or product ID.

3. Configure the Checkout Integration

Then configure the checkout integration. Checkout behavior varies by app: some use embedded integrations, while others use app-specific or hosted checkout flows. That means any custom checkout script, analytics tag, or promotional tool may need to be re-integrated on the app side depending on which solution you choose.

4. Configure Dunning Rules

Configure dunning rules inside the app. Most BigCommerce subscription apps offer standard retry schedules and email templates; advanced smart-retry logic may require the enterprise tier.

5. Set Up Webhooks

Set up webhooks from the subscription app to your order management system so fulfillment triggers correctly. Because subscription orders originate in the app and are pushed back into BigCommerce, timing issues can leave orders stranded. Test thoroughly.

6. Walk Through the Full Customer Experience

Finally, walk through the customer experience end to end, because the subscription-app portal and the BigCommerce customer account are two separate systems your customer now has to navigate.

Step-by-Step: Setting Up Recurring Billing on Swell

Swell is API-first, and recurring billing is native to the platform, not an app or add-on. You can learn how to set up recurring billing on Swell via either the visual dashboard or the developer API, and mixed carts, dunning, pause/skip, proration, and customer portal are all built in.

1. Enable Subscriptions in Settings

Navigate to Settings, then Subscriptions setup in the dashboard to enable the subscription data model across products, carts, checkout, and orders. No additional install, no second admin.

2. Connect Your Payment Gateway

Swell supports multiple payment gateways, including Stripe and Braintree, with additional gateway options documented in its help center. Add your processor credentials under Payment Gateways. Swell uses tokenized payment methods for recurring billing; gateway-specific support for stored credentials and merchant-initiated recurring charges should be confirmed in your payment setup for the strongest possible auth-rate signals.

3. Create a Subscription Plan

In Products, open the product you want to sell on subscription and click "Create subscription plan." See the creating subscription plans guide. Define the billing interval, trial length, prepaid term, and any subscription discount rules. You can attach multiple plans to the same product, for example monthly, 3-month prepaid, and annual prepaid.

4. Configure Dunning and Retries

In Subscriptions settings, set your retry cadence (Swell supports smart retries with separate soft-vs-hard decline handling out of the box), grace period, and the email template for dunning notifications. See subscription notifications for configuration details.

5. Enable the Customer Self-Service Portal

Swell includes a customer portal with pause, skip, swap, change-cycle, change-quantity, and cancel flows, all configurable per your business rules. Follow subscription management to choose which actions customers can take.

6. Configure Mixed Carts

Swell natively supports mixed carts, one-time products, and subscription products in the same checkout, billed atomically, without requiring a separate subscription app.

7. Set Up Webhooks

From the developer dashboard, subscribe your backend to relevant subscription lifecycle and payment-failure events documented in Swell's event reference. Swell's webhook signing means you can verify payloads cryptographically without extra middleware.

8. Test in Sandbox

Use your gateway's test card numbers and Swell's staging environment. Accelerate billing cycles by setting short intervals (e.g., daily) on a test plan so you can see renewals complete in minutes instead of months.

9. Launch

Flip to production gateway keys, announce to your customers, and watch the subscription reports dashboard for MRR, active subs, and failed-payment rate.

Start your free trial today and begin setting up recurring billing for your store.

Key Settings to Configure Right From Day One

Getting the defaults right on Day One prevents months of billing disputes and emergency fixes later.

Grace Period

After a failed charge, how long do you let the subscription remain "active" while you retry? Seven days is a common default. Longer grace periods keep more subscribers but delay cancellation of non-paying accounts; shorter ones reduce revenue leak but increase voluntary churn from confused customers.

Retry Schedule

Most subscription engines retry at days 1, 3, and 7 by default. Smart retry services, which learn the optimal time-of-day to retry based on issuer behavior, consistently outperform fixed schedules on recovery rate in industry benchmarks. If your engine supports smart retry, turn it on.

Pause / Skip / Swap

Decide which actions a customer can take on their own via the self-service portal: pause for up to N cycles, skip next shipment, swap to a different SKU, change cadence, change quantity. More self-service cuts support ticket volume but require clear rules to prevent abuse (e.g., pausing indefinitely to get a discount).

Proration

When a customer upgrades or downgrades mid-cycle, how do you bill? Common approaches include full prorated credit (charge the delta immediately), no proration (change takes effect at next cycle), or prorated refund. Pick one and document it for CS.

Multi-Currency and Taxes

Lock subscription currency at creation. A subscription created in EUR should always renew in EUR. Configure tax to recalculate per charge, not once at signup, so customers who relocate get the right tax at the right time.

Mixed Cart Rules

If you support mixed carts, decide how discounts apply. Does a 10%-off coupon apply to the subscription item, the one-time item, or both? Does it apply only to the first subscription charge or all future renewals? Document and test both paths.

Upgrade / Downgrade Flow

When a customer changes plan tiers, what happens? Some teams prorate immediately. Others wait until the next billing cycle. A few offer a choice. The right answer depends on your margin structure, so pick one before launch.

How to Test Recurring Billing Before Going Live

Do not test recurring billing in production. Every processor provides a sandbox with test card numbers that simulate specific outcomes: approved, insufficient funds, expired card, lost or stolen, 3D Secure challenge, processing error. Run each scenario at least once before launch.

The end-to-end test script should cover:

• The customer creates a subscription with a successful test card.
• First charge captures at checkout (or trial starts, if using a trial).
• Fast-forward to the next billing cycle (use your engine's "advance clock" tool or set a daily interval on the test plan).
• Renewal charge succeeds, and your order system creates a fulfillment order.
• Repeat with a card that fails on renewal. Confirm dunning emails are sent, retry happens on schedule, and subscription pauses or cancels on final failure.
• Customer updates card in the portal. Confirm the new token replaces the old one.
• Customer pauses, skips, swaps, and cancels via portal. Confirm each flow writes correct data and emits correct webhooks.
• Verify tax recalculation across state or country lines by changing the test customer's address.
• Verify webhook signatures, payload schemas, and replay handling.
• Run a concurrency stress test if you expect launch-day volume. Subscription renewals tend to batch at the same clock minute, which can overwhelm naive webhook handlers.

Document each test case and the observed result. If anything deviates, fix it in the sandbox, not production.

Common Mistakes When Setting Up Recurring Billing

These are the mistakes we see over and over in recurring billing projects. Plan around them from the start.

Ignoring Dunning

Teams launch with a default retry schedule and never revisit it. Smart retry and card account updater services can recover a meaningful share of failed payments that would otherwise become involuntary churn. If your failed-payment rate is creeping up, your dunning is under-configured.

No Subscriber Self-Service Portal

Every cancel, pause, swap, or card update that goes through your support team instead of a portal is a ticket that could have been self-served. A good portal pays for itself in CS cost reduction within a quarter.

Hard-Coded Billing Cycles

Creating products with hard-coded monthly cycles and no flexibility to add quarterly or annual options means you cannot test prepaid plans later. Prepaid plans typically have higher LTV, so build the flexibility in from Day One.

Wrong Currency Handling

Letting subscription currency switch based on browser geolocation at renewal time will cause tax errors, chargebacks, and customer confusion. Lock currency at creation.

Skipping Sandbox Testing

A subscription bug that ships to production costs hours of CS work per affected customer. A bug caught in the sandbox costs thirty minutes. Spend the week on sandbox.

Not Supporting Mixed Carts

If your store sells one-time products and subscription products, customers will try to buy both in the same checkout. Platforms that force two separate checkouts create cart abandonment and support volume. Support mixed carts from launch if you can.

Underinvesting in Webhook Handlers

Webhooks fail, get delayed, or arrive out of order. A handler that does not verify signatures, handle retries, or idempotently process duplicate events will cause data drift between your subscription engine and your downstream systems. Build webhook handling as it matters, because it does.

Final Verdict

Setting up recurring billing is not complicated if you take it in sequence: pick a platform, connect a processor, build a catalog, configure dunning, enable a portal, wire webhooks, handle tax, test end to end, launch, and monitor. The trap is skipping sandbox testing or hard-coding decisions that are expensive to reverse.

If you want a platform where recurring billing is native (not an app, not a bolt-on) with mixed carts, smart dunning, a customer portal, and a developer API all in the core product, Swell is designed for exactly this use case. Plans start at $29/month billed yearly, with higher tiers adding capabilities such as international price lists, priority support, role-based permissions, and developer support. Create your store today and launch recurring billing on a platform built to scale with you.

Frequently Asked Questions

What is recurring billing, and how does it differ from a one-time charge?

Recurring billing is an authorization to charge a stored, tokenized payment method on a fixed schedule. It differs from a one-time charge in three ways: the card is stored as a token (not the raw number), the merchant triggers each charge automatically, and the system must handle the full subscription lifecycle (renewals, failures, plan changes, and cancellations) over time.

Do I need a separate subscription engine, or does my ecommerce platform handle it?

It depends on your platform. Some platforms ship with a native subscription engine built in, so you do not need a third-party app. Others require a third-party subscription app (e.g., Recharge on Shopify, Bold on BigCommerce), which may add platform or transaction costs that vary by provider and pricing tier. Confirm your platform's approach before picking processors.

What is dunning, and why does it matter for subscription revenue?

Dunning is the process of recovering failed recurring payments through retries, email notifications, and card updates. Failed payments are a meaningful source of involuntary churn, so a well-configured dunning workflow matters a lot. Smart retry logic, which distinguishes soft declines (retry) from hard declines (do not retry) and optimizes retry timing per issuer, consistently outperforms fixed retry schedules.

Can customers have one-time and subscription items in the same cart?

Yes, this is called a mixed cart. Not every platform supports it natively; some require workarounds or a second checkout. If mixed carts are important to your business, confirm native support in your platform evaluation rather than treating it as a bolt-on. Swell supports mixed carts out of the box, with no extra app required.

What happens when a customer's card expires during an active subscription?

The renewal charge will fail. With a card account updater (CAU) service from your processor, the expired card is automatically updated to the new one on file at the issuer, invisible to the customer. Without CAU, your dunning emails ask the customer to manually update the card. CAU services can meaningfully reduce hard declines and recover a share of what would otherwise be involuntary churn, so turn it on if your processor supports it.