The first charge is the easy one. Your customer is at the checkout, card in hand, typing the security code. Everything the gateway wants is present.
Thirty days later that same card gets charged again, with no customer, no security code, and nobody watching. That second charge is where shopping cart recurring billing either works quietly for years or fails in ways that take months to notice. This covers what breaks, because the failure modes are predictable and nearly all of them are configuration.
Why rebills decline
A rebill is not the same transaction as the original purchase. It is a card-not-present charge with no customer and no security code, and gateways treat it differently. When a recurring charge fails on a card that worked at checkout, the cause is almost always one of four:
- The security code is missing. Security codes cannot be stored, so every rebill goes out without one. Some gateways reject those by default.
- The card expired. Subscriptions outlive cards. A two-year subscriber gets reissued at least once.
- Insufficient funds or a temporary hold. Usually transient, and often recoverable a few days later.
- The gateway changed its rules. Risk settings get tightened, and automated transactions are frequently the first thing caught.
Each has a specific fix. None require emailing customers for their card again.
The security code problem
This is the failure that surprises merchants most, and it is worth understanding before you launch a subscription product. Security codes are never stored in UltraCart. That is a compliance requirement rather than a platform limit: the rules prohibit keeping the code alongside other card billing details.
So the code reaches your gateway once, during the original checkout, and is then gone. Every rebill afterward goes out without one. Configure your gateway to accept authorizations without a security code for automated transactions, or those charges decline permanently rather than temporarily.
Most gateways let you have this both ways: require the code at checkout and decline on a mismatch there, while still allowing later rebills without it. A gateway that insists on a code for every authorization cannot support subscriptions, which is better learned during setup than after your first billing cycle. Our comparison of payment processors is a reasonable starting point when choosing one.
Recurring billing retry logic
A declined rebill is not a lost customer. Many recurring billing declines are temporary: a hold on available credit, a balance that clears on payday, a fraud rule that trips once. Retry logic exists to try again at the right moment.
UltraCart retries a failed auto order three times by default, waiting three days between attempts, then cancels if all three fail. Both the count and the interval are adjustable in your auto order processing settings.
The three-day gap is deliberate, and it is the detail most merchants get wrong when tuning this. A declined attempt often places a temporary hold on the card's available credit for the amount you tried to charge. Retry too quickly and you are testing a card your own failed attempt just made less likely to approve. Waiting lets the hold expire, which usually takes two to three business days.
Gateway cascade on decline
Retrying the same card through the same gateway is one option. Running more than one gives you another: when a charge declines, send it elsewhere.
UltraCart calls this a rotating transaction gateway, and it does more than split traffic by percentage. By default a decline triggers a cascade, meaning the transaction rolls over to the next available gateway instead of failing. A charge one processor refuses may be approved by another, and the customer sees none of it. A setting can delay that cascade by six hours when you would rather let a transient issue clear first.
The same mechanism makes changing processors survivable. Add the new gateway alongside the existing one and shift traffic gradually. Payments that succeed move over, and payments that fail fall back to the old gateway and get flagged. To finish, set the old one to zero percent traffic but leave it active so refunds and existing rebills still work.
Why rebills stay put
There is an important exception to that routing. When an order is a rebill, UltraCart uses the same gateway that processed the original transaction. Many gateways will not accept a transaction without a security code unless they handled the original authorization. Send the rebill elsewhere and it declines, not because anything is wrong with the card, but because the new gateway has no history to authenticate against.
Subscription traffic therefore behaves differently from one-time traffic by design. New orders distribute freely. Rebills follow their original, and an auto order setting enforces this when your gateway requires it.
Handling expired cards
Cards expire on a schedule unrelated to your billing cycle. For any subscription lasting more than a year, this is a certainty rather than a risk.
UltraCart handles the common case automatically by advancing the stored expiration year by three, matching the renewal period most issuers use. A reissued card often carries the same number with a new date, so the charge simply goes through.
When it does not, the customer gets an email with a link to update their card and billing address. That link matters more than it looks: a self-service update recovers a subscription far more cheaply than winning back a customer who was cancelled while not paying attention.
Billing built into the cart
Everything above depends on the cart, checkout, and billing engine sharing the same data. Retry logic needs the order. Gateway affinity needs the processor that handled the original charge. Expiration handling needs the stored card and customer record together.
Add billing as a separate service and those pieces sit in different systems that must be kept in sync. That synchronization is where subscription revenue quietly leaks, because a failure in one system is invisible in the other. A hosted shopping cart that includes recurring billing keeps them in one place, and the case for consolidating cart, checkout, and hosting applies to billing for the same reason. Stored cards also sit inside a Level 1 PCI compliant environment, so your subscription program inherits that certification.
Configure recurring billing
Setting up recurring billing on your cart, in order:
- Confirm your gateway allows rebills without a security code. Do this first. Everything else is wasted effort if automated transactions cannot process at all.
- Require the security code at checkout so the original authorization is properly authenticated.
- Set your retry count and interval. Keep at least three days between attempts so credit holds expire.
- Add a second gateway if volume justifies it and let cascade recover declines the first processor refuses.
- Test the full cycle before launch, including a deliberate decline, so you see retry and cascade behavior on your own configuration.
For selling and retaining subscribers, including the customer portal and cancellation flows, see our guide to built-in subscription management. Full configuration steps live in the auto orders documentation.
Recurring billing FAQ
Why does a card work at checkout but fail on the rebill?
The rebill is submitted without the card security code, because that code cannot be stored, and some gateways reject card-not-present transactions that lack one. Configure your gateway to allow authorizations without a security code for automated transactions, while still requiring it at checkout.
How many times should a failed subscription payment be retried?
UltraCart retries three times by default with three days between attempts, then cancels. Keep at least three days. A declined attempt can place a temporary hold on the card's available credit that takes two to three business days to clear, so retrying sooner tests a card your own attempt just made harder to charge.
What happens when a subscriber's credit card expires?
UltraCart advances the stored expiration year by three, matching the renewal period most issuers use, so reissued cards with the same number keep processing. If the charge still fails, the customer is emailed a link to update their card and billing address.
Can I use more than one payment gateway for subscriptions?
Yes, though rebills behave differently. New orders distribute across gateways by traffic percentage, and a decline cascades to the next available gateway. Rebills stay on the gateway that processed the original transaction, because many gateways will not authorize without a security code unless they handled that original charge.
How do I switch payment processors without losing subscribers?
Add the new gateway alongside the existing one rather than cutting over. Shift traffic gradually so payments that succeed move there while declines fall back and get flagged. To finish, set the old gateway to zero percent traffic but leave it active so refunds and in-flight rebills still work.
Recurring revenue is worth protecting precisely because it arrives without anyone doing anything, which is why a misconfiguration can run for months unnoticed. To see this on a cart where billing, checkout, and card storage are one system, start a free trial and set up a test subscription.
