Should I vibe code
Sell digital files and simple subscriptions from a user-owned storefront
Sellfy isn't the merchant of record and neither is Stripe. The VAT on that Berlin sale is yours.
?
Their verdict, the Starter 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
Stripe Checkout, a webhook, a signed download link: an agent gets you a working store before the coffee goes cold, and for a one-off sale to a buyer in your own country it is genuinely fine. Sellfy's actual shape is what makes this a bad weekend. It is not a checkout — it is a shop that also renews subscriptions monthly, mails your customer list, and in the print-on-demand case ships physical objects to addresses you are now storing. And Sellfy is explicitly not the merchant of record, which means the same is true of your version: the VAT on a sale to Munich is yours to charge, evidence and remit, with two pieces of non-contradictory location evidence you were probably not collecting. Each of those obligations is quiet. A card that expires does not throw an exception, a cancel button that only updates your own table keeps taking money, and a broadcast to two thousand buyers is one send away from your domain's mail reputation. The store is a weekend. What you signed up for is a set of promises that keep coming due while you are busy with something else.
What actually breaks
not "if". the specific failures.
- Fulfilment after payment, the classic ordering bug: the charge succeeds, the process dies before the delivery email, and the buyer has a receipt and no file
- Webhook retries, which arrive because Stripe is being careful and become two licences, two emails and two charges if the handler is not idempotent
- Download links, which escape into a Discord within a week unless they are short-lived, single-use and tied to the order
- VAT, charged at your own country's rate to an EU buyer, or not charged at all, with no location evidence retained and nothing that produces a quarterly return
- B2B reverse charge, where a business buyer enters a VAT number nobody validated against VIES and you have charged tax you should not have
- Cancellation, when your app marks the subscription cancelled locally and never tells Stripe, so the card keeps being charged by a system that thinks it stopped
- Failed renewals, because you never wrote the dunning schedule — the card expires, the payment fails once, and a paying member is silently locked out
- Chargebacks four months later, answered with a row in your database instead of delivery logs, IP evidence and the terms the buyer accepted
- The marketing email, which is bulk email from your own domain and needs SPF, DKIM, a working unsubscribe and a suppression list before the first send
- Physical and print-on-demand orders, which drag in shipping addresses, tax on goods, fulfilment partner failures and a returns process
Launch day goes well, which is the problem. Two hundred people buy in the first hour, and somewhere in that hour your delivery step — which runs after the payment intent succeeds, in the same request, without a queue — starts timing out against the storage provider. Stripe has the money. Your database has orders marked paid. Roughly forty buyers have a receipt and no download email, and the ones who retry get a link that 403s because the signed URL was generated against a key that rotated at midnight. You find out from Twitter, not from monitoring, because there is no alert for "paid but not delivered" — there is no such state in your schema, since the two things happened in the same function and could not diverge. Reconstructing who got what means diffing Stripe's payment list against your orders table by email address, at two in the morning, while replies pile up in an inbox from people who are perfectly reasonable and would simply like the file they paid for.
Is that you?
the verdict is a default, not a law
- You are selling one product, in your own country, to buyers you could refund by hand
- Checkout is hosted by Stripe or Paddle and no card detail ever reaches your server
- Every sale is one-off — no renewals, no memberships, no stored payment schedule
- Delivery is durable: the entitlement is written before the response returns, and the email is a retryable job on top of it
- You are selling across borders and have not decided who determines, charges and remits the VAT
- Anything renews, and you have not written cancellation, dunning and proration before launch
- The store also emails your buyer list, which is a separate discipline with its own reputation and consent rules
- Download links are permanent URLs, or the file sits in a public bucket with a guessable name
- You cannot answer a chargeback with delivery evidence — timestamps, IP, the accepted terms and the download record
- You are adding print-on-demand or physical goods, which is a second business with shipping, addresses and returns attached
If you build it anyway
the checklist, then the prompt that enforces it
- Hosted checkout only, with the amount created server-side. Never let a price arrive from the browser and never let a card near your infrastructure.
- Make webhooks idempotent on the event ID and the payment intent, and store processed events. Stripe will retry, and a retry must never mint a second licence.
- Persist the entitlement inside the transaction that records the payment, then deliver as a separate retryable job. "Paid but undelivered" must be a state you can query and alert on.
- Short-lived, single-use, order-bound download URLs with a download counter, served from object storage — never a permanent link, never a public bucket.
- Let a tax engine determine and record VAT rather than a rate table you maintain. Keep the two pieces of location evidence with the order, validate business VAT numbers against VIES, and produce a quarterly report you can actually file.
- Treat the payment provider as the source of truth for subscription state. Cancelling in your database without cancelling at Stripe is how people get charged for a year after they left.
- Write the dunning schedule before launch: retry cadence, the emails, the grace period, and exactly when access ends. Absent that, an expired card silently deletes a paying customer.
- Keep chargeback evidence by default — delivery timestamp, download log, IP, and the version of the terms accepted — because you will need it months after you have forgotten the order.
- If you send marketing email, do it properly: authenticated domain, a real unsubscribe honoured immediately, a suppression list, and a separate sending domain from your receipts.
I am building a storefront that sells digital files and monthly subscriptions and delivers downloads automatically. Other people's money is involved and I am the merchant of record. Build it in this order and refuse the shortcuts. 1. Hosted checkout only — Stripe Checkout or equivalent, amounts created server-side from server-held prices. If I ask you to accept a price from the client, refuse and explain what devtools does to it. 2. Webhook handling before delivery: verify signatures, deduplicate on event ID, stay idempotent. Show me the test where the same event arrives three times and only one entitlement exists. 3. Model the entitlement separately from the email: write it in the same transaction as the payment, deliver via a retryable job, and alert on any order that has been paid and undelivered for five minutes. 4. Download URLs are signed, single-use, expiring, bound to the order and counted. No public buckets, no permanent links, no guessable paths. 5. Tax next, not last. Determine the rate from the buyer's location with a tax engine, store two pieces of location evidence with the order, validate EU business VAT numbers against VIES, and produce a filable quarterly report. If I say I will add VAT later, tell me what my first cross-border sale has already committed me to. 6. Subscriptions: the payment provider is the source of truth. Cancel there first, reflect it locally second, and write the dunning schedule — retries, emails, grace period, end of access — before the members area. 7. Store delivery timestamps, download logs, buyer IP and the accepted terms version with every order, and give me one screen that assembles chargeback evidence. Invoice numbers are sequential, immutable and never reused. 8. Marketing email is a separate system: authenticated sending domain distinct from receipts, real unsubscribe, suppression list, no send without a preview. 9. Out of scope for v1: print-on-demand, physical shipping, affiliates. Then price the alternative honestly — $29 a month at 0% transaction fees against the hours in items 5, 6 and 7.
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
At the first sale to a different country, which for a digital product is roughly the first week. $29 a month with no transaction fee buys the parts of this entry that are dangerous rather than fun — location-based VAT with the evidence trail, subscription lifecycle including dunning, delivery that survives a webhook retry, and dispute handling that has been argued with real banks. Build your own if you are selling one file to a domestic audience, and even then let hosted checkout do the money.
$29/mo is cheaper than your weekend.
Keep the money and the entitlements somewhere you do not own. Stripe holds subscriptions, customers and payment history; your database should hold products, orders and an entitlement record keyed on the Stripe customer, with files in object storage under stable names. Migrating to Sellfy or Payhip is then re-uploading products and re-issuing download links, which is a day. The parts that do not migrate are the ones to plan for: live subscriptions have to be moved at the payment provider rather than in your database, old download URLs will keep being clicked by people who bookmarked them, and your VAT records have to stay readable for years after the store is gone — export them as files, not as a database you will not keep running.
Open-source commerce platform with modular checkout, order and fulfilment primitives — the storefront half, with tax determination still your problem.
Questions
How does this differ from the Payhip and Podia entries?
Payhip is the one-off digital sale: take the money, deliver the file, get the VAT right. Podia is a recurring membership with a video library that has to keep playing for someone who paid two years ago, which is why it sits at ABSOLUTELY NOT. Sellfy is deliberately in between — one-off files plus renewing subscriptions plus a mailing list plus, if you enable it, physical goods — so it inherits Payhip's tax problem and Podia's cancel-and-dunning problem without the video bill.
Stripe handles the payment, so what is left to get wrong?
Everything either side of it. Stripe moves money and stays PCI-compliant for you; it does not decide whether a Munich buyer owed 19% VAT, it does not deliver the file, it does not remember that the second webhook was a retry, and it does not stop your app from cancelling a subscription locally while the charge keeps going out. The dangerous code in a store is not the payment call — it is the twenty lines around it.
Is per-country VAT genuinely my problem on a small store?
For digital goods sold to EU consumers, yes, from the first sale — the rate follows the buyer's location, and the usual route is a single OSS return that needs two non-contradictory pieces of evidence about where they were. Sellfy states plainly that it is not the merchant of record: it calculates and reports, and the registration and remittance stay with the seller. If you build the store yourself, you have taken on the same job without the reporting.
- EU VAT invoicing rules (European Commission)
- Stripe — reducing your PCI scope with hosted checkout
- CAN-SPAM Act compliance guide for business (FTC)
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.
Checkout is ten lines. Charging the buyer's own country's VAT and proving where they were is not ten lines.
Cancel has to actually stop the charge. A cancel button that only hides the row is a fraud claim with a UI.
Courses, community, email and payments. Pick one to vibe code. Not four with a checkout attached.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice