Deposits & Payment Plans for WooCommerce

For automatic collection, yes, and it is worth understanding before you buy. WooCommerce can store a customer’s card but provides nothing to charge one later. That capability lives inside each payment gateway, and every gateway only switches it on when WooCommerce Subscriptions is present. We verified this on four separate gateway families.

Without Subscriptions the plugin still works: you build any schedule you like and the customer pays each instalment from a link or their account, which is what the official deposits plugin does today. It simply is not automatic.

Any gateway that supports WooCommerce Subscriptions, which is around thirty of them, including Stripe, PayPal Payments, WooPayments, Authorize.Net, Braintree, Square, Elavon and Moneris.

That is the honest claim and the one we test against. We do not claim all payment methods, because a gateway that bills on its own schedule bypasses the mechanism entirely. Where that happens the plugin refuses the plan and tells you, rather than silently collecting nothing.

Yes. A plan is an ordered schedule of any length from two upwards, and each entry is independently a fixed amount or a percentage.

$500 now, then three payments of $250 is a normal plan here, not a workaround. Most plugins in this category cap at a deposit and a balance.

Yes, and this is exactly why the deadline rule exists. An entry can be due a number of days, weeks or months counted backwards from a deadline rather than forwards from purchase.

Set the course date on the product and the balance falls due before it, whether the customer books six months ahead or the week before. A fixed offset from checkout cannot do this: someone booking on Friday for a Saturday class would otherwise have thirty days to pay for a course they had already attended.

Yes. Mark which payment releases fulfilment and, until it clears, the order stays in its own status that fulfilment integrations do not pick up.

We confirmed this against WooCommerce’s own Order Fulfillments feature on a live store, with a control order to prove the exclusion was ours and not a coincidence.

It retries on a bounded schedule you control, and each attempt is recorded. When retries are exhausted the order moves to an overdue status and you are told, with the gateway’s own reason attached.

The order is never cancelled silently, because that would destroy money you are owed with no audit trail. Customer dunning emails are optional rather than assumed.

Apportioned. Every entry carries its proportional share of the tax on the goods, per rate, and the shares sum to exactly the tax on the order.

Deferring all tax to the last payment is what the official deposits plugin does, and it confuses merchants in VAT stores. If your prices include tax, the deposit shown on the product page is the deposit taken at checkout. A mismatch between those two is a known bug in this category and it is what the arithmetic was built against.

A refund reduces the plan, and payments already settled are never rewritten. A full refund cancels every remaining payment, stops the schedule, and leaves a note on the order.

The plugin never initiates a refund itself. You refund through WooCommerce as normal and the plan responds correctly.

Yes to both. Plans attach at variation level, not just product level, so different variations can carry different plans or inherit the parent’s.

Classic shortcode checkout and the block (Store API) checkout are both supported, and the amount reaching the gateway is proven identical on each. A discrepancy there is a known failure in this category.

Yes, and it says so rather than half-working.

Grouped and external products are never themselves added to the cart, so a plan on them is meaningless. Product bundles and composite products are one purchase spread across several cart lines, and a schedule computed on any single line is not a schedule for the whole thing, so those are refused with an explanation. Subscription products are not sold on a plan in this version.