NIKOLA

Recurring billing is the least forgiving thing on your site

A broken contact form annoys somebody. A broken renewal loses money silently for a month before anyone notices, and by then the failed payments have already churned. Subscription systems do not fail loudly — they leak.

YOU ARE PROBABLY HERE BECAUSE

  • renewals started failing after a plugin update
  • some subscribers are being charged twice
  • you are moving off a platform and the billing cannot stop
7 projects built or repaired3 migrations of live subscribersInterrupted payments caused: none

What I can do for you

Four ways this starts. Most people begin with the first one even when they already know they need the second.

FIXED · 3–5 DAYS

Subscription health check

I compare what your site believes against what your payment gateway believes, and hand you a written report of every discrepancy — failed renewals nobody chased, subscriptions active in one system and cancelled in the other, webhooks that never landed. You keep the report whether or not you hire me for the fix.

FIXED, AFTER DISCOVERY

Migration off your current platform

Moving live subscribers onto WooCommerce Subscriptions with billing running throughout. Data mapped, old records repaired, run twice on a clone, tested rollback, then two full billing cycles of reconciliation before I call it done.

FIXED · 2–4 WEEKS

Failed payment recovery

A proper retry ladder, pre-emptive card expiry notices, and dunning emails that read like a person wrote them. Usually recovers more revenue than acquisition work at the same cost, and it is the least-built part of most subscription systems.

MONTHLY RETAINER

Ongoing subscription maintenance

Reserved time each month for plugin and gateway updates, renewal monitoring, and the steady stream of small things. Priority on anything that stops a renewal.

Book a consultation

Forty-five minutes, no charge.
I will tell you which of these you need, including when it is the cheapest one.

The kinds I build

Most sites need two or three of these at once, and the awkward part is usually where they meet — a membership that also ships a physical product, or a donation that also unlocks content.

Simple subscriptions

One plan, one price, one interval. Monthly or annual access to something, billed until cancelled.

  • Trials, free and paid
  • Sign-up fees
  • Synchronised renewal dates
  • Pause and resume

Variable subscriptions

One product, several billing options — monthly against annual, tiers, sizes, quantities — each with its own price and interval on the same page.

  • Plan switching with proration
  • Upgrade and downgrade paths
  • Quantity changes mid-term
  • Per-variation pricing rules

Physical products, recurring shipping

Subscription boxes and consumables. The hard part is not the billing — it is that a real parcel has to leave a warehouse on a schedule that matches it.

  • Recurring shipping rates
  • Skip, delay and reschedule
  • Address changes mid-cycle
  • Stock reserved against renewals
  • Fulfilment handoff to ERP or 3PL

Recurring donations

Regular giving with the emotional and administrative differences that come with it. Donors are not customers and the flows are not the same.

  • Donor-chosen amounts
  • Gift Aid and receipting
  • Anonymous and in-memoriam giving
  • Failed payment handled gently

Gated areas and memberships

Access that follows subscription state, including the states people forget — expired, on hold, in grace, cancelled but paid up until the end of the term.

  • Content and course restriction
  • Tiers with different access
  • Grace periods after failure
  • Group and corporate seats

Wallets and credit

Where a flat subscription does not fit the product. Members hold a balance and spend it, or buy credit outright and consume it over time.

  • Balance and ledger
  • Pay per article or per unit
  • Credit expiry rules
  • Top-up on a schedule
  • Reconciliation against the gateway

Where the money actually leaks

Almost nobody loses subscribers at the sign-up form. They lose them at renewal, in ways that produce no error message and no support ticket.

THE CYCLE THAT HAS TO KEEP WORKING Active next charge scheduled Renewal due scheduler fires the job Charge attempt token sent to gateway Paid access continues Payment failed card expired, funds, 3DS Retry ladder dunning emails Silent churn nobody was told Recovered back into the cycle LEAKS HERE expired cards nobody was asked to update AND HERE retries too few, too fast, or silent AND HERE no email ever sent
Three of these boxes are where subscription revenue disappears, and none of them raises an error anybody sees. Recovering failed payments is usually worth more than acquiring new subscribers, and it is almost always the least-built part of the system.
FAILURE MODE

Renewals stop after an update

A plugin or gateway update changes a hook or an API version, the scheduled job quietly stops firing, and nobody notices until the month's revenue comes in short.

FAILURE MODE

Cards expire and nobody asks

A meaningful share of any subscriber base has a card expiring this year. Without a pre-emptive update flow, each one becomes a failed renewal and then a lost customer.

FAILURE MODE

Dates drift after an import

Subscribers imported without reconstructing their billing schedule get charged early, get free months, or both. The accounts stop reconciling and the fix is manual.

FAILURE MODE

WordPress and the gateway disagree

A subscription cancelled at Stripe but still active in WordPress keeps giving away access. The reverse keeps charging someone who thinks they left.

FAILURE MODE

Access does not match billing state

Cancelled but paid until month end, on hold, in grace after a failure — every one of those needs a defined answer, and gated content usually only handles two of them.

FAILURE MODE

Reports do not match the gateway

Your dashboard says one number, Stripe says another, and nobody can explain the gap. Usually webhooks that failed months ago and were never replayed.

Migrations — the part most people cannot do

Building a subscription system from nothing is straightforward. Moving thousands of people who are already being charged, onto something else, without a single interrupted payment, is a different discipline. I have done it three times.

The reason it is hard is that the money does not live in WordPress. Member records are simple rows. The thing that actually moves money is an object at the payment gateway, and the naive migration path cancels every one of them.

Platform migrationPMPro → WooCommerce Subscriptions

Levels mapped to products, trials and discount codes given explicit destinations, content protection rules rewritten, and the awkward cases decided by you in writing rather than guessed by me. Done twice, under a deprecation deadline both times. The detailed version →

