Recurring Payment: How to Set One Up and Actually Get Paid Globally
A recurring payment is the quiet engine behind every subscription business. The customer pays once to say yes, and then the money shows up on schedule without anyone lifting a finger. Get it right and revenue becomes predictable. Get it wrong and you spend your weekends chasing failed cards, refunding angry customers, and wondering why your MRR chart looks like a heart monitor.
This guide covers what a recurring payment actually is, how to set one up, where founders lose money, and how to handle the part nobody warns you about: sales tax and VAT across dozens of countries.
TL;DR
- A recurring payment charges a customer automatically on a fixed schedule (weekly, monthly, annually) using stored card or bank details.
- You need three things to run one: a payment method on file, a billing schedule, and a system to retry failed charges.
- Failed payments (called involuntary churn) kill 20% to 40% of subscription revenue if you ignore them. Smart retries recover most of it.
- If you sell software or digital products across borders, you owe sales tax or VAT in the buyer's country, not yours. That is the part that turns a simple charge into a compliance project.
- A Merchant of Record like Creem runs the recurring payment, the retries, and the tax filings for you, so you keep building instead of bookkeeping.
What Is a Recurring Payment?
A recurring payment is an agreement where a customer authorizes you to charge them repeatedly without asking each time. You store their payment credentials once, and your billing system pulls the agreed amount on the agreed date.
There are two flavors worth knowing.
Fixed recurring payments charge the same amount every cycle. Think Netflix at $15.49 a month or a $99 annual plan. Predictable for you, predictable for the customer.
Variable recurring payments change based on usage. Think an AWS bill, a per-seat SaaS plan that grows with the team, or a usage-based API product billed per 1,000 calls. The schedule is fixed but the number moves.
Both rely on the same plumbing: a saved payment method, a tokenized card or mandate, and a scheduler that fires the charge. The customer sees a line on their statement. You see money in your account. That is the whole promise.
How to Set Up a Recurring Payment
You have two real paths, and they are very different amounts of work.
Path 1: Wire it up yourself with a payment gateway
The DIY route uses a raw payment gateway like Stripe or Braintree. You get an API, and you build everything on top of it.
Here is what "everything" means:
- Collect and tokenize the card. Never store raw card numbers yourself unless you enjoy PCI DSS audits. Use the gateway's hosted fields or SDK.
- Create a customer object and attach the payment method.
- Define your products and prices, then create a subscription that ties the customer to a price and a billing interval.
- Handle webhooks. When a charge succeeds, fails, or a card expires, the gateway sends an event. You need code listening for every one of them.
- Build dunning. When a payment fails, you retry on a smart schedule and email the customer to update their card.
- Handle proration, upgrades, downgrades, cancellations, and refunds.
- Then, and this is the big one, calculate and remit sales tax and VAT everywhere you have customers.
This gives you total control. It also gives you a project that eats weeks of engineering time and never really finishes, because tax rules change and cards keep failing.
Path 2: Use a Merchant of Record
The second path hands the whole stack to a Merchant of Record (MoR). You define the plan and the price. The MoR becomes the legal seller, runs the recurring payment, handles the retries, and files the taxes under its own registrations.
With Creem, setting up a recurring payment looks like: create a product, set the interval and price, drop in a checkout link or API call, done. The subscription, the failed-payment recovery, and the global tax compliance come with it. You are not wiring webhooks for card expiry at midnight.
The tradeoff is a slightly higher fee than a bare gateway. What you buy with that fee is not having to become a tax filer in 40 countries. For most software and digital-product sellers, that is the better trade by a wide margin.
Where Recurring Payments Leak Money
The dangerous part of recurring billing is that failures are invisible until you look. Nobody complains when a card silently declines. They just churn.
Involuntary churn is revenue you lose to failed payments, not to unhappy customers. Cards expire, banks flag charges as suspicious, balances run short. Industry data pegs involuntary churn at roughly 20% to 40% of total subscription churn. That is real money walking out the door for a technical reason, not a product reason.
Three fixes recover most of it.
Smart retries. Do not retry a failed card five minutes later five times in a row. Space attempts across days and align them with paydays. A good retry engine recovers a large share of failed charges with zero customer effort.
Card account updater. Networks like Visa and Mastercard offer services that automatically update a stored card when it is reissued. This alone eliminates a chunk of expiry-driven failures.
Dunning emails. A short, clear "your payment didn't go through, update your card here" email with a one-click link brings back customers who would otherwise vanish. Timing and tone matter more than volume.
If you build recurring payments yourself, you build all three yourself. If you use an MoR, they run by default.
The Tax Trap Behind Every Cross-Border Recurring Payment
Here is the thing that turns a tidy monthly charge into a legal headache. When you sell digital products or software to someone in another country, the tax is usually owed in the buyer's country, not yours.
Sell a subscription to a customer in Germany and you may owe German VAT at 19%. Sell to the UK and it is 20% UK VAT. Sell to a customer in Texas and you may owe US state sales tax once you cross an economic nexus threshold. Multiply that by every country and state where you have a single paying customer.
Each cycle of a recurring payment is a taxable event. So the compliance obligation is not a one-time thing at signup. It repeats every month, forever, in every jurisdiction.
Doing this yourself means registering for VAT or sales tax in each region, charging the correct rate, collecting valid business tax IDs for reverse charge, filing returns on different schedules, and keeping records if an auditor knocks. It is a full back-office function.
This is the single strongest reason software sellers use a Merchant of Record. When Creem is the merchant of record, Creem is the legal seller of the transaction. Creem charges the right tax rate at checkout, remits it to the right authority, and files the returns. Your recurring payment keeps running and you never register for VAT in a country you have never visited.
Recurring Payment vs Subscription vs Installment
These terms get mixed up, so here is the clean version.
A recurring payment is the mechanism: an automatic charge on a schedule.
A subscription is a business model built on recurring payments, where ongoing access to a product is exchanged for ongoing charges.
An installment plan is a fixed number of recurring payments that pay off a single purchase, like a $600 course split into 6 payments of $100. Once the total is paid, the charges stop.
All three use the same underlying rails. The difference is whether the charges are open-ended (subscription), usage-based (variable recurring), or capped at a total (installment).
FAQ
How do I set up a recurring payment for my business?
Pick your path. With a raw gateway you build subscription logic, dunning, and tax handling on their API. With a Merchant of Record like Creem you create a product, set the price and interval, and share a checkout link. The MoR runs the charges, retries, and taxes for you.
What is the difference between a recurring payment and a subscription?
A recurring payment is the automatic charge itself. A subscription is a business model that uses recurring payments to sell ongoing access. Every subscription contains recurring payments, but not every recurring payment is a subscription (installment plans use them too).
Why do recurring payments fail?
Most failures are involuntary: expired cards, insufficient funds, or bank fraud flags. These account for a large slice of subscription churn. Smart retries, card account updater services, and dunning emails recover the majority of them.
Do I have to charge tax on recurring payments?
Usually yes, and in the customer's country. Digital products and SaaS are taxable in most regions, and each billing cycle is a fresh taxable event. A Merchant of Record handles this by becoming the legal seller and remitting tax on every charge.
Is a payment gateway enough to run recurring payments?
A gateway processes the charge, but it does not make you tax compliant, and it leaves dunning and subscription management for you to build. A Merchant of Record bundles all of it. Choose based on how much of that stack you want to own.
Stop Babysitting Your Billing
A recurring payment should be the most boring part of your business. Money arrives on schedule, failed cards get recovered automatically, and the taxman gets paid without you filing a single form.
That is exactly what Creem does. As your Merchant of Record, Creem runs the recurring payments, recovers failed charges, and handles sales tax and VAT in every country you sell to. You set the price and build the product. Creem handles getting paid.
See how it works at creem.io and check the plans at creem.io/pricing. Focus on your product. Let Creem handle the rest.
