Prepaid (non-Gift) Subscription

overview a prepaid subscription is paid for upfront , in full, at the time of purchase instead of being billed each cycle, the customer buys a fixed number of deliveries (for example, 5 shipments) at a set interval, and those deliveries are then fulfilled over time until the prepaid term is used up a non gift prepaid subscription is one the customer purchased for themselves (as opposed to a gift purchased for someone else, which is covered in its own section) prepaid subscriptions behave quite differently from standard recurring ones they're paid in advance — there's no per cycle charge; the deliveries are already paid for they have a fixed length — they run for a set number of deliveries and then end on their own they can't be paused, skipped, or resumed — because the term is already purchased, these customer self service actions are not available (see available actions below) because of the prepaid model, a prepaid subscription's status is shown using two status fields in the admin state — the overall subscription status ( active , canceled , or inactive ) prepaid state — tracks the progress of the prepaid term itself ( pending , active , completed , or canceled ) these two move together through the lifecycle, with the prepaid state giving the more detailed picture (a processing state — pending, success, or failed — is also shown, reflecting the health of the most recent delivery, just as it does for standard subscriptions ) the sections that follow walk through the prepaid lifecycle, what places a subscription into each status, and how the two status fields line up at each step prepaid state a prepaid subscription progresses through the following stages the prepaid state is the primary indicator of where it is in its term; the state badge mirrors it as shown below pending the prepaid subscription has been purchased but hasn't started delivering yet this is the brief setup stage between the purchase being placed and the subscription becoming ready to fulfill its first delivery a prepaid set to begin on a future start date stays pending until that date what puts it here the prepaid subscription is created in pending at the time of purchase overall state the subscription is being set up and has not yet begun delivering active the prepaid term is underway deliveries are being fulfilled on the set schedule, drawing down the prepaid balance one delivery at a time until the purchased number of deliveries is reached what puts it here the subscription is activated and begins fulfilling deliveries overall state active completed all of the purchased deliveries have been fulfilled and the prepaid term is finished the subscription has run its full course and will not place any more orders this is a natural, successful end what puts it here the final delivery in the prepaid term is fulfilled (the purchased delivery count is reached — e g 3 of 3) where you'll see it completed is shown on the prepaid subscriptions page as the prepaid's state the linked subscription, on its own details page, will instead show a state of inactive note "completed" and "inactive" are the same outcome, shown from two different views on the prepaid subscriptions page, the state describes the prepaid term when every purchased delivery has shipped, this reads completed — meaning the term finished successfully on the subscription → details page, the state describes the subscription itself once the term is done, this reads inactive — meaning the subscription has ended and won't place further orders that same page also shows a prepaid state field, which reads completed , tying the two together so completed answers "did the prepaid term finish?" and inactive answers " is the subscription still running?" for a finished prepaid subscription, both are true at once the term completed, so the subscription is now inactive seeing different words on the two pages is expected — it's not a discrepancy prepaid sub underlying sub canceled the prepaid subscription was ended early , before all of its purchased deliveries were fulfilled because the customer paid upfront, canceling triggers a prorated refund for the deliveries that were paid for but not yet received what puts it here the customer or an admin cancels the subscription (cancellation availability depends on a store setting — see below) refund the unused portion of the term is refunded — either as store credit or back to the original payment method, depending on how the cancellation is processed overall state canceled available actions because a prepaid subscription's term is purchased in advance, the self service actions available on standard subscriptions are intentionally restricted pause, resume, and skip are not available a prepaid subscription's schedule can't be changed this way — there's no charge to defer and no cycle to skip, so these actions are blocked cancel is available only if the store enables prepaid subscription management by default, cancellation is turned off for prepaid subscriptions when a store turns on prepaid subscription management, the cancel action becomes available (and triggers the prorated refund described above) when these actions are unavailable, the admin displays a banner on the subscription note "some actions not available — because this is a pre paid subscription, certain fields are not editable and some actions (like cancel, skip and pause) are not available " what happens at the end of the term when a prepaid subscription fulfills its last purchased delivery, what happens next depends on how it was set up one time prepaid (most common) the subscription completes and goes inactive it does not automatically renew — the customer would need to purchase again to continue renewing prepaid instead of ending, the subscription automatically purchases another prepaid block of the same length and continues delivering the term effectively repeats prepaid that converts to a standard subscription ("rollover") when the prepaid term completes, the original prepaid subscription goes inactive (completed) and a new standard recurring subscription is created to continue service going forward the new subscription is linked back to the prepaid one it was converted from, so the history is traceable (this new subscription then follows the standard/recurring lifecycle documented in that section )