To stop subscription billing after a fixed number of payments, configure a finite payment limit and verify the successful-payment count on the individual subscription. Separate that billing boundary from the programme's service or access end. Six collection attempts, six elapsed months and six successful payments are different records.
This checklist is for a training business collecting a fixed programme price in a limited series. It is not a cancellation-policy template or a recommendation to sell an indefinite membership when the offer is a finite commitment. Explain the total, schedule and ending conditions before checkout.
What does the payment limit actually control?
The PayRequest Billing Cycles documentation describes payment limits, Payments Made, Payments Total and Remaining. Once the configured number of successful payments is reached, the subscription becomes Completed and regular future billing stops. Access is governed separately by the business's workflow.
The product code reviewed on 8 October 2026 carries a finite product's duration limit into a new subscription's payment total. It increments the recorded counter through the successful-payment method and clears the next billing date on completion. Check the actual subscription record rather than assuming that editing the product changes every existing contract.
Define the finite offer before setting the count
For an original fictional example, a training company sells one programme for €600, collected as six recurring payments of €100. Assume the agreed total includes everything in this example, with no separate setup fee, discount or tax adjustment. Six times €100 equals €600; the example is not a PayRequest plan price or a customer's performance result.
Write down the programme, currency, total, individual payment amount, interval, start date and payment limit. Record service dates and access terms separately. If your offer includes a trial, first payment or setup fee, inspect how those are recorded before promising which events count toward the six.
Count successful payments, not attempts
Suppose the fourth scheduled collection fails once and later succeeds. The original ledger below deliberately includes seven attempts but only six successful payments. It does not model a provider's retry timing.
| Collection event | Result | Successful count | Amount collected in example |
|---|---|---|---|
| Payment 1 | Successful | 1 of 6 | €100 |
| Payment 2 | Successful | 2 of 6 | €200 total |
| Payment 3 | Successful | 3 of 6 | €300 total |
| First attempt at payment 4 | Failed | Still 3 of 6 | Still €300 |
| Later attempt at payment 4 | Successful | 4 of 6 | €400 total |
| Payment 5 | Successful | 5 of 6 | €500 total |
| Payment 6 | Successful | 6 of 6 | €600 total |
A pending transaction belongs in a pending column until its outcome is established. Do not manually raise a successful count merely because the expected calendar date passed. Match each counted event to the actual payment record and avoid counting the same payment twice. The ledger is an illustrative reconciliation worksheet, not a claim that every provider handles retries identically.
Keep completion and service access separate
Payment completion answers whether the agreed billing count has been reached. It does not answer whether a student finished the programme or should still see its materials. WooCommerce's membership/subscription documentation likewise distinguishes billing periods from membership end-date behavior; those particular settings are WooCommerce's, not PayRequest's.
Use two fields in your handoff: “billing complete after six verified payments” and “service/access end under the programme terms.” They may have different dates. Check any connected course, community or external access system instead of assuming it follows a Completed badge automatically.
Check the final payment and any exceptions
Before closing the record, verify the configured total, successful count, amounts and currency, Completed status and future billing schedule. If a provider operation is already pending, check it separately; a local completion state is not evidence that every in-flight operation has finished.
Refunds, disputes and adjustments need their own references. Do not assume a refund decrements the counter or authorizes a replacement charge. Record the gross collections and any return separately; for example, six €100 collections and a later €50 refund yield €550 net returned-and-collected cash, but that arithmetic does not decide the contractual balance or the next action. Investigate before another debit.
Choose a payment boundary, not an indefinite renewal
WooCommerce's subscription-product guide illustrates another product's finite expiration settings. Use such documentation to compare the required job, not to copy labels into PayRequest or presume matching behavior.
For a temporary break rather than a final stop, use the pause-and-resume checklist. For choosing between a term invoice, a pack and ongoing billing, see lesson billing models. Then review one finite product and its individual record with PayRequest Subscriptions.
Editorial note: AI assisted with this article and cover. Published documentation and relevant product code were reviewed on 8 October 2026. The ledger is fictional; no live subscription, retry or access integration was tested.
