Compare
KahunaCart vs Vendure
Vendure combines a Node commerce server, GraphQL APIs and separate storefront starters. KahunaCart integrates the storefront and admin with Grav. Compare customization, order management, hosting and licensing. Documentation verified 2 September 2026.
The short answer
Which fits your project?
Use these requirements to identify the better fit, then check the feature and pricing tables below.
Choose Vendure when
- You need developer-defined order transitions and validation.
- You need multiple sales channels or marketplace sellers.
- You want detailed stock movements and allocation controls.
- Your team prefers GraphQL and typed customization of commerce behavior.
Choose KahunaCart when
- You want a store integrated into a Grav site on PHP hosting.
- You want common product attributes configurable without a database migration.
- You prefer REST endpoints for store integrations.
- You want storefront pages, order emails and invoices supplied together.
- You prefer KahunaCart's site license to the licensing options shown for Vendure.
Headline differences
Deployment, customization and APIs
Storefront deployment
Vendure supports TanStack Start and Next.js starters with browsing, search, cart, checkout and accounts. They provide a starting implementation that your team customizes and deploys separately. KahunaCart's storefront runs within the Grav site.
Licensing
Vendure Core uses GPLv3. Its commercial Platform offers separate licensing and support on a quoted basis. The pricing table records these options; review the applicable license terms for your project.
Custom fields
Vendure custom fields become part of its typed schema and database. Adding one involves configuration and a database migration, with corresponding support in its tools and admin. KahunaCart makes common product attributes configurable in the admin.
APIs
Vendure's Shop and Admin APIs use GraphQL. KahunaCart provides REST endpoints. The choice depends on your team's integrations and preferred development tools.
Order and stock control
Vendure supports formal order transitions, detailed stock movements and developer-defined commerce behavior. These controls are important for complex workflows and are not all available in KahunaCart.
Bookings and rentals
KahunaCart's paid Bookings add-on handles appointments, class places and shared staff or equipment. Rentals requires Bookings and adds nightly stays with seasonal rates. For a Vendure project, evaluate dated availability and booking management separately from stock allocation and order transitions. The new matrix rows distinguish verified extensions from support this review has not established.
Side by side
Feature comparison
Selected categories from the full comparison. Identical rows without additional notes are omitted; the remaining rows show differences in support and availability. Booking and rental rows were checked on 21 September 2026. Bookings and Rentals are paid KahunaCart add-ons. The two point-of-sale rows were checked on 14 October 2026, and Point of Sale is a paid add-on too. Unverified cells indicate that support has not been established.
- ✓ In the box
- + Official add-on
- 3rd Third-party
- ~ Partial
- ✗ Not available
- ? Unverified
Platform, licensing & pricing 6 features
| Feature | KahunaCart | Vendure |
|---|---|---|
| Open-source core | KahunaCart: Not available | Vendure: In the box |
Perpetual licence, so the shop keeps working when updates lapse |
KahunaCart: In the box | Vendure: In the box |
| Not a rental: a licence includes a year of updates, and renewing afterward is optional. If you let it lapse, the shop keeps running exactly as it is. You simply lose the ability to install new versions until you renew. | ||
Host platform is free, with no separate licence on top of the commerce one |
KahunaCart: In the box | Vendure: In the box |
| Grav is free, so there is no CMS licence to buy alongside KahunaCart. Optional features such as Bookings and Rentals are separate paid add-ons; they do not require a paid edition of Grav. | ||
Runs on ordinary shared PHP hosting |
KahunaCart: In the box | Vendure: Not available |
| KahunaCart needs nothing exotic: no queue server, no separate search server, and no extra runtime beyond ordinary PHP. It runs on the same shared hosting an ordinary Grav site runs on, with background tasks handled on a simple schedule rather than a constantly running process. | ||
Zero-config datastore (SQLite or flat file) for a first store |
KahunaCart: In the box | Vendure: Not available |
| A first store needs no database setup at all, since it works out of the box with no server database required. Larger stores can move to a full database server later, and the underlying structure stays the same either way, so switching does not mean starting over. | ||
Released in the last six months (as of August 2026) |
KahunaCart: In the box | Vendure: In the box |
| KahunaCart is a first release. That is the honest caveat on everything else here: the feature set is wide, but there is not yet a long production track record behind it. | ||
Cart & checkout 14 features
| Feature | KahunaCart | Vendure |
|---|---|---|
Cart and order are the same record in different states |
KahunaCart: In the box | Vendure: In the box |
| A cart and the order it becomes are the same record, just at an earlier stage, so nothing gets copied or can disagree between the two. This also means an abandoned cart, a retried payment, and a payment link a merchant sends by hand are all handled the same simple way rather than needing separate systems. | ||
Guest order converts to an account afterwards |
KahunaCart: In the box | Vendure: In the box |
| A guest shopper is offered the chance to create an account on the receipt and in their order emails. That account is only created once the order actually completes, so a declined payment never leaves a half-created account behind. | ||
Cart merge or adoption on login |
KahunaCart: Partial | Vendure: In the box |
| KahunaCart deliberately does not merge carts. If a customer logs in with no items already in their session and exactly one unfinished cart on file, that cart is restored. It never combines two carts together and never touches a cart already in progress, since a silent merge could change a shopper's total without warning. | ||
Multi-step checkout shipped and working |
KahunaCart: In the box | Vendure: Not available |
| A complete, working checkout is included. For physical products, it becomes a two step checkout once you have set up shipping zones, since a shipping cost cannot be calculated before an address is known, and the button always accurately describes what it will do next. | ||
Declarative custom checkout fields with conditional logic |
KahunaCart: In the box | Vendure: In the box |
| The checkout form is a list of fields you edit rather than a template you fork. Every field the checkout draws can be reordered, relabelled, required, hidden or switched off from the admin, and you can add your own: a VAT number, a delivery date, a purchase-order reference. Whether a field is required, whether it is hidden, and what counts as a valid answer are each written with the same rule builder you already use for sales and coupons, so "required when the billing country is in the EU and the customer is a company" is two conditions rather than code. An add-on can add a field the same way, and your edits to that field survive the add-on being switched off and back on. A value posted for a field the checkout is not currently showing is refused rather than quietly stored, so hiding a field really does hide it. Company name and a billing phone number ship as fields you switch on. | ||
Shipping/tax estimate on the cart page before checkout |
KahunaCart: In the box | Vendure: Unverified |
| The shipping and tax estimate shown on the cart page is calculated the same way checkout will actually charge, so the number a shopper sees is not a rough guess. It only asks for a state or postcode when your shipping or tax setup actually needs that detail. One known limitation: if you use a payment provider that handles tax on your behalf, the cart page still shows your store's own local estimate rather than that provider's number. | ||
Express pay (Apple Pay / Google Pay / one-click) |
KahunaCart: In the box | Vendure: Unverified |
| The express-pay region is built into both the cart and the checkout page, and every button that goes in it is drawn to one published style contract, so two wallet buttons from two different providers can never sit at different heights or corner radii. The button itself comes from your payment provider. Stripe ships one, so a Stripe store gets Apple Pay and Google Pay in the region today; on the other gateways the region stays empty until that provider adds a button. Card details still never pass through KahunaCart, which is exactly why the button belongs to the provider rather than to the store. | ||
Abandoned-cart capture |
KahunaCart: In the box | Vendure: Partial |
| A cart is recorded as abandoned once a shopper has reached checkout and provided an email address, rather than counting every visitor who merely added something to a cart and left. | ||
Abandoned-cart recovery email |
KahunaCart: In the box | Vendure: Not available |
| One recovery email per abandoned cart, and optionally one reminder after a delay you choose. That is the whole feature: there is no third message, no campaign builder and no scheduling screen, because longer sequences belong in a marketing tool rather than in a shop. Both messages are switched off by default and stay off through an update, so upgrading KahunaCart never suddenly emails a backlog of old abandoned carts without you choosing to turn it on. | ||
Recovery link that puts the abandoned cart back |
KahunaCart: In the box | Vendure: Not available |
| The recovery email carries a link that puts the whole cart back in one press, so a customer does not have to find nine items again. The link opens a page listing what would come back and what it costs today, and nothing is restored until the customer presses the button, because mail scanners and link previewers follow links in an inbox and would otherwise restore carts nobody asked for. Prices are today's prices: a cart abandoned in March and restored in June is priced as June prices it, and any line whose price has moved is called out by name. A line whose product has been deleted, unpublished or sold out is dropped with a note saying so and the rest of the cart still comes back. A cart counts as recovered once, however many times its link is opened, and you can revoke a single link without affecting any other link the store has sent. The same machinery gives you a share link for a cart you built with a customer over the phone: single-use, short-lived, and it can ask for the email address on the cart before it opens. | ||
Deposits and part payment |
KahunaCart: In the box | Vendure: Not available |
| A customer can pay part of an order now and the rest later. Each order gets one payment collection holding a row per attempt, marked as the deposit, the balance or a refund. The order is not treated as paid until the balance clears, and it carries a part-paid status of its own that reports and add-ons read rather than working it out from the amounts. The balance is collected through the same pay link the order already has, so there is nothing new for a customer to learn, and a Collect balance action chases it with a message that says what the order comes to, what has been paid and what is left, recorded on the order so anyone can see it was sent. Refunding just the deposit is an ordinary refund against that collection, and a payment notification that arrives twice cannot take the money twice. | ||
Minimum, maximum and pack-size quantities per product |
KahunaCart: In the box | Vendure: Unverified |
| A product can set the smallest quantity one order may hold, the largest, and a pack size the quantity has to be a multiple of, so beer sells by the six and tiles by the box of ten. A variant can override any of the three, and a blank box means inherit rather than no limit. One per order is a single tick that wins over all of it. The minimum rounds up to the next multiple and the maximum down, so every number the shop prints is a quantity the store will actually sell, and the maximum comes down to the stock on hand for a variant that will not sell below zero. The quantity box on the product page and in the cart carries the numbers with a sentence saying the rule in words, and the same rule is checked again at add-to-cart, at the quantity box and at checkout, so a basket built before the rule existed is refused before money moves rather than after. | ||
Quantity rules set on a category and inherited |
KahunaCart: In the box | Vendure: Unverified |
| The same three numbers sit on a category, and everything filed in it and in every category under it inherits them, so a wholesale department sold in sixes is three numbers typed once rather than three numbers typed on six hundred products. A product's own value overrides the category field by field, so a product with its own minimum in a category with a minimum and a maximum keeps its minimum and takes the category's maximum. Where a product is in two categories that disagree the stricter rule wins each field: the highest minimum, the lowest maximum, the largest pack size. One tick on a product takes it out of its categories' rules altogether, for the single-bottle sampler filed under a department sold in sixes. | ||
Store-wide minimum and maximum order |
KahunaCart: In the box | Vendure: Unverified |
| Four settings say what the whole basket has to be: the fewest and the most items across every line, and the smallest and largest the order may come to in money. All four are off until you set them. The two money rules read the merchandise subtotal after discounts and before shipping and tax, so nobody reaches a minimum by paying for postage and nobody misses one because tax is added at the last step. A basket outside the rules is told so at the top of the cart page with the checkout button left where it was, and a shopper who walks past the sentence is refused at checkout with the same words. One tick takes a product out of all four, so a store with a fifty-pound minimum can still sell a twenty-five-pound gift card on its own. | ||
Orders 14 features
| Feature | KahunaCart | Vendure |
|---|---|---|
Sequential order numbers from an atomic sequence |
KahunaCart: In the box | Vendure: In the box |
| Order numbers are assigned in sequence and never change once given out. Deleting an order leaves a gap in the sequence rather than renumbering the orders around it, so a number a customer already has on their receipt can never change. Every order also carries a short payment reference for bank transfers, printed on the receipt, the invoice and the pay page and available to drop into your payment instructions. It leaves out every character pair people confuse when copying by hand, so no zero and letter O, no one and letter I, and it does not tell anyone who pays you how many orders you have taken. | ||
Invoice number from its own sequence |
KahunaCart: In the box | Vendure: Unverified |
| Invoices get their own separate, gapless numbering sequence apart from the order number, which several EU countries require. You can set the starting number and format, and optionally have it reset each year. | ||
Merchant-defined order statuses |
KahunaCart: In the box | Vendure: In the box |
| You can create your own order statuses, with your own names, colours and order, and switch any of them off. Each status can be marked as counting toward payment, affecting stock, or being a final state, and the store's logic works off those settings rather than the status name, so renaming a status never breaks anything relying on it. A status cannot be deleted while orders are still using it. Each status can also carry a customer-facing name, so Picking, Packed and At the framer can all read as "Preparing your order" to the customer while you keep three separate states, three counts and three filters in the admin. Leave it blank and the customer sees the status name itself, which is what every store gets until it chooses otherwise. | ||
Order state machine with legal transitions |
KahunaCart: Partial | Vendure: In the box |
| There is no formal list of which order status can legally follow which. What does exist is a single, consistent path for changing status that always records the change in the order's history, plus rules tied to specific flags, such as allowing refunds only on statuses flagged complete, and requiring a final order to be explicitly unlocked before it can be edited again. It is closer to consistent guardrails than a fully declared state machine. | ||
Order timeline / history |
KahunaCart: In the box | Vendure: In the box |
| Every order keeps a permanent history: status changes, shipments, cancellations, refunds, and emails sent are all recorded automatically. Add-ons can add their own entries to this history too, and customers see a simplified version of it on their receipt. Alongside it, orders carry notices, which are the things somebody has to be told rather than a log of what happened. A customer is told when a coupon lapsed or a line went away, on the receipt, at checkout and in the confirmation email, and never from the internal record: a notice is built from a fixed list of what a customer may be shown, so an internal status name, a private note or a stored snapshot cannot reach a buyer. You get the other half as a work queue of the orders that need a person, covering negative stock, a coupon redeemed past its limit, a failed webhook or an address that did not validate, and an item leaves the queue when somebody has dealt with it. | ||
Order notes, private and customer-facing |
KahunaCart: In the box | Vendure: In the box |
| You can leave notes on an order, either private notes only staff see, or notes that get emailed to the customer. A private note can be deleted, but a note already sent to a customer cannot be, since it has already gone out. | ||
Manual / phone order creation in the admin |
KahunaCart: In the box | Vendure: In the box |
| Staff can create an order manually in the admin, for a phone or in-person sale, and it goes through exactly the same process as a website order: numbering, stock deduction, and a confirmation email. The order takes the customer's billing and shipping address, filled in from their address book, so tax and shipping are worked out from it exactly as at checkout, and a customer in a group with its own price list gets those prices. Staff can also record a VAT ID and sell without VAT under the reverse charge. Prices always come from the catalog, there is no way to type in an arbitrary price, and there is no way to add a one-off line item like a custom fee or surcharge. For a shop counter, the Point of Sale add-on gives staff a till, described in the next row. | ||
Point of sale at the counter, on the same stock and orders as the online store |
KahunaCart: Official add-on | Vendure: Not available |
| The Point of Sale add-on turns a tablet, a laptop or a phone into a till on your own site. Staff pick their name, type a PIN and scan or tap products, and the customer pays with cash, a card on a Stripe, Square or SumUp reader, store credit, a gift card or a pay link, or a mix of them. Every counter sale is an ordinary order, using the same products, prices, stock, coupons and customers as the website, and it is taxed at the address of the shop where it was sold. Customers can bring things back to the counter, and someone who owes the rest of a booking or an online order can pay it there. Reports count counter and online sales together and can split them by channel. The till needs a connection to your shop to sell, because there is no offline mode. | ||
Till shifts with a starting float and a cash count at closing |
KahunaCart: Official add-on | Vendure: Not available |
| Each shift starts by counting the float into the drawer, and cash put in or taken out during the day is recorded with a reason and the name of whoever did it. At closing, staff count the drawer by notes and coins or as one total before the till shows what it should hold, so nobody counts towards a number. The till then says whether the drawer balances, is short or is over, and freezes a Z report with the sales, payments and refunds by type, discounts, tax by rate, totals for each member of staff and the cash drawer line by line. An X report shows the shift so far at any time, and a difference bigger than the limit you set sends you a message. | ||
Editing an order after it is placed |
KahunaCart: In the box | Vendure: In the box |
| Orders can be edited after they are placed, such as adding or removing items, changing quantities or prices, and adjusting shipping, address or tax, with every version of the order kept and readable afterward. Lines are never deleted outright, only written off, and an order in a final status must be explicitly unlocked before it can be edited again, with that unlock recorded too. This is an optional setting you turn on, and turning it on is blocked if you have an installed add-on that has not been updated to support it. | ||
Payment link for an unpaid order |
KahunaCart: In the box | Vendure: Unverified |
| You can send a customer a payment link for an unpaid order, offering the same payment methods checkout would normally offer. The link expires after a while rather than staying valid indefinitely. | ||
Customer-facing PDF invoice |
KahunaCart: In the box | Vendure: Not available |
| A printable, downloadable PDF invoice is generated automatically for every order, with no extra software to install. A confirmed refund automatically issues a credit note as well. | ||
Ledger of every provider interaction |
KahunaCart: In the box | Vendure: In the box |
| Every interaction with your payment provider, charges, refunds and everything in between, is logged, with refunds linked back to the original payment they refunded. Incoming notifications from the provider are logged too, with the message content kept only for ones verified as genuine, since that inbound address is public and anyone could attempt to post to it. | ||
Order source attribution (referrer, campaign tags, device) |
KahunaCart: In the box | Vendure: Not available |
| Every order records where it came from: the site that referred the visit, the campaign tags on the link they followed, and whether they were on a phone, a tablet or a desktop. The first visit wins rather than the last. Nothing at all is stored about a visitor who does not order, no third-party service is contacted, and the browser's user agent is read once to work out the device and then dropped rather than kept. Reports break revenue down by any of it, so 'where did this order come from' is a question your store answers on its own rather than one you go and ask an analytics product. | ||
Bookings & rentals 6 features
| Feature | KahunaCart | Vendure |
|---|---|---|
Appointment booking with available time slots |
KahunaCart: Official add-on | Vendure: Unverified |
| Book appointments through the Bookings add-on. Set service durations, opening hours, notice periods and buffers. Customers choose an available time and use the store checkout. | ||
Shared staff and resource availability |
KahunaCart: Official add-on | Vendure: Unverified |
| Bookings checks staff, rooms and equipment across services. A booking can require several resources at once, such as a therapist and a treatment room. Working hours, time off and capacity determine which slots are available. | ||
Group sessions with limited places |
KahunaCart: Official add-on | Vendure: Unverified |
| Bookings supports scheduled classes with a capacity for each session. Sell individual dates or a whole course, keep attendance registers and offer cancelled places to a waiting list. | ||
Nightly accommodation with check-in and check-out dates |
KahunaCart: Official add-on | Vendure: Unverified |
| The Rentals add-on requires Bookings. It adds a date-range picker, nightly stays, guest limits, minimum stays and arrival and departure rules. Sell a whole property or a pool of equivalent rooms through the existing checkout. | ||
Seasonal rates for nightly stays |
KahunaCart: Official add-on | Vendure: Unverified |
| Rentals supports date-based rate bands and weekend prices. Add extra-guest charges and a cleaning fee for each stay. The quoted price is held while the guest completes checkout. | ||
Rental availability import and export through iCal |
KahunaCart: Official add-on | Vendure: Unverified |
| Bookings and Rentals exchange availability with listing sites through iCal feeds. Channel exports omit guest details. Updates are periodic and can leave a double-booking window; this is not a real-time channel manager. See the sync limits. | ||
Developer extensibility 7 features
| Feature | KahunaCart | Vendure |
|---|---|---|
Documented event/hook API |
KahunaCart: In the box | Vendure: In the box |
| Developers get a documented set of events they can hook into to extend or customise how the shop behaves, along with clear rules for registering new features safely. If one add-on's extension has a problem, it fails on its own without breaking the rest of the page. | ||
Insertable calculation pipeline |
KahunaCart: In the box | Vendure: In the box |
| Order totals are built through a clear, ordered series of steps covering pricing, sales, coupons, shipping and tax. Developers can insert an extra step into that sequence to add custom pricing logic, rather than having to rewrite the whole calculation. | ||
Add-ons decide when two cart lines merge |
KahunaCart: In the box | Vendure: Not available |
| Developers can control when two similar items in a cart are kept as separate lines or combined into one, for example when a gift message or custom engraving should keep two otherwise identical items apart. This is a rule most shop platforms hide from you entirely. | ||
Add-ons can register whole admin screens |
KahunaCart: In the box | Vendure: In the box |
| Add-ons and payment providers can add entire new screens and panels into the admin, the customer receipt, order emails and customer account pages, not just tweak an existing template. This lets an add-on offer a full feature rather than asking you to edit template files. | ||
Job queue with retries and backoff |
KahunaCart: In the box | Vendure: In the box |
| Background tasks run through a job queue that safely handles multiple workers at once without duplicating work, retries failed jobs with increasing delays, and lets a task postpone itself to try again later rather than failing outright. There is currently no admin screen for viewing the queue, so it has to be checked from the command line. | ||
CLI commands |
KahunaCart: In the box | Vendure: Partial |
| Eighteen command line commands cover setup, background processing, provider syncing, import and export, sample data, webhooks, search indexing, reporting and diagnostics, so a deployment script or developer can do almost anything the admin screens can do. | ||
Storefront works with JavaScript disabled |
KahunaCart: In the box | Vendure: Not available |
| The storefront works fully with JavaScript turned off. There is no framework and no build step involved, and the small amount of script used only loads on shop pages. Even a saved address picker works without needing an extra page request. | ||
Storefront & theme 6 features
| Feature | KahunaCart | Vendure |
|---|---|---|
Storefront runs without a build step |
KahunaCart: In the box | Vendure: Not available |
| The storefront runs on hand written CSS and plain JavaScript, with no framework, no build step and no external dependencies to install or maintain. The included theme is intentionally lightweight. | ||
Documented CSS custom-property theming contract |
KahunaCart: In the box | Vendure: Not available |
| Theming works through a documented set of style hooks with sensible fallbacks, so a theme can restyle the shop by adjusting colours in one place rather than overriding lots of specific styles. | ||
Merchandised, config-driven shop landing page |
KahunaCart: In the box | Vendure: Not available |
| The shop landing page is built from configurable blocks, each showing featured products, a tag, a category, specific products in a chosen order, or whatever is left over, in a hero, grid or compact layout. Up to twenty blocks can be combined, each product appears only once across the page even if it would match more than one block, and empty blocks are simply skipped. | ||
Live search / instant filters that degrade without JS |
KahunaCart: In the box | Vendure: Not available |
| Live search and instant filtering update just the relevant part of the page instantly when JavaScript is available, and fall back to a normal page reload when it is not, so the storefront always works either way. | ||
First-party storefront theme |
KahunaCart: In the box | Vendure: Not available |
| KahunaCart ships its own free storefront theme, which has no hard dependency on KahunaCart being installed, so it works as a general purpose theme too. It includes no demo content, and is tested to make sure shop links always point to real pages rather than broken placeholders. | ||
SEO structured data emitted by the commerce layer |
KahunaCart: In the box | Vendure: Not available |
| The shop automatically outputs structured data that search engines use to understand products, including price, availability, ratings context, breadcrumbs, and images for social sharing previews. Any theme benefits from this automatically without extra setup. | ||
The other direction
Where Vendure offers more
Vendure lets developers define permitted order transitions, validate changes and explain why a transition was blocked. KahunaCart records status changes and lets staff configure statuses, but does not provide equivalent transition rules.
Vendure exposes customization for promotions, shipping, payment handlers and collection filters. It also lets promotion actions reuse their condition logic. KahunaCart provides its own rules and shipping extension points with a different scope.
Vendure supports multiple channels and currencies, and can assign sellers to channels and split marketplace orders. KahunaCart runs one store.
Vendure records detailed stock movements and allocation reasons, and supports developer validation of cart changes. Its GraphQL APIs are another distinction for teams that rely on typed queries and generated clients.
What it costs
License and ongoing costs
Vendure Core is free under GPLv3. Its separate commercial Platform uses quoted pricing. KahunaCart Bookings and Rentals are optional paid add-ons; the base license totals exclude them.
| KahunaCart | Vendure | |
|---|---|---|
| Commerce licence, year 1 | $249 | $0, GPLv3 Core |
| Year 2 | $99, optional | $0 |
| Licence | Commercial, per site, perpetual | GPLv3 since 3.0, with a plugin licence exception |
| Commercial Platform | Not applicable | Quote required |
| Support | Not separately priced | Included with Platform; not part of Core |
| Runtime | Any PHP host, SQLite by default | Node, plus a relational database |
| Storefront | Integrated, 19 templates and an MIT theme | Official production-ready starters; separate app |
| Transactional emails | 16, included and translated | An email plugin with templates you write |
| Developer access | REST API, plus AI-assistant tool support | GraphQL-first Shop and Admin APIs |
| Custom field | A quick configuration change | Configuration change plus generated/applied migration |
Prices recorded in August 2026. Hosting and development exclusions are noted in the table. The comparison uses KahunaCart's list price. References: pricing page, KahunaCart store.
Migrating
Planning a move from Vendure
Products, variants and option groups map closely to KahunaCart. Channel pricing requires a choice about which prices the destination store will use. Prices in more than one currency can be kept: list each currency in the store's settings and import them in price_EUR-style columns.
Review each facet and map it to an attribute or tag. Decide explicitly how private facets should be handled. Resolve rule-based collection membership at export time so it can be represented in the destination catalog.
Tax categories, rates and zones have corresponding KahunaCart concepts, but should be checked during the mapping.
Export current orders to CSV and create a custom mapping. Vendure-specific transition and status history does not transfer directly. Preserve the source export rather than treating the imported order as a complete historical copy.
Questions
Common questions
What licensing options does Vendure offer?
Vendure Core uses GPLv3, and the commercial Platform offers separate licensing and support on request. Review the published license and plugin exception for your project. The pricing table distinguishes the two options.
Does Vendure include a storefront?
It supports TanStack Start and Next.js starters with browsing, search, cart, checkout and accounts. The storefront remains a separate application to customize and deploy. KahunaCart's storefront runs within Grav.
How do Vendure and Medusa differ?
This assessment highlights Vendure's configurable order transitions and commerce extension points, and Medusa's order-change, exchange and return workflows. Both require a development and hosting setup beyond PHP-only hosting.
Which Vendure features does KahunaCart lack?
Key differences include formal order-transition rules, multiple sales channels and sellers, detailed stock allocation and GraphQL APIs. KahunaCart supports configurable statuses and order history, but not the same control model. See the matrix for individual features.
Keep comparing
Related comparisons
Explore KahunaCart before you decide.
Review the pricing and documentation against your store's requirements.
Buy in the store