On this page
Almost every guide to accepting cryptocurrency quietly assumes you have a website to put it on. Most people who want to get paid in crypto do not. They are designers billing a client three time zones away, developers selling a plugin, tutors, translators, editors, community moderators, artists taking commissions, small studios selling a font or a preset pack — people whose entire commercial surface is a DM, an email thread, a Discord server or a profile page they do not control. For all of them the honest answer is that a checkout is a URL, not a project. This guide is about that URL: how to build one that actually closes a sale, how to make it deliver the goods on its own, and how to turn it into an invoice a client will pay.
Who actually needs a store — and who never did#
A storefront exists to solve three problems: showing a catalogue, taking money, and delivering. If you sell one thing, or a handful, to people who already know what they want, only the second and third are real. Building a site to solve them is like renting a warehouse to post one parcel.
Ask yourself where the buying decision is actually made. If it happens in a conversation — a quote, a commission, a call, a comment thread — then the store adds a click, not a conversion. What you need at that moment is something you can paste into the conversation while it is still warm. If instead people discover you cold and browse before deciding, you need a page. The distinction matters more than any technology choice below, and it is the reason the two routes in the next section exist rather than one.
The one thing you cannot skip: an account to receive the money. With a no-KYC gateway that is roughly thirty seconds and no documents, which is what makes the whole no-website approach practical — otherwise the "no code" part is dwarfed by weeks of onboarding paperwork.
The three no-code routes#
Everything in this guide comes down to three shapes. They are not competitors; most people end up using two of them for different situations.
| Route | Best for | What the buyer gets | Setup |
|---|---|---|---|
| Payment link | One product, one quote, one invoice | A hosted checkout page at a URL you paste anywhere | ~1 minute |
| Hosted shop | A small catalogue people browse | A branded storefront on its own domain | ~15 minutes |
| QR code | In person, on print, on screen | The same checkout, scanned instead of clicked | Instant |
On CryptoPayIn, links live on cryptopaylink.co and shops on shopycrypto.com — separate from the main site, so what you send a client is a clean checkout URL rather than a query string bolted onto someone else's brand. The QR code is not a fourth product; it is any link, rendered as a square. That matters more than it sounds: the same object works in an email, in a chat, on a slide, on an invoice PDF, on a market stall sign and on the back of a business card.
Building a link that closes the sale#
A payment link is a small set of decisions. Each one maps to a real situation, and getting them right is the difference between a link people pay and a link people ask questions about.
Fixed price or buyer-entered amount
Fix the price when you are selling a thing: a preset pack, a licence, a month of support. Leave the amount open when the payer decides how much — tips, donations, deposits, "pay what you owe on this invoice", topping up a balance. One link can serve a whole client base if the amount is theirs to enter, which is exactly the freelancer's case.
Price it in the currency you think in
You quote €400 or $500; the customer pays in Bitcoin, USDT, Monero or whatever they hold. Pricing works in thirty fiat currencies and the crypto amount is computed at the moment the invoice is created, from rates cross-checked against independent sources. That snapshot is then locked for the life of the invoice, so a market move while the buyer finds their wallet is not your problem — and if the rate sources disagree or look stale, the invoice refuses to be created rather than mispricing your work.
Caps, expiry and the sold-out state
A link can be capped: pay it once, pay it fifty times, or let it close itself when the inventory behind it runs out. Use a one-shot link for a specific client invoice — it cannot be forwarded and paid twice by accident. Use an uncapped one for a public product. Invoices themselves expire after thirty minutes by default and can be set up to twenty-four hours; the window is about rate risk, not about you, and a buyer who misses it simply gets a new one. Funds that land late still credit.
Ask the buyer what you will need to deliver
Add custom fields to the checkout and the answers ride along with the payment: a delivery email, an in-game username, a Discord handle, a domain to activate against, a preferred file format, the name to put on the licence. This is the single most underused feature in no-code selling. Every field you add here is a support email you never have to send, and the answers are visible only to you.
Test it as a stranger. Open your own link in a private window on a phone and walk through it. Two minutes of this catches the missing field, the ambiguous product name and the price you set in the wrong currency — all three of which are otherwise discovered by a customer.
Automatic delivery: the part that makes it a product#
A checkout that only takes money leaves you doing the actual work by hand, at whatever hour the payment lands. Attaching the delivery to the link is what converts "I accept crypto" into something that runs while you sleep, and it is the difference between a payment tool and a sales channel.
Three kinds of delivery cover almost everything sold without a website:
- A message. Arbitrary text revealed on the receipt once payment confirms: access instructions, a coupon, a private address, a scheduling link, the next step. The simplest and the most flexible.
- A download or a redirect. The buyer lands on the file or the private page immediately after confirmation — the natural fit for digital goods, courses, templates and packs.
- Licence keys. Upload a pool of up to ten thousand keys and one is handed out per payment, never reused. When the pool empties, the link closes itself rather than selling something you cannot deliver.
That last one deserves emphasis, because it quietly solves the hardest problem in unattended selling: inventory that must not be double-sold. Keys, seats, codes, invitations, numbered editions — anything finite and unique. The link becomes the inventory system, and there is nothing to reconcile at the end of the week.
Delivery appears on the buyer's receipt the moment the payment confirms — which, depending on the network they chose, is seconds to about twenty minutes. Nobody waits on you, and there is no "please allow 24 hours" line in your description.
When one link becomes a storefront#
The moment you have more than a handful of products, or you want people to browse before they decide, a link per item stops being enough. A hosted shop groups them onto one branded page with its own URL, no code and no hosting: pick a theme, add products, preview it live, publish.
Variants and inventory
Each product can carry up to thirty variant combinations — sizes, tiers, editions, durations, seat counts — each with its own price and its own key inventory. That is the part that makes a shop more than a pretty list: "Standard / Pro / Studio" is three independent products in every way that matters, presented as one choice.
Physical goods and shipping
Selling something you post rather than send? Mark the product physical and choose the countries you ship to; the checkout then collects a shipping address, and only from buyers you can actually serve. Digital and physical items are bought in separate checkouts, which sounds like a limitation and is really a favour — one order, one fulfilment path, no half-shipped baskets.
How far it scales
Up to ten shops per account and fifty products per shop, which is a genuine small business rather than a demo: one shop for your clients, one for a side project, one for a collaboration, each with its own front. Underneath, every product is a payment link, so delivery, keys and custom fields work identically whether the buyer arrived through a storefront or a URL you pasted in a chat.
Invoicing a client in crypto#
Freelancers and agencies have a slightly different problem from sellers: the amount is negotiated, the buyer is a company, and somebody's accountant will look at this later. The mechanics are the same — a payment link is the invoice — but four details are worth getting right.
Quote in your currency, get paid in theirs
Put your normal number on the invoice: €2,400, $3,000, whatever you bill. The client pays in the asset they hold. If they are a company with a treasury, that is usually a stablecoin, and then the arithmetic is exact on both sides — 2,400 out of their USDT balance, 2,400 into yours, no conversion argument, no "which rate did you use" email.
Put the link where the number is
The payment link belongs on the invoice itself, next to the total, as a URL and a QR code. Invoicing software that lets you add a custom field or a payment-instructions block is enough; you do not need it to "support crypto". If you send PDFs, the QR is what gets scanned, because the person paying is often not the person who received the PDF.
Milestones instead of one big transfer
On-chain payments are final once confirmed — that is the property that removes chargebacks, and it cuts both ways. For a large engagement, do not put the whole amount behind one link. Split it: deposit, midpoint, delivery. Three links, three dates, and neither side is ever holding all the risk. This is ordinary professional practice; crypto just makes it explicit. The reasoning is spelled out in the guide on finality and refunds.
Give your accountant something boring
Every payment lands in a ledger with gross, fee and net per line, exportable as CSV, with the transaction hash beside it. Revenue recognised in your own currency, the fee as a separate expense line, the hash as a receipt no one can dispute. Your tax obligations do not change because the rails did — but the paperwork is arguably cleaner than a bank statement, because each line links to a public, permanent record.
The buyer that isn't a person#
One forward-looking reason to prefer a link over a bespoke checkout: an active payment link is also a machine-readable checkout. An AI agent shopping on someone's behalf can read the link's JSON, see the price, the accepted assets and exactly which fields it must supply, create an invoice, pay it and read the receipt back — with no API key and no account of its own. The same is true of a shop's catalogue.
Whether autonomous buyers become a meaningful share of your revenue is not something anyone can promise today. What is certain is that the cost of being reachable by one is zero if your product is already a link, and non-trivial if it is a bespoke form. If you would rather not be part of that, it switches off per account and the endpoints answer 403. The contract is documented on the agent-checkout page.
When to graduate to the API#
No-code has a real ceiling, and it is worth naming so you can tell whether you are near it. Move to the API when you need payments created programmatically from your own system — a SaaS billing cycle, a per-user amount computed at runtime, a marketplace splitting between sellers, a game crediting a balance the instant a payment confirms. The signal is not volume; it is whether the price or the delivery depends on data only your software has. Selling ten thousand copies of one thing is a link. Selling one thing whose price depends on a customer's usage last month is an integration.
When that day comes it is one endpoint to create a payment plus one signed webhook to receive settlement, and most developers ship it in an afternoon — the road is covered end to end in the main acceptance guide. Until then, the ceiling is higher than most people assume, and everything above costs the same as everything else here: 1% when you get paid, nothing when you don't.
