PrestaShop is built around a single act: one cart, one order, one payment. A subscription assumes the opposite, a commitment that produces payments over time without the customer coming back. Those two models do not meet naturally.
Here is the architecture that works, and the points where implementations break.
Who holds the truth
First decision, and it conditions everything else.
A payment platform like Stripe has a full recurring billing engine: subscriptions, billing cycles, retries, expired card handling. Rebuilding that inside PrestaShop would be a mistake.
The split that holds: Stripe owns the subscription, meaning the cycle, the billing dates and the collection. PrestaShop owns the catalogue, the customer and the orders generated at each billing date.
In practice, every successful charge creates an order in PrestaShop, which then follows your normal picking and shipping process. That is what keeps your statistics, your invoices and your logistics consistent.
The webhooks to listen to
This is the heart of the integration, and where the work actually is.
Five events have to be handled, each with a precise behaviour.
- Successful billing payment. Creates the order in PrestaShop, decrements stock, triggers the confirmation email.
- Failed payment. Creates no order, puts the subscription on hold, triggers the dunning sequence.
- Subscription updated. Change of plan, quantity or date. Has to propagate to the shop side.
- Subscription cancelled. Cuts access if you sell content, stops the shipments if you sell physical goods.
- Payment method expiring. Triggers a reminder before failure, which avoids the interruption.
Three technical rules on webhooks. Verify the signature of every notification, otherwise anyone can create orders on your shop. Handle them idempotently: the same event can be delivered several times, and you must not create two orders. And acknowledge receipt quickly, then process in the background, otherwise the platform treats the call as failed and replays it.
DataFirefly Subscriptions — Subscriptions and Stripe Recurring Payments for PrestaShop 8 & 9The subscription module for PrestaShop 8 and 9: Stripe card-on-file, dunning, self-service customer area.€169.00
Expired cards, the first source of loss
On a subscription, most involuntary cancellations come from a payment method that has become invalid, not from a customer decision.
Three mechanisms stack up to limit the damage. Automatic card updating, offered by the card networks and relayed by the payment platforms, which retrieves the new number with no intervention. The reminder before expiry, triggered a month before the validity end date. And the retry sequence after a failure, spread over one to two weeks rather than repeated the next day.
Plan a grace period during which the service stays active despite the failure. Cutting immediately turns a banking incident into a permanent cancellation.
The checkout: do not mix
A design question often settled too late. A cart containing a subscription and one-off products creates a problem: the first creates a recurring commitment, the second does not.
Two acceptable approaches. The dedicated checkout, where the subscription is taken out on its own, with no way to add anything else. Simpler, clearer for the customer, and the recommended default.
Or the mixed cart, where the initial order contains both, with a single payment that covers the products and starts the subscription. Technically heavier, and you have to be very clear about what will be charged afterwards.
What not to do: allow two different subscriptions in the same cart. The billing cycles diverge immediately and management becomes intractable.
Strong customer authentication
European payment regulation requires cardholder authentication for many transactions. On a subscription, the first payment is authenticated by the customer, the following ones fall under a different framework since they are merchant-initiated.
Two practical consequences. The mandate has to be correctly recorded on the first payment, which the platforms handle provided the payment intent is created with the right parameters. And some billing dates can still require authentication, which means planning a path that brings the customer back to an authentication page, rather than a silent failure.
The legal frame
Three obligations, enforced and regularly missed.
Information before signing up: duration, amount, frequency and cancellation terms have to be visible on the purchase page, not only in the terms and conditions.
Online cancellation, as simple as signing up, reachable from the customer account without having to write or call.
Information before renewal for automatically renewing subscriptions, far enough ahead to leave the customer time to decline.
The three figures of the model
Monthly recurring revenue, which gives the economic base. Monthly churn, separating voluntary cancellations from payment failures, because the remedies differ. And the average lifetime of a subscriber, which follows from the second and determines how much you can spend to acquire one.
The DataFirefly Subscriptions module for PrestaShop puts this architecture in place on PrestaShop 8 and 9: subscriptions backed by Stripe, automatic order creation at each billing date, webhook handling with signature verification, payment failure management and a customer area to change or cancel.