Operating a DTC Subscription Box Across Payments, Fulfillment, and Churn

A physical subscription box needs one dependable chain: customer instructions change the correct cycle, an approved payment creates the correct order, and the warehouse ships that order once. Failed renewals, skipped boxes and cancellation requests need equally clear outcomes.

This example uses a US merchant selling one monthly box in dollars through Shopify, an eligible payment gateway and a subscription app built through the Shopify Partner route with the required access. The proposed app owns the schedule and recovery policy; the warehouse owns shipment execution. This is a design example, not a claim that Shopify’s first-party app implements every rule below.

Choose a stack that can sell physical goods#

Verify the merchant entity, product category, recurring-payment support, gateway and delivery markets before accepting customers. Paddle’s acceptable-use guidance excludes physical products and products requiring physical delivery. Its software merchant-of-record offering is therefore not an eligible billing component for this physical-box example. Source: Paddle acceptable use.

For Shopify, confirm the chosen subscription app has the required access and permissions. Shopify’s billing-cycle guide distinguishes approved app access from custom apps created directly in the Shopify admin, which cannot use these subscription capabilities. If using an existing app, verify its actual schedule, skip, cancellation and retry behavior instead of assuming it matches this proposed implementation.

Keep contract, cycle, attempt and order separate#

The subscription contract records the recurring agreement, including items, price and billing and delivery policies. The cycle represents one scheduled period; a billing attempt executes a charge, and a successful attempt creates an order. Shopify describes cycle indices as stable identifiers within a contract and supports cycle-specific changes without rewriting the source agreement. Source: Shopify billing cycles.

Do not use an order-cancellation reason to prove the subscription ended. A customer may cancel one shipment while retaining future renewals, or end future renewals while an already-purchased box still needs fulfillment. Preserve the separate contract and order decisions.

Publish a specific renewal and change policy#

For the illustrative November cycle, the box price is $40 before applicable tax, with shipping included. Renewal is scheduled for November 5 at 09:00 America/New_York. The November box ships by November 9 after confirmed payment and inventory readiness. The app reserves inventory before charging and rechecks availability before release.

The merchant asks customers to submit variant or address changes by noon on November 4 for normal processing. This is an operational cutoff, not a rule that overrides cancellation rights or applicable consumer law. Honor a cancellation received before charge submission; requests that race with a charge require a recorded review and the applicable refund decision.

Use the named time zone and store UTC instants as well. In 2026, November 5 at 09:00 in New York is 14:00 UTC; October 5 at 09:00 is 13:00 UTC. Eastern Time is not a permanent UTC−4 offset. Recalculate future events with time-zone rules instead of adding a fixed number of hours.

Define skip, pause, cancel and reactivation outcomes#

A skip changes the selected cycle without ending the underlying agreement. A pause suspends scheduled billing under the defined policy. Cancellation stops future renewal instructions and has its own effective timestamp. Confirm the affected cycle and next expected bill date to the customer rather than sending a generic “updated” message.

Shopify’s first-party subscription management documentation describes distinct pause, resume, cancel and upcoming-order skip actions. Treat that as evidence of those documented app capabilities, not proof that a different app handles timing or warehouse handoffs the same way. Source: Shopify contract management.

In the proposed model, a midmonth variant upgrade applies at the next renewal with a disclosed price; there is no midcycle proration. Reactivation requires confirmation of the next scheduled cycle and does not automatically charge all skipped boxes. Validate the stored schedule before showing the customer a new date.

Execute one cycle without duplicate charges#

Before billing, atomically claim the eligible cycle in the app’s durable records and recheck contract status, skip instructions, price and inventory. Store the instruction snapshot and one active attempt. Concurrent workers must not each decide independently to charge the same cycle.

Shopify’s subscriptionBillingAttemptCreate mutation can target a cycle and accepts an idempotency key to protect repeated requests. Persist the key for the logical attempt and reuse it for transport retries. An actual later attempt after a confirmed failure is a separate authorized attempt with its own key and link to the same cycle. Source: Shopify billing attempt creation.

A returned API response is not enough to release a box. Retrieve the attempt’s documented outcome and associated transaction and order evidence for the pinned API version. Shopify’s current attempt object exposes state and transactions; several older convenience fields, including ready and order, are deprecated. Keep the integration’s outcome mapping versioned. Source: Shopify attempt object.

If the request times out, keep it unresolved and retrieve the original attempt before creating another charge. Deduplicate callback effects and reconcile missing updates from authoritative records. Do not let a customer payment-update action, support resend and scheduled worker each charge the same cycle while an earlier attempt may still succeed.

Recover failed payments within the shipping promise#

The proposed policy permits at most two additional attempts on November 6 and 7 for an eligible, confirmed temporary failure. These dates are merchant policy requiring gateway and network compatibility, not Shopify defaults. A failure requiring authentication or a new payment method goes to customer action rather than repeated charges against unchanged credentials.

Keep fulfillment held during recovery. A payment recovered by November 7 may still qualify for the November 9 shipment if stock and warehouse capacity are confirmed. If recovery misses that window, obtain the appropriate customer decision for a revised promise or skip outcome before a late charge. Do not charge a box the business can no longer supply on the agreed terms.

After exhausted recovery, this example pauses the contract and marks November unfulfilled. It does not silently cancel the customer. Send the current status, any outstanding decision and the next action. Maintain one failure cohort for the cycle so retries do not inflate the count of customers who failed to pay. See dunning management for the broader recovery process.

Release and reconcile the physical order#

Require confirmed captured payment, an eligible uncanceled order, the correct address and inventory, and one recorded warehouse release. Use a unique order-release record so duplicate events cannot create two packing jobs. A shipment update must change the existing job rather than create another order.

Track packing completion, carrier handoff, shipment movement and delivery confirmation against the promised dates. Give support the same tracking record and name an owner for missed milestones. Separate a warehouse delay from a carrier delay, then apply the agreed customer-update, replacement or refund process. Keep those outcomes linked to the paid order so delivery failures remain visible alongside renewal and churn results.

Handle cancellation after charge and before carrier handoff through a coordinated warehouse stop and authorized refund decision. After shipment, use the applicable return or refund process. Ending future renewals alone does not refund an already-paid order. Partial refunds must remain linked to the original charge and cumulative refunds must not exceed its refundable amount.

For an illustrative $40 sale excluding tax, assume $18 contents, $3 packing, $6 shipping and a $1.46 processing fee. Contribution before other operating costs is $11.54. These are assumptions, not provider prices. Show refunds, replacement shipments and retained fees separately so a recovered payment is not mistaken for a profitable delivered box.

Recognize subscriber loss after the actual outcome#

Choose one metric unit: this example gives each customer one subscription contract. Monthly churn means opening active customers whose subscriptions end during the month, divided by opening active customers. Report paused and skipped customers separately, and keep new starts outside the opening-cohort denominator.

Assume 1,000 active customers at the start of November. Twenty cancel voluntarily. Twenty different customers have failed renewals; 15 recover, while five ultimately have their contracts ended after a later documented decision. Churn is (20 + 5) ÷ 1,000 = 2.5%, split into 2% voluntary and 0.5% payment-related loss. If those five are merely paused under the example recovery policy, recognized churn is instead 2%, with five payment-related pauses reported separately.

Keep on-time delivery, unresolved attempts, refunds and recovery rate beside churn. A first decline is a recovery signal; a shipment delay is a service signal. Neither automatically establishes a lost subscriber.

Verify the cycle before a customer pilot#

Exercise a paid renewal, skip, cancellation before submission, cancellation racing with payment, duplicate event, unresolved attempt, successful recovery and missed shipping cutoff in a nonlive environment. Confirm both customer messages and warehouse outcomes. A limited customer pilot begins only after eligibility and critical controls are established; it is not a substitute for an unknown payment or cancellation path.