Each section below starts with what you see. The plugin states the cause on the order rather than leaving you to find it, so the first step in almost every case is to read the order.

Payments are not being charged automatically

What you see. An admin notice: “Deposits & Payment Plans: scheduled payments are not being charged automatically.” Payments show as awaiting customer instead of paid, and customers are getting payment links.

Find the cause. WooCommerce > Payment plans states how balances on this store are collected and names the payment methods that cannot be charged on a schedule. For one order, open it and read Collection in the Payment plan box. Either way the answer is one of five reasons, each covered below.

Nothing goes uncollected while this is true. The customer is asked to pay instead, and the plan advances the same way when they do.

Reason: WooCommerce Subscriptions is not active

The message. “Charging a saved card automatically needs WooCommerce Subscriptions to be active. Without it, [gateway] has no way to take a payment on a schedule, and WooCommerce on its own does not provide one.”

Cause. WooCommerce Subscriptions is not installed, not active, or its licence has lapsed. Gateways switch their scheduled-charging machinery off when it is absent.

Fix. Install and activate WooCommerce Subscriptions, then confirm at Plugins > Installed Plugins that it is active. New payments will be charged automatically from then on. Existing plans need no repair.

If you do not intend to buy Subscriptions, nothing is broken. This is the documented fallback and the payment-link route is a supported way to run the plugin.

Reason: saved cards are switched off

The message. “[Gateway] can save a customer’s card, but it is not set up to charge one on a schedule. This is nearly always because saved cards are switched off in that gateway’s own settings.”

Fix.

1. Navigate to WooCommerce > Settings > Payments and open your gateway.
2. Find its saved-cards or tokenization setting. It is usually called “Saved cards”, “Tokenization” or “Allow customers to save payment methods”.
3. Turn it on and save.
4. Re-read Collection on an order. It should now read “Automatic, on the card saved with [gateway]”.

Orders placed before you turned this on have no saved card and stay on the payment-link route, and they say so; see the next reason. Only orders placed afterwards can be charged automatically.

If saved cards were already on, that gateway cannot take scheduled payments and there is nothing to fix. Collect by payment link, or take future orders on a gateway that supports WooCommerce Subscriptions.

Reason: no saved card on this order

The message. “No saved card is attached to this order or to the customer’s account, so there is nothing to charge later. This happens on orders placed before saved cards were required at checkout, on orders that paid nothing at checkout, and on orders paid with a method that cannot be saved. Each remaining payment is collected by sending the customer a payment link instead.” Or, on an order with no customer account at all: “This order was placed without a customer account, so no card could be saved and there is nothing to charge later.”

Cause. The gateway can charge saved cards, but this order has none to charge. Every plan checkout now creates an account and saves the card, so on a store running this version the usual causes are an order placed before that was the case, a plan whose deposit is zero so that no card was taken at checkout, an order created by hand or by an import, or a saved card the customer has since deleted from their account.

What the plugin does. The moment such an order is paid it records the reason in an order note, so you are told before the first due date rather than after five failed attempts. Each remaining payment is collected by payment link, and the plan advances the same way when the customer pays.

Fix. Nothing needs repairing on the order. Its remaining payments are collected by payment link: the customer pays each one from My Account > Payment plans with any method your store accepts, and the plan advances exactly as it would on a charge. If you would rather not run the order that way, refund it and re-sell it, and the new checkout saves the card.

Reason: the gateway cannot store a card

The message. “[Gateway] cannot store a card to charge later, so scheduled payments on it are collected by sending the customer a payment link.”

Cause. Some payment methods have no card to store: bank transfer, cheque, cash on delivery, and gateways that redirect away without vaulting.

Fix. There is nothing to repair on that order. To collect automatically in future, offer a gateway that supports WooCommerce Subscriptions alongside the one you have. Customers who choose it get automatic collection; the rest get payment links.

Reason: no gateway on the order

The message. “This order carries no payment method”, or “The gateway this order was paid with ([id]) is no longer installed”.

Cause. The order was created without a payment method, usually by hand or by an import, or the gateway it was paid with has since been removed from the site.

Fix. If you removed the gateway by mistake, reinstall it. Otherwise collect by payment link; the customer can pay with any method your store currently accepts.

A gateway takes the full price instead of the deposit

What you see. The product page offers a deposit, but checkout charges the whole amount, or the plan quietly does not apply.

Cause. A few gateways take over scheduling entirely and bypass the amount the store asks for. Rather than let one charge the wrong figure, the plugin refuses the plan on that gateway and records the refusal on the order.

Fix. Read the order notes, which name the gateway and the refusal. Offer a different gateway for plan purchases. Charging a customer more than the storefront quoted is the one outcome the plugin will not produce, so the refusal is deliberate.

A payment failed

