Should I vibe code
Embed a small catalog and hosted checkout into an existing site
If the price lives in the browser, someone will edit it. An embedded cart is a checkout on a page you don't control.
?
Their verdict, the Venture price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Ecwid's trick is that it is not a store, it is a widget — a script tag that drops a catalogue and a checkout into a site somebody else already built. That framing is what makes the DIY version look small, and it is also what makes it dangerous. You will wire hosted checkout to a product list in an afternoon and it will take money correctly on the first try. Then the rest of commerce arrives: inventory that must decrement exactly once against a double-clicked button, shipping rates that depend on weight and destination and are wrong in ways customers notice immediately, US sales tax that is sourced to the buyer's address across thousands of local jurisdictions, EU VAT and distance-selling rules, statutory return rights that are law rather than policy, and — specific to an embedded widget — a cart whose totals are computed by JavaScript on a page you do not control. If the price lives in the browser, somebody will edit the price. None of this is beyond an agent. All of it is other people's money and other people's addresses, and the invoice for getting it wrong arrives months later as a chargeback, a tax assessment or a parcel that was never sent.
What actually breaks
not "if". the specific failures.
- Cart totals computed client-side on a page you do not own, then trusted by a server that should have priced the order itself from its own catalogue
- Inventory decremented when the order is created rather than when payment succeeds, so a spike sells the last unit four times
- The webhook retry you did not make idempotent, which writes a second order and ships a second parcel to a customer who paid once
- Shipping: a carrier rate you cached, a package weight you guessed, and a customer charged six dollars to send a nineteen-dollar box
- US sales tax, which is sourced to the buyer's address across thousands of local jurisdictions and does not become optional because the shop is small
- A refund issued in the payment dashboard that never restocks the item and never cancels the fulfilment job
- Addresses, phone numbers and order history accumulating with no retention rule, on a store that will eventually be handed to somebody else
- The embed itself, dropped onto a client's WordPress where a plugin rewrites your markup, a consent banner blocks your script, and the cart silently does not load
The store does four hundred orders on the Friday, ten times any previous day, and that is the whole reason for everything that follows. Inventory decremented on order-created rather than payment-succeeded, so the eleven remaining units of the one product everybody wanted sold nineteen times; the warehouse — a spare room — finds out on Monday, and eight of those buyers are already tweeting screenshots of their confirmation emails. Meanwhile the shipping estimator, which caches rates by postcode prefix, quoted flat domestic rates on twenty-three orders bound for Canada, and you are absorbing the difference on every one of them. None of that is the expensive part. The expensive part is quiet and arrives in April: you charged every US buyer your own state's rate for eight months, because destination sourcing was a sentence in a help article you skimmed in week one, and the liability sits with you regardless of what you actually collected at checkout.
Is that you?
the verdict is a default, not a law
- The catalogue is a handful of items, the buyers are in your own tax jurisdiction, and you restricted the sale rather than assuming it
- Checkout is entirely hosted — Stripe Checkout, a Payment Link, PayPal's own flow — so no card detail ever reaches your origin
- The server prices every order from its own catalogue and treats anything the browser sends as a request rather than a fact
- You could refund every order this month by hand, with an apology, without it hurting
- You sell physical goods across borders and have no answer to which jurisdiction's tax applies and what evidence you hold
- Anything on the page touches a card number, an expiry or a CVC
- Stock is limited enough that overselling means telling real people their order is cancelled
- You are building it for someone else's business, because then the money moving through your bug is theirs and the reputation is theirs too
- There is no idempotent, signature-verified webhook handler, which is the single most common way an order takes money and never exists
If you build it anyway
the checklist, then the prompt that enforces it
- Hosted checkout only. Stripe Checkout or Payment Links, so card data never reaches your origin and your PCI scope stays at the smallest self-assessment tier.
- Price server-side from your own catalogue. Accept a product id and a quantity from the browser and nothing else — never a price, never a discount, never a total.
- Treat the payment webhook as the only truth about money: verify the signature, store the raw event before acting, key every handler on the event id, and write the test that delivers the same event twice.
- Decrement stock on payment success inside a transaction with a constraint that cannot go negative, and make overselling a database error rather than a customer email.
- Use a tax service that knows the rates, and store the rate, the amount and the buyer's location evidence on the order at the time of the order. It cannot be reconstructed afterwards.
- Wire refund and dispute webhooks on day one so a refund restocks, cancels fulfilment and revokes access automatically. A refund that leaves the workflow running is a bug you discover by being cheated.
- Quote shipping from a live carrier API against real package dimensions, and fail closed — refuse to sell — rather than guessing a rate you will eat.
- Money is integers in minor units everywhere, including intermediate calculations and discounts. Never a float.
- Write the retention rule and the deletion job in the same commit as the customers table, because addresses and phone numbers have a lifetime.
I am building an embeddable store — a catalogue and checkout dropped into an
existing site — taking real money from strangers for physical goods. Build the
unglamorous half first and refuse the shortcuts, even when I push.
1. Before any code, tell me what I am taking on: money that is not mine, sales
tax sourced to the buyer's address, VAT for EU buyers, chargeback liability
months after delivery, statutory returns, and parcels that must arrive.
2. Card data never touches my server: hosted Stripe Checkout or Payment Links,
and refuse a custom card form — tell me what one would do to my PCI scope.
3. The server prices every order from its own catalogue. The browser may send a
product id and a quantity, nothing else. Reject any request carrying a
price, discount or total — this is a widget on a page I do not control, so
assume the client is hostile — and write the test that tries it.
4. Build the webhook consumer before the storefront: verify signatures, persist
the raw event first, key handlers on the event id, make replay a no-op, and
test it by delivering the same event twice.
5. Then inventory. Decrement on payment success, in a transaction, with a
non-negative constraint, so overselling fails loudly in the database rather
than quietly in the warehouse.
6. Then refunds and disputes, in the same pass, wired to the provider's events:
restock, cancel fulfilment, revoke anything digital. Never a manual step.
7. Then tax. Use a tax service and store the applied rate, the amount and the
buyer's location evidence immutably on the order. Refuse to hard-code a
single rate for out-of-jurisdiction buyers, and tell me why.
8. Shipping quotes come from a live carrier API using real weights and
dimensions. If no quote can be obtained, block the sale rather than guess.
9. All amounts are integers in minor units. No floats anywhere.
10. Retention rule and deletion job in the same commit as the customers table.
11. Out of scope: subscriptions, marketplaces, POS, multi-currency, wholesale.
12. Finish with the obligations I just took on, and Ecwid Venture's monthly
price, and let me decide again.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
The shop is how the business gets paid. Thirty-five dollars a month — five, if ten products is enough — buys a checkout that has been through PCI review, tax tables maintained by people who read tax updates for a living, carrier integrations already debugged against real parcels, and an admin an owner can use without you. The comparison is not a subscription against a weekend. It is a subscription against being permanently on call for other people's orders, in a system where the bugs invoice you in April.
$35/mo is cheaper than your weekend.
The store is not the asset; three tables are — products, orders with their tax and location evidence, and customers. Export all three to CSV on a schedule and confirm once that another platform will import them, because discovering your order history is unmigratable is a thing that happens during the migration. Keep product images in a bucket you own with filenames a human can match to a SKU. The payment provider holds its own record of the money, which is a genuine safety net, but nobody else holds your line items, your addresses or the evidence you will need if a chargeback lands in month four.
Active open-source commerce platform with modular checkout, inventory and fulfilment primitives.
Headless commerce API with a maintained tax, shipping and payment model, and a fair look at how much of this is genuinely hard.
Questions
Stripe Checkout handles cards and tax. What is left to get wrong?
Everything either side of the payment. Stripe will collect the money and can calculate the tax; it will not decide how many units you have left, whether the parcel weighs what you told the carrier, whether the refund you issued also cancelled the shipping label, or whether you are registered to remit the tax you collected. Taking the payment is the smallest part of taking a payment, and it is the only part that is genuinely solved for you.
Why is this harsher than the digital-goods entries?
Physical fulfilment. A digital sale that goes wrong is a duplicate download or a licence key you can revoke. A physical sale that goes wrong is a parcel that was never sent, or was sent twice, or was priced with shipping you now absorb, and the customer's expectation of it arriving is concrete in a way a file is not. Add destination-based sales tax and carrier rating and you have two whole subsystems that digital goods simply do not have.
It is an embedded widget. Doesn't that make it smaller, not bigger?
It makes the surface bigger, not smaller. Your store now runs as JavaScript on a page controlled by someone else, alongside their plugins, their consent banner and their caching layer. Anything your script computes can be changed before it reaches your server, which is why every price must be recomputed server-side, and why a widget architecture is exactly the wrong place to trust a cart total.
- Stripe — reducing your PCI compliance scope
- PCI Security Standards Council — document library
- EU VAT invoicing and place-of-supply rules (European Commission)
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
Courses, community, email and payments. Pick one to vibe code. Not four with a checkout attached.
Selling a course means owing access to it for years. Your side project does not have years in it.
Checkout is ten lines. Charging the buyer's own country's VAT and proving where they were is not ten lines.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice