In short
- Separate payment collection from the delivery schedule.
- Compare costs and remaining obligations across both models.
- Test skips, cancellation and end-of-term behaviour.
- Verify app limits before combining prepaid and build-a-box.
Here, pay-as-you-go means pay per scheduled delivery rather than metered software usage. Prepaid and pay-as-you-go subscriptions distribute customer commitment, cash collection and fulfilment differently. The better model depends on the use case and the business's ability to deliver future obligations, not simply which option collects more money initially.
Separate payment timing from delivery timing
A prepaid plan can collect for several deliveries in advance. A pay-as-you-go plan can charge for each scheduled cycle. Define what is included, how many deliveries occur and what happens at the end of the term.
Do not describe cash received upfront as profit. Future fulfilment, refunds and service obligations still need to be modelled and handled under the business's approved accounting and policy process.
Match commitment to the customer need
Prepaid can be relevant to a defined gift or a known period of use. Pay-as-you-go can suit replenishment where flexibility matters. These are use-case hypotheses, not guarantees of better conversion or retention.
Keep the continuing commitment and renewal behaviour clear. A finite prepaid term and an automatically renewing offer should not be presented as equivalent.
Compare the complete economics
Model discounts, payment costs, shipping, product cost, support and refunds. Include the effect of collecting cash at different times and the capacity needed for future deliveries.
Use a defined cost basis and realistic scenarios. Request current app terms and confirm whether the intended billing and delivery configuration is supported. A storefront selector does not establish every downstream workflow.
Define changes and cancellation clearly
Specify permitted address changes, skips, delays, substitutions, cancellation and unused deliveries. Have the responsible team approve the terms and applicable requirements before publishing them.
Test what customers and staff see after each action. A change can affect one shipment, later shipments or the whole plan; those consequences should be explicit.
Pilot the offer and fulfilment
Choose a focused product set and test purchase, scheduled delivery, customer access, payment failure where relevant and end-of-term behaviour. Inspect the resulting records and notifications.
Keep unresolved exceptions visible and assign an owner. Do not expand acquisition until the team can explain and operate the commitment.
Compare the merchant workflow, not only the payment button
| Decision | Prepaid | Pay per delivery |
|---|---|---|
| Collection | One charge covers several planned deliveries | A charge is due for each scheduled cycle |
| Operations | Track remaining paid deliveries and outstanding service | Confirm each cycle can be charged and fulfilled |
| Customer changes | Explain effects on unused deliveries and any balance | Explain the cutoff for the next charge and order |
| End of term | State whether the plan expires or renews | State how the continuing plan can be managed |
Shopify models billing and delivery as separate policies within selling plans. The subscription app and configuration determine which merchant and customer actions are available. Do not assume that changing an offer also changes all existing subscriptions.
Example: a meal plan paid weekly or in advance
In an illustrative meal service, one option bills before each weekly delivery. Another collects for four planned weekly deliveries at the start. The team must confirm what happens when a customer changes an address, misses a menu-selection cutoff, skips a week or reaches the end of the paid term. Test the customer portal, kitchen handoff and remaining-delivery record together.
A build-a-box offer adds another dependency: whether selections and replacements are supported for that billing model. As checked on November 4, 2026, Loop’s prepaid documentation lists bundles as unsupported and distinguishes expiring from renewing prepaid plans. Check the current limitations before promising a prepaid build-a-box combination.
What to bring to a subscription scoping call
Bring the store URL, current subscription app, product and delivery rules, supported markets and proposed term. Include the first billing date, renewal behaviour, cancellation handling and who owns fulfilment exceptions. For an existing programme, reconcile remaining deliveries and next billing dates before changing a customer cohort.
Compare comparable cohorts
Review realised contribution, fulfilment completion, refunds and support effort by plan. A prepaid customer remaining on a contract is not directly comparable to a pay-as-you-go customer actively renewing each cycle.
For ongoing performance checks, use our subscription retention framework alongside the model decision. Scope international subscription commerce with TNM around billing, fulfilment, migration and customer journeys.
Frequently asked questions
In this comparison it means paying for each scheduled delivery or subscription cycle. It does not mean metered software usage. State the charge, delivery interval, permitted changes and any continuing commitment clearly in the offer.
Often the existing store can support purchase options through a compatible subscription app and theme integration. Verify payment eligibility, product setup, portal behaviour and app limitations first. A prepaid option does not automatically support every bundle or build-a-box workflow.
No. The configured plan may expire after the paid deliveries or renew for another term. Loop provides a prepaid auto-renew setting; verify its current behaviour and show the intended term and next charge clearly to the customer. Test the final delivery and renewal or expiry path before launch.