What you see. A payment shows as failed, and Last result on the order carries the gateway’s own words: an expired card, insufficient funds, a decline code.

What the plugin does. Retries a bounded number of times, a day apart. Nothing is cancelled. When the retries are spent, the order moves to Payment overdue and a notice tells you.

Fix.

1. Read Last result for the gateway’s reason. It decides everything below.
2. Expired or replaced card: ask the customer to pay from My Account > Payment plans, which lets them pay with a current card.
3. A temporary decline: use Charge now on the order that carries the plan to retry immediately. The payment order records the result; the button is on the parent.
4. A gateway configuration error, such as expired API credentials: fix the gateway settings first, then Charge now.

Some refunds were refused

What you see. A cancel and refund batch with a banner reading “Some refunds were refused”, and one or more orders in the state Refund it yourself with the payment method’s own words in the Result column. The order carries a note beginning “Payment plan: cancel and refund stopped.”

Cause. The payment method refused the refund. The words are the gateway’s: a transaction it cannot find, a charge already settled and past its refund window, expired API credentials, or a method that cannot refund from the store at all.

What the plugin did. Nothing on that order was cancelled and its remaining payments are still scheduled. Anything refunded before the refusal is recorded in the note and is not refunded again. The other orders in the batch were not affected.

Fix. Either refund the order from its own order screen, in WooCommerce’s refund panel or in the gateway’s dashboard, and then cancel the order there, which stops the plan; or fix the cause in the gateway and run Cancel and refund on that order again from Outstanding balances. A second run refunds only what is still outstanding.

A batch reports orders as Not finished

What you see. A batch with the banner “Some orders were not finished” and orders in the state Not finished.

Cause. The background task for those orders never ran. The usual reason is that the plugin was deactivated, or WordPress stopped running its scheduled tasks, while the batch was queued.

Fix. Nothing on those orders was changed. Select them again on Outstanding balances and run the action again. If batches never finish at all, see the section on scheduled tasks below.

An order is stuck at Payment overdue

What it means. A payment is past its date and has not been collected. The status is a request for a decision, not a cancellation, and the plan is still live.

Your options.

• Use Charge now, if the reason for the failure has been dealt with.
• Ask the customer to pay from My Account > Payment plans.
• Refund the order in full to stop the plan and release the customer, or select it with the others on Outstanding balances and use Cancel and refund.

Filter Outstanding balances to “Overdue, needing a decision” to see every order in this state at once.

Nothing is being collected at all, and no payment says why

Cause. WordPress is not running its scheduled tasks. WordPress only runs its schedule when someone loads a page, so a quiet store does nothing unattended.

This is not the WooCommerce Subscriptions question. The schedule runs on Action Scheduler, which is part of WooCommerce, and it is what raises each payment when it falls due. Until a payment has been raised there is nothing to charge and nothing for the customer to pay, so this is the one cause that stops collection on every store, whichever way it collects.

Check. Look at Tools > Scheduled Actions and filter to the carticy-installments group. Actions piling up as pending with dates in the past confirm it.

Fix. Add a real system cron entry and ask your host to confirm it is running:

* * * * * cd /path/to/your/site && wp cron event run --due-now --quiet

Until that is in place you can charge from Outstanding balances by hand, but note that the batch itself also runs as a scheduled task and will sit at Queued until tasks run again.

No plans appear on the product page

Work down this list.

1. Check the licence. Without an active one, products offer no plan and the product editor carries a notice. Existing customers’ schedules keep collecting regardless.
2. Check the product type. Grouped, external, bundle and composite products are refused, and the Payment plans tab says so. On a subscription product the tab does not appear at all.
3. Check the product actually names a plan under Product data > Payment plans.
4. On a variable product, check the variation is not set to inherit from a parent that offers nothing.
5. If a plan counts back from a deadline, check the product has a date in Deadline the plans count back from. Without it that plan is not offered, and the Payment plans tab names it and says so.
6. Clear your page cache. A cached copy of the product page from before you added the plan will not show it.

A payment is due today when the plan said it was due later

This is expected on a plan that counts back from a product’s deadline, when the customer buys inside the offset. A balance due 7 days before an event, bought the day before it, is due on the day of purchase rather than after the event. See Building a Payment Plan.

If it happens on a plan that uses offsets from purchase, check the product’s deadline date has not been left over from a previous event.

Part-paid orders vanished after deactivating the plugin

They did not. Deactivating moves each one to On hold and records where it came from, because a deactivated plugin cannot register its own order statuses and those orders would otherwise show a raw slug or drop out of your order list. Reactivate the plugin and every one goes back exactly where it was. No balance is lost and no customer is emailed.

Still having issues?

Contact support with your WordPress, WooCommerce and PHP versions, the gateway you take plan payments on, whether WooCommerce Subscriptions is active, the order number, and the exact text of Collection and Last result from that order’s Payment plan box.