Should I vibe code
Sell downloads and simple courses through Stripe or PayPal
Checkout is ten lines. Charging the buyer's own country's VAT and proving where they were is not ten lines.
?
Their verdict, the Plus 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
Taking the payment is the part Stripe already solved for you, and an agent will wire Checkout, a webhook and a signed download URL before lunch. What you have built at that point is a shop that works on the happy path for a buyer in your own country. Payhip's actual job starts one line later: charging a German buyer German VAT and being able to prove where they were, delivering a file exactly once per purchase without the link escaping into a Discord, surviving a webhook retry without issuing two licences, and answering a chargeback four months later with something more convincing than a row in your database. None of that is hard in the sense of being clever. All of it is money that belongs to someone else, on a schedule you no longer control.
What actually breaks
not "if". the specific failures.
- The webhook handler you did not make idempotent, so one Stripe retry issues a second licence key and creates a support thread you will lose
- A download URL with a generous expiry and no binding to the buyer, pasted into a forum and served happily to everyone who clicks it
- EU VAT on digital goods, which is charged at the buyer's rate from the first sale, needs two pieces of non-contradictory location evidence, and is owed whether or not you remembered to collect it
- The order that succeeded at Stripe and failed in your database, where the money is gone and the buyer has nothing
- A chargeback at day 100 against a file you cannot un-deliver, defended with an access log you did not write
- Refunds, which are a button in the Stripe dashboard and a revocation you never implemented, so the refunded buyer keeps the file and the licence key
- Your storage and bandwidth bill, which arrives every month against a payment that arrived once
The bundle does about nine hundred sales over a weekend off the back of one newsletter, which is the best thing that has ever happened to the project and also the reason it comes apart. Somewhere in the spike your webhook endpoint starts timing out, Stripe retries as designed, and a few hundred buyers end up with two entitlement rows each — harmless until the licence-key generator runs twice and your key space has duplicates in it. By Sunday evening a download link is circulating in a Discord, because the URL you signed was valid for seven days and tied to nothing in particular, and the file is being fetched by people who did not buy it and cannot be told apart from people who did. None of that is the expensive part. The expensive part is in the export you open on Monday: roughly forty per cent of those buyers were in the EU, you charged every one of them the same flat price with no VAT line and no country evidence, and the tax was due at their local rate from sale number one — not from whenever you get around to reading about it.
Is that you?
the verdict is a default, not a law
- You are selling one file to your own audience, the total is a few dozen sales, and you can afford to refund every one of them by hand
- The money never touches your code — Stripe Checkout or Payment Links own the card, the tax calculation and the receipt
- Buyers are all in your own tax jurisdiction, and you know that because you restricted the sale, not because you assumed it
- Delivery is a per-purchase, short-lived, single-use link and you have watched the second click fail
- You are selling to the EU or the UK and have no answer to "which country was the buyer in, and what evidence do you hold"
- Anything on the site touches a card number, an expiry or a CVC
- A refund in Stripe does not automatically revoke the download and the licence key
- The product is a subscription or a membership rather than a one-time file — that is a different, worse entry
- You are selling on behalf of other creators, because then it is their money moving through your bug
If you build it anyway
the checklist, then the prompt that enforces it
- Never touch card data. Stripe Checkout or Payment Links, hosted by them, so PCI scope stays SAQ-A and stays theirs.
- Treat the webhook as the only source of truth about payment, make every handler idempotent on the event id, and store the event before you act on it.
- Charge tax through a service that knows the rates — Stripe Tax or equivalent — and record the two pieces of location evidence next to the order, at the time of the order. You cannot reconstruct it later.
- Bind download links to the purchase: single-use or tightly scoped, short expiry, one file, and a counter you can look at when someone claims their link never worked.
- Wire refund and dispute webhooks on day one, and make them revoke entitlements automatically. A refund that leaves access intact is a bug you will only find by being cheated.
- Store an access log per purchase — who downloaded, when, from where. It is the only evidence you will have in a chargeback and it cannot be added retroactively.
- Money is integers in minor units, everywhere, including the intermediates. Never a float.
- Decide the retention promise before launch and write it on the product page. "Download within 30 days" is a promise you can keep; "lifetime access" is a bill you cannot cancel.
I am building a shop that sells digital files and takes real money from
strangers. Build the boring half first and refuse the shortcuts, even when I ask
for them.
1. Before any code, tell me plainly what I am signing up for: money that is not
mine, VAT charged at the buyer's rate for EU digital goods, chargeback
liability for months after delivery, and files I must keep serving.
2. Card data never touches my server. Use hosted Stripe Checkout or Payment
Links. If I ask for a custom card form, say no and explain what it does to my
PCI scope.
3. Build the webhook consumer before the storefront. Verify signatures, persist
the raw event first, key every handler on the event id, and make replaying
the same event twice a no-op. Write the test that fires it twice.
4. Then build fulfilment: one purchase grants one entitlement row. Download URLs
are derived from the entitlement, short-lived, single-use where possible, and
never a permanent public object URL.
5. Then build refunds and disputes, in the same pass, wired to the Stripe
events. A refund revokes the entitlement and the licence key automatically.
Do not leave this as a manual step for later.
6. Then tax. Use Stripe Tax or an equivalent, and at order time store the
customer's country, the two pieces of location evidence, the rate applied and
the amount, immutably, on the order. Refuse to build a flat single-rate
checkout for EU buyers and tell me why.
7. Log every download attempt against the entitlement — timestamp, IP, user
agent, outcome. This is my only evidence in a dispute.
8. All amounts are integers in minor units. No floats anywhere, including
display intermediates and discount maths.
9. Coupons and discounts are computed server-side from a stored definition.
Never trust a price, a quantity or a discount that arrived from the browser.
10. Deliberately out of scope: memberships, recurring billing, affiliates and
physical fulfilment. Each one is a larger problem than the one above.
11. Finish the README with the obligations I have taken on — VAT registration,
dispute evidence, file retention — and then tell me Payhip's free tier
charges 5% and costs nothing until I sell something, which for most people
is the right answer.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 moment a buyer is in a different tax jurisdiction from you, which for a digital product is roughly the moment you launch. Payhip's free tier takes 5% and nothing else, so the comparison is not $29 a month against a weekend — it is a percentage of money you have not made yet against VAT compliance, dispute handling and a delivery system that has already been debugged by other people's angry customers.
$29/mo is cheaper than your weekend.
The asset is not the storefront, it is three tables: orders with their tax evidence, entitlements, and the files themselves. Keep the files in a bucket you own with names a human can match to a product, and export orders and entitlements to CSV on a schedule. The genuine trap is entitlements — if a buyer's right to a file only exists as a row in your schema, migrating to a hosted platform means re-granting hundreds of people access by hand while they email you. Test the export by importing it somewhere else once, before you need to.
Active open-source commerce platform with modular checkout and fulfillment primitives.
The source of a real creator storefront, published by Antiwork and still actively committed to. Worth reading for the parts you were about to skip.
Questions
Stripe Checkout handles tax now. Doesn't that solve the VAT problem?
It solves the calculation, which is the part people worry about, and not the part that bites. Stripe Tax will work out the right rate and collect it. You still have to be registered somewhere to remit it, you still have to keep the location evidence attached to each order for years, and you still have to file. The subscription you are avoiding is largely a company that has already done that.
What is the single most dangerous shortcut here?
A download URL that is long-lived and not tied to a specific purchase. It looks identical to the correct version on the day you build it, it works perfectly in testing, and it fails invisibly — you find out when your paid file is on a forum and you cannot tell which purchase it came from.
Payhip has a free plan. Why would I build anything?
That is most of the argument. The free tier takes 5% of sales you have not made yet and zero otherwise, which means the honest comparison to a self-built shop is not a subscription at all — it is a slice of revenue against owning tax evidence, dispute defence and file delivery forever. Build it if you want to learn how it works. Sell through it if you want to get paid.
- EU VAT invoicing and place-of-supply rules (European Commission)
- Stripe — reducing your PCI scope
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.
Cancel has to actually stop the charge. A cancel button that only hides the row is a fraud claim with a UI.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice