Most users never think about what happens behind a “Generate Link” button. They click, expect a checkout link to appear, copy it, and use it in a campaign, WhatsApp message, QR code, or product offer.
That is how it should be.
But for the app developer, the architecture behind that button matters a lot. If the flow depends on too many services, too many redirects, or too much external glue code, the app becomes harder to maintain and less reliable over time.
That is why, when we started planning the latest update for Checkout Links for Wix, we decided not to only redesign the interface. We also rebuilt the checkout engine behind it.
The goal was simple: move from a hybrid architecture with an external backend and Firestore storage into a more platform-native Wix app built around the modern Wix SDK, Wix eCommerce APIs, Wix Data, and the newer Wix app stack.
This was not a cosmetic refactor. It changed how checkout links are created, stored, displayed, edited, and managed.
The Problem With the Old Architecture
The earlier version of Checkout Links worked, but the architecture had grown into something heavier than it needed to be.
Creating a checkout template involved multiple moving parts. The app created a Wix checkout template, created a checkout from that template, then sent data to an external Render backend, which stored records in Firestore.
That kind of setup can work, especially in an early version of a product. It is common to move fast, connect the pieces, and validate the use case before investing in a cleaner internal structure.
But over time, the downsides become clear.
Every extra service adds another place where something can fail. Every external request adds more complexity. Every separate data layer creates more work when you need to keep records, templates, and merchant actions in sync.
For an app like Checkout Links, this matters because merchants are not using it as a technical toy. They are using it to create links that can generate real sales. If a merchant creates a checkout link for an Instagram campaign, a WhatsApp promo, or a QR code on packaging, that link needs to be stable.
The old architecture also made certain product decisions harder. A free tier, better editing rules, cleaner delete behavior, faster dashboard actions, and richer template previews all become easier when the internal system is designed around the platform instead of around external workarounds.
The Shift: From External Sidecar to Platform-Native
The new version of Checkout Links moves the core flow closer to Wix itself.
Instead of relying on a separate Express backend and Firestore as the main persistence layer, the app now uses Wix eCom and Wix Data more directly. The app creates the checkout template through Wix eCommerce services, stores the relevant record in Wix Data, and keeps the checkout link available from the dashboard without requiring a second “generate” step.
The most important architectural change is that we no longer need to materialize the checkout at template-save time.
In the previous flow, the app created a checkout from the template during the merchant action. In the new flow, the merchant gets a durable template redirect URL. The actual checkout is created when the buyer clicks the link.
That difference sounds technical, but the effect is simple: link creation becomes cleaner, and the buyer-facing checkout is handled closer to the moment it is actually needed.
For merchants, the visible result is a smoother dashboard. Once a template is created, the link is ready to copy, reuse, or turn into a QR code. There is no separate “Create Link” action sitting between the merchant and the link they want to use.
Why the Wix SDK Matters
The move to the newer Wix SDK was not just about updating packages. It was about aligning the app with the direction of the Wix platform.
Instead of treating Wix as something we connect to from the outside, the new architecture uses Wix services as the core of the app. That includes scoped SDK packages for areas like eCommerce, Stores, Data, app management, dashboard behavior, and the design system.
This matters for three reasons.
First, it reduces unnecessary complexity. When the app can use platform-native tools for checkout templates and data storage, there is less need for custom glue code between Wix, an external backend, and a third-party database.
Second, it improves maintainability. A simpler architecture is easier to reason about, test, debug, and extend. That matters when adding features like QR code support, template editing, plan limits, and analytics events.
Third, it makes the app more future-ready. Wix is continuing to improve its modern app development stack. Building around that stack puts Checkout Links in a better position for future updates instead of locking it into older patterns.
What Changed in the Checkout Flow
The old flow had more steps than necessary. A merchant created a checkout template, the app created a checkout from that template, and then the external backend stored the link data.
The new flow is much leaner.
The app creates the checkout template, builds the redirect URL, stores the app record in Wix Data, and makes the link available directly in the dashboard.
That change also improves the mental model for merchants. A checkout template is now treated more like a reusable asset. You create it once, name it, review the products, copy the link, and use it wherever you need it.
This fits the real-world use cases better. Merchants may want to use the same link across WhatsApp messages, Instagram DMs, QR codes, email campaigns, packaging inserts, or event signs. The dashboard should support that kind of reuse without making the merchant regenerate links again and again.
Better Data for a Better Dashboard
The rebuild was not only about the checkout pipeline. We also changed how the dashboard gets the information it needs.
The new version stores richer metadata about each checkout template, including product names, thumbnails, discounts, and estimated cart value. This allows the dashboard to show a more useful merchandising view without constantly re-querying the product catalog for every card.
That is important because a checkout link dashboard should not feel like a raw database table. Merchants need to quickly understand what each link is for.
A template called “Weekend Gift Box Promo” is helpful. But seeing the products, images, value, and link actions directly in the dashboard is much better.
That is the kind of UX improvement that comes from better architecture. When the data model is cleaner, the interface can become clearer too.
Cleaner Delete and Edit Behavior
One of the smaller but important changes is how deletion works.
In the old setup, deleting a record could remove the Firestore document without fully cleaning up the Wix checkout template behind it. That creates the risk of orphaned platform data.
In the new version, deletion is handled more consistently. The app deletes the Wix checkout template and removes the app's Wix Data record together.
Editing also became more structured, especially because of the new free tier. Free users can create one checkout template, but the system needs clear rules around what can and cannot be changed later. That kind of logic should not be scattered around the UI. It needs to be enforced properly in the app engine.
So instead of treating access as a simple “free or paid” flag, the new version uses a capability-based model. The app can decide whether a merchant can create another template, edit an existing one, delete one, or change the product set based on their current plan and state.
That gives us more control without turning the code into a mess.
Supporting the Free Tier
One of the biggest product changes in Checkout Links 6.0 is the new free tier. Every Wix merchant can create one checkout template for free.
That sounds like a pricing decision, but it also depends on architecture.
A free tier is easy to announce and harder to implement cleanly. The system needs to know how many templates the merchant has, what actions they are allowed to take, and how to prevent plan limits from being bypassed.
Because the app now has a cleaner internal model, the free tier can be enforced inside the engine, not just hidden behind front-end UI logic.
That matters because pricing rules should be reliable. If the product says free users get one template, the backend needs to enforce that rule properly.
Supporting Real Wix Stores
Another important part of the rebuild was product catalog support.
Real Wix stores are not all identical. Some use different catalog versions, product structures, variants, and store configurations. A checkout app has to handle that reality.
The new version integrates with the Wix Stores SDK and supports both older and newer catalog patterns. This is not the kind of feature most merchants notice directly, but it matters because it makes the app more reliable across different stores.
A checkout link tool should not only work for one perfect demo store. It should work for real merchants with real catalogs.
Efficiency as a Product Feature
The main benefit of this rebuild is not that the code looks nicer.
The benefit is that the product is now easier to use, easier to maintain, and easier to grow.
The new UI, free tier, QR support, cleaner dashboard, and better edit flows all sit on top of the same architectural decision: reduce unnecessary moving parts and build closer to the Wix platform.
For users, the app still feels simple. Create a checkout template, copy the link, and use it wherever you sell.
But behind that simple flow is a cleaner engine.
That is exactly what good software should do. The user should not need to understand the architecture, but they should feel the benefits: fewer confusing steps, more reliable actions, and a smoother experience.
Building Baseplate Digital Tools the Right Way
Baseplate Digital is not trying to build bloated software. The goal is to build practical tools that solve specific business problems and hold up over time.
For Checkout Links, that meant taking the time to rebuild the foundation instead of only polishing the surface.
A checkout link looks simple from the outside. It is just a URL. But if merchants rely on that URL for campaigns, customer messages, QR codes, packaging inserts, and direct sales, the system behind it needs to be solid.
That is why we moved the checkout engine to a more platform-native Wix SDK architecture.
Not because it sounds impressive. Not because users care about SDK names. But because better architecture creates a better product.
Checkout Links 6.0 is faster to use, easier to try, and better prepared for what comes next.
And that is the point of the rebuild.