Third-party importlegacy or bespoke systems

Subscriptions imported from systems that were never designed to be left, with billing schedules reconstructed from payment history rather than trusted from an export. Done at ICL Society and Progressive Christianity.

Payment method migrationtokens, not cards

Card details are not yours to move and never touch your server. What moves is the token — the gateway's reference to a stored payment method. Whether those can be reused depends on your gateway, whether the account stays the same, and how the old system stored them. Establishing that is the first thing I do, because it decides whether members act or never notice.

Gateway migrationStripe and PayPal

Stripe supports account-to-account migration of stored payment methods through their own process, which is the difference between a silent cutover and asking everyone to re-enter a card. PayPal billing agreements are less portable and usually need reference transactions approved before automatic billing works at all.

Data repair firstbefore anything moves

Every one of these sites had orphaned records, members on levels that no longer existed, and duplicates from a plugin update years earlier. Migrating faithfully migrates the mess. At Progressive Christianity the database corruption was fixed before the migration was even planned.

Two clean billing cyclesbefore it counts as done

Renewals are monthly or annual, so cutover day proves nothing. Reconciliation continues until two full cycles have run without a discrepancy.

Where this has been done

ProgressiveChristianity.org and Progressing Spirit

Two sites on one multisite. Millions of records and thousands of live subscribers moved onto WooCommerce Subscriptions — not one interrupted payment, and no subscriber had to do anything. Bookstore, recurring donations, Amazon integration and Mailchimp all still running on the other side of it.

Woo Subscriptions
Stripe · PayPal · Mailchimp
donations · bookstore
2022 — 2026

Informed Citizen

Subscription news portal with a wallet, so readers hold credit and pay per article rather than only by subscription. Migrated off Paid Memberships Pro with the credit ledger built on top.

PMPro → Woo Subs
wallet · per-article billing
2025 — present

Sparketh

Children's art school. Parents hold the subscription, children hold the accounts. Rebuilt from scratch with an LMS restructure, order migration and a move off Paid Memberships Pro.

PMPro → Woo Subs
LMS · family accounts
2025 — 2026

International Cinema Lighting Society

Six membership tiers on Paid Memberships Pro across nine languages including Arabic. Subscriptions imported from a third-party system without interrupting payments.

PMPro · WPML
third-party import
via Digital Silk

The ObG Project

Credit wallet for medical professionals — buy credit, sit an exam, receive the document needed for specialisation renewal. Money, assessment and a document with professional consequences, under HIPAA constraints.

Wallet & credits
HIPAA · SCORM · LMS
2017 — 2018

DNAcademy and aimacademy.online

Subscription education platforms — buy access, log in, work through the course. On aimacademy the work was a theme migration, upgrade and a long list of reported faults.

LMS subscriptions
gated access · upgrades

What this does not include

Handling card data

Card numbers never touch your server or mine. Everything runs through the gateway's tokenisation, which is both the law and the only sane way to do it.

Choosing your gateway

I will tell you what each option costs you in migration risk and what it can and cannot carry across. Which processor you use is a business decision involving fees and geography.

Pricing strategy

What to charge and how to package it is not my expertise. I will build whatever structure you decide on and tell you which parts of it are technically expensive.

Guaranteeing nobody re-enters a card

Sometimes token carry-over is impossible because of how the old system stored things. You will hear that from me in week one, not month three.

Questions I get asked

Will our subscribers have to re-enter their card details?

Often not, but it depends on your gateway, whether you keep the same gateway account, and how the old system stored payment methods. Stripe has a supported process for moving stored payment methods between accounts; PayPal billing agreements are considerably less portable. This is the first thing I establish, because it changes both the plan and the price. Anyone promising a seamless answer before looking at your setup is guessing.

Can you do a migration without pausing billing?

Yes — that is the point of the approach. Three times now, with no interrupted payments. Billing continues while the migration runs on a clone, and the cutover happens only once two full test cycles agree.

WooCommerce Subscriptions or Paid Memberships Pro?

If you only need gated content and recurring billing, PMPro does that well and moving costs money to stand still. If you need real products, coupons, reporting, physical fulfilment, or to sell things that are not memberships, WooCommerce Subscriptions is the better home. I would rather talk you out of a migration you do not need.

Can subscriptions ship a physical product?

Yes, and it is more involved than it sounds. Recurring shipping rates, skip and delay, address changes mid-cycle, and stock reserved against upcoming renewals so the warehouse is not surprised. The billing is the easy half.

Our subscribers were charged twice. What causes that?

Almost always a retry without an idempotency key, or a webhook processed twice because the first response timed out. Both are fixable, and both leave a trail in the gateway logs that makes the cause obvious once someone looks. Refunding is the easy part; stopping it recurring is the job.

Renewal dates are wrong since we imported our subscribers.

The classic import failure. Schedules have to be reconstructed from payment history rather than taken from a spreadsheet, otherwise everyone drifts to the import date. It is repairable after the fact, but it means recalculating each subscriber against what they were actually charged and when.

Our renewals are failing and we do not know why.

Common, and usually diagnosable quickly. The first step is comparing what your site believes against what the gateway believes — the gap is normally webhooks that failed and were never replayed, or a scheduler that stopped firing after an update. That comparison is a small fixed piece of work on its own.

Can you recover failed payments better than we do now?

Almost certainly, because most sites do nothing beyond the plugin default. A proper retry ladder, pre-emptive card expiry notices, and dunning emails that read like a person wrote them typically recover more revenue than any acquisition work at the same cost.

Send me your subscriber count and your gateway

That, plus what you are on now, is usually enough for me to tell you on a call whether this is a three-week job or a three-month one.

Book a consultation