Magento 2 and Adobe Commerce have no native subscription or recurring billing engine. The recurring profiles that existed in Magento 1 were dropped, so every subscription store runs on either a payment gateway’s own subscription service or a third-party extension. On Hyva, the subscribe widget and the customer account screens both need a Hyva-ready frontend or they will not render.
For a coffee roaster, a supplements brand, or a B2B consumables seller, subscriptions are the revenue model, not a nice-to-have. Getting them wrong on a Hyva development build means either a broken subscribe button or a slow product page on the exact SKUs that drive lifetime value. This guide covers the two real models, the payment mechanics behind them, and how to keep it all fast on Alpine.js.
There is no native Magento subscription engine
This is the single fact most subscription projects get wrong at the start. Magento 1 had recurring payment profiles tied to PayPal. Magento 2 removed that. Adobe Commerce, even the paid edition, does not ship a product-level subscribe-and-save engine. What Adobe Commerce does give you is the plumbing: the Vault for stored payment methods, and integrations with gateways that run subscriptions on their side.
So when a merchant asks whether Magento “supports subscriptions,” the honest answer is that Magento supports the payment storage and the order model, but the subscription logic itself comes from one of two places. You choose the model first, then worry about Hyva.
The two models: gateway-native versus extension
Every Magento subscription setup is a variation of one of these two patterns. They have different failure modes, different reporting, and a very different Hyva story.
| Gateway-native subscriptions | Magento subscription extension | |
|---|---|---|
| Where the billing engine lives | The payment gateway (Stripe, Braintree, Adyen, Adobe Payment Services) | Inside Magento, driven by a module and cron |
| Subscription record of truth | The gateway dashboard | The Magento admin |
| Failed-payment retries (dunning) | Handled by the gateway | Handled by the extension |
| Reporting and MRR | In the gateway | In Magento reports |
| Storefront subscribe UI | Custom or extension-provided | Extension-provided |
| Best for | Simple subscribe-and-pay, fast setup | Complex catalogs, mixed carts, Magento-native ops |
Gateway-native means the gateway owns the recurring schedule. Magento vaults the card, creates the subscription with the gateway, and the gateway charges on schedule and tells Magento when a payment succeeds or fails. This is simpler and offloads the hardest part, dunning, to the gateway. It is a good fit when subscriptions are straightforward and you want the gateway’s billing reliability.
Extension-driven means a module inside Magento holds the subscription schedule, runs on cron, and charges the vaulted card each cycle through the gateway. Aheadworks, Amasty, MageDelight, and several others sell this model. It keeps subscription orders, customers, and reporting inside Magento, which merchants who run everything from the admin prefer, and it handles mixed carts (a subscription item and a one-time item together) more naturally. The cost is that you now own the dunning and cron reliability yourself.
Neither is universally right. A single-product subscribe-and-save brand is usually happiest gateway-native. A catalog with dozens of subscribable SKUs, tiered intervals, and B2B contract pricing usually wants the extension model so everything stays in one system.
The payment mechanics that decide everything
Whatever model you pick, recurring billing depends on storing a reusable payment credential. That is the Vault. When a customer subscribes, the gateway tokenizes the card and Magento stores the token, not the card, which keeps PCI scope down. Future charges use the token.
Three things follow from this:
- Your gateway has to support vaulting and off-session charges. Braintree, Adyen, Stripe, and Adobe Payment Services all do. Some regional or legacy gateways do not, which quietly rules out subscriptions before you have written a line of code.
- Strong Customer Authentication and 3D Secure change the flow. For European buyers, the first charge may need SCA, and later off-session charges rely on the exemptions the gateway negotiates. Get this wrong and renewals fail at scale.
- Wallets complicate reuse. A PayPal or Apple Pay first payment does not always vault cleanly for off-session recurring use, so confirm the wallet path supports the recurring schedule you are selling.
These are gateway decisions, and they matter more than the extension you pick. Adobe’s own documentation on Magento payment methods and gateways is the place to confirm what your gateway supports before committing.
What breaks on Hyva, and where
A subscription touches three storefront surfaces, and each one is a place the default extension frontend can fail on Hyva.
- The product page subscribe widget. The “one-time or subscribe and save” selector, interval picker, and price change are interactive. Most subscription extensions build this in Knockout or jQuery, which does not run on Hyva’s Alpine.js stack. If the widget does not render, the customer cannot subscribe at all, and this is the highest-impact break.
- Checkout. Hyva favors a native checkout, and the subscription has to attach its schedule and terms to the order there. An extension that injects Knockout checkout steps will not render on a Hyva checkout without adaptation.
- The customer account “my subscriptions” area. Pause, skip, swap, and cancel all live here. If this screen breaks, support tickets replace self-service, which is expensive for exactly the customers you most want to keep.
The pattern mirrors every other Magento feature on Hyva: the backend and APIs work untouched, but any interactive storefront widget built for Luma needs a Hyva-ready version. Some vendors have caught up. Amasty, for example, updated its subscription module to comply with Hyva’s Content Security Policy, and PayTrace’s gateway module is Hyva compatible. The safe move is to confirm Hyva support for your specific extension and gateway combination before you buy, not after.
How to keep subscribe pages fast
Subscribable SKUs are often your best sellers, so a slow subscribe widget taxes your most valuable traffic. Practitioner rules that keep it fast on Hyva:
- Render the subscribe selector in Alpine, not a bolted-on Knockout island. A native Alpine widget avoids reloading the legacy JavaScript stack on your best product pages.
- Keep the price recalculation client-side where possible, and fetch only the subscription terms over GraphQL, so toggling one-time versus subscribe does not trigger a full page round trip.
- Do not let the subscribe widget block Largest Contentful Paint. The hero image and price should paint first; the interval picker can hydrate a beat later.
- Serve the my-subscriptions account area as private content, kept out of full page cache, the pattern Hyva prefers over ESI hole-punching.
Done right, a Hyva subscribe page is faster than the Luma version it replaced, which is the whole reason to migrate. Done as a graft, it can be slower on the pages that matter most.
Dunning: the part that quietly decides revenue
The unglamorous truth of subscriptions is that most churn is involuntary: a card expires, a charge is declined, a bank flags it. How your setup retries failed payments (dunning) decides how much of that revenue you recover.
Gateway-native setups inherit the gateway’s retry logic and card-updater services, which are usually excellent; Stripe’s subscription lifecycle and smart retries documentation is a good reference for what mature dunning looks like. Extension-driven setups depend on the module’s dunning features and your cron health, so a stuck cron can silently stop renewals across your whole book. If you run the extension model, monitor cron and indexer health the same way you would protect any revenue-critical queue, and confirm the extension supports smart retries and expiry notifications before launch.
Where subscriptions fit in your platform choice
Subscriptions are one reason merchants weigh platforms. Magento and Adobe Commerce give you the most control and the deepest catalog and B2B model, which is why complex or B2B subscription programs live here, supported by Magento development and the wider Bemeir technology partners ecosystem across payments and fraud. Simpler DTC subscription brands sometimes fit Shopify with a subscription app, while Shopware and BigCommerce each have their own subscription paths. The right answer depends on catalog complexity, B2B needs, and how much you want to own versus outsource.
For the payment side of a subscription build, our guide on Magento payment gateways on Hyva compares Adyen, Stripe, Braintree, and Authorize.net, and the B2B payment on account guide covers company credit for subscription-adjacent B2B billing. If you want to know who does this work, the about Bemeir page introduces the team, and you can start any subscription conversation from the Bemeir homepage.
FAQ
Does Magento or Adobe Commerce support subscriptions natively?
No. Magento 2 and Adobe Commerce have no native subscription engine. Magento 1 had recurring payment profiles, but Magento 2 dropped them. Subscriptions come from either a payment gateway’s own subscription service or a third-party Magento extension. The platform provides the payment vaulting and order model, not the recurring logic.
Which is better, gateway-native subscriptions or a Magento extension?
Gateway-native is simpler and offloads dunning to the gateway, which suits straightforward subscribe-and-save brands. A Magento extension keeps subscriptions, customers, and reporting inside the admin and handles mixed carts and complex catalogs better, at the cost of owning dunning and cron reliability yourself. Match the model to your catalog complexity.
Will my subscription extension work on a Hyva theme?
Only if it ships a Hyva-ready frontend. The subscribe widget, checkout steps, and my-subscriptions account area are interactive and are often built in Knockout or jQuery, which Hyva does not load. Some vendors now offer Hyva-compatible or CSP-compliant versions. Confirm Hyva support for your exact extension and gateway before purchasing.
What payment gateways support Magento recurring billing?
Gateways that support vaulting and off-session charges, including Braintree, Adyen, Stripe, and Adobe Payment Services. Some regional or legacy gateways do not support reusable tokens for recurring charges, which rules out subscriptions on them. Confirm SCA and 3D Secure handling for renewals if you sell to European customers.
How do I stop subscription renewals from failing?
Most subscription churn is involuntary, from expired or declined cards. Use a gateway with card-updater and smart retry services, or an extension with strong dunning features, and monitor cron health closely if the extension runs the billing. Send expiry notifications before renewals fail rather than after.
Do subscriptions slow down my Hyva product pages?
They can if the subscribe widget is a grafted Knockout island that reloads the legacy JavaScript stack. Built natively in Alpine, with subscription terms fetched over GraphQL and the widget hydrating after the hero and price paint, a Hyva subscribe page is faster than the Luma equivalent. The mistake is bolting the old widget onto a new theme.
Subscriptions are where a storefront’s speed and its billing reliability meet. On Hyva, both are winnable, but only if the model, the gateway, and the frontend are chosen together rather than discovered one broken widget at a time. That joined-up decision is the work Bemeir does on subscription builds.
