You built the page — an AI tool helped, or you wrote it by hand — and now it needs to charge someone. The instinct at this point is that you have hit the wall: no server, no backend, so no money. That instinct is mostly wrong, and it is wrong in a way worth understanding rather than just working around, because the same reasoning decides every other service you might want to add later. Payment providers split their credentials deliberately into a kind that is safe to publish and a kind that is not, and they built an entire client-side integration path around the first one. What you cannot do without a server is keep a secret or enforce a rule — and it is worth knowing which of your requirements are actually those before assuming you need infrastructure.
Try it now
Drop a file — get a private link in seconds. No sign-up.
Drop an HTML, ZIP, PDF, PNG or JPEG file, or click to choose.
One file, or a ZIP bundle. Max 3 MB.
Up to 3 MB, link self-destructs after 7 days. Sign up free to keep links forever, password-protect them, and store more.
Decide which of the two shapes you want, because the effort is very different. A hosted payment link is a URL you generate in the provider's dashboard — Stripe's own documentation describes this as accepting payments online without writing code — and your page simply links to it, so the entire transaction happens on their side. An embedded checkout runs inside your page using a publishable key, which keeps the visitor on your page and asks more of you in setup. For a single product, a booking deposit or an invoice, the link is usually the right answer and takes minutes.
Keep the credential straight, because this is the one place a mistake is expensive. Stripe's documentation states that only publishable keys are safe to expose outside your backend — that key type exists precisely to sit in code that anyone can read. The secret key has a different prefix and must never leave a server. Almost every incident here comes from following a server-side tutorial and not noticing which key it used, so check the prefix before the file goes anywhere.
Then the page needs somewhere to live, and a page that can take money is usually a page you will revise. Upload the .html file, or a ZIP of a built folder — you get a link back in seconds, and when you change the price or the copy you replace the contents at the same address rather than minting a new one, with each upload kept as a numbered version. A password is free on every plan if it is going to specific people; on Studio ($14.99/mo) it runs on your own domain, which reads differently on a page that is asking for a card.
It is safe if it is the right kind of key, and providers make the distinction explicit rather than leaving it to you. Stripe's documentation says that only publishable keys are safe to expose outside your application's backend: that key identifies your account but can only perform the narrow set of operations that are safe for an anonymous stranger to perform. The secret key is a different object with a different prefix and belongs on a server. So the question to ask is never 'can I put a key in this page' — it is 'which of the two am I holding', and the answer is in the provider's own docs.
Where the visitor is standing when they pay, and how much work you do. A payment link is created in a dashboard and is just a URL — your page links to it, the visitor goes to the provider's hosted page, and you write no code at all. An embedded checkout renders inside your page using the publishable key, so nobody leaves, at the cost of some integration. Neither needs a server. If you are not sure, start with the link: it is reversible in an afternoon and it tells you whether anyone actually wants to buy the thing.
Anything where the trust cannot live in the page. Real accounts and sessions, prices that a visitor must not be able to change before submitting, access that unlocks after payment, and receiving webhooks — a provider telling your system that a payment succeeded needs something listening when nobody has the page open. If you need those, use a platform built for it: Vercel and Netlify both take a repository and give you server-side routes and somewhere for secrets to live. That is a genuinely different tool from a page host, including this one.
The number written in your page can be edited by anyone holding it, which is exactly why the provider does not trust it. With a hosted payment link the amount lives in the provider's dashboard, so editing your page changes what it says and not what gets charged. With an embedded checkout the same principle applies as long as the amount comes from an object you created on the provider's side rather than from a value in the page. Treat any number in the file as decoration and let the provider hold the real one.
No, and there are good reasons for it not to be. A private link works exactly the same way — the payment provider does not care how the visitor arrived, only that the checkout was opened. For a proposal with a deposit, a client invoice, or a piece of work priced for one buyer, an unguessable link that stays out of search is usually the shape you want, with a password on top if the number itself is sensitive.
More than most people assume, and the boundary follows the same rule as payments: anything built to be called from a stranger's browser works, and anything that needs to keep a secret or enforce a rule does not. Forms, scheduling, analytics and comments all fall on the working side because they were designed to be embedded in sites their authors do not control.
No card to try, no sign-up to get a link. Sign up free to keep links forever, password-protect them, and store more.