Disclosure: I'm the founder of Cypher eSIM. This is a build log, not a pitch. The product is named because the article is about how it works.
We sell travel eSIMs and take payment only in crypto. The design constraint from day one was: collect nothing. No signup, no email, no card, no ID. It turns out that one constraint touches every layer, from how you deliver the product to how you count visitors. Here is what it looks like in practice, including the parts that broke.
What we store
Per order: an order id, the plan, the eSIM's ICCID once it is provisioned, payment status, timestamps, and a utm_source if you arrived with one. That is the whole customer record. There is no users table.
Support has no "look up the customer" step. If you write to us in Telegram, we ask for your order link. If you don't have it, we cannot find you. That is a feature you design around from the start, not a bug you patch later.
The link is the account
After payment, the order gets a page we call the eSIM passport. It shows status, remaining data, expiry, the QR code and a top-up button. That page is the only credential there is.
Consequences:
- No password reset, because there is no password. Lose the link, lose access. In the Telegram bot the link lands in your chat, so it is hard to lose. On the web we say it plainly: bookmark this.
- Sharing the link means sharing access. We say that too.
Paying without an account
Each order gets its own invoice and its own address; addresses are never reused. Bitcoin and Monero are watched on our own nodes. USDT is accepted on four networks (Tron, BNB Chain, Arbitrum, Solana), plus USDC, DAI, ETH, SOL and TON. An invoice has an expiry; after that the order is marked expired and stays that way.
Three things we learned the hard way:
- Most crypto checkouts die between "invoice shown" and "payment sent". A large share of started orders expire untouched: the person opened their wallet and never came back. This is the ceiling of crypto-only, and it is why the web funnel matters so much. Our website converts several times better than our Telegram bot, with the same prices and the same product.
- The wrong network is the expensive mistake. USDT sent on the wrong chain is gone, and nobody can refund it. Put the network name next to the amount, in the same size, and again next to the address. Not in a tooltip.
- Telegram Stars are not a payment method for this audience. Almost nobody who picked Stars finished the payment. We're removing them.
Provisioning the eSIM
When the payment confirms, the backend requests a profile from the carrier's API and gets back an ICCID and an activation string (LPA:1$...). The passport page renders it as a QR code and as copyable text, because iOS and Android both accept manual entry and some people install from a laptop screen.
Two decisions that saved a lot of support hours:
- "Install now, activate later" is true, and we say so. The profile can sit on the phone until you land.
- Top-ups add data to the same profile. No new QR, no reinstall. The top-up form asks only for the ICCID, which is printed on the passport page and visible in phone settings.
The "60 seconds" promise on the homepage is mostly chain confirmation plus the carrier call. On a slow chain it takes longer, and the invoice page says so instead of pretending.
Counting visitors without tracking them
There are no advertising tags, no cookies and no session recording.
Server-side, a visitor is a hash that rotates daily. We can count unique visitors per day and see which pages and referrers work. We cannot follow a person across days, and we never wanted to. Funnel steps (opened checkout, picked a plan, opened payment, paid) are named events on the same endpoint.
What you give up: cohorts, cross-device journeys, "users who did X and then Y last week". Retention we compute from the product itself: top-ups on the same eSIM, and repeat orders from the same Telegram chat. It turned out far higher than we expected, which we would not have believed without seeing it.
SEO on a single-page app
The store is a React SPA. Google does render JavaScript, but "eventually" and "sometimes" are not a strategy, so commercial routes are prerendered to static HTML.
The mistake: for months, 34 routes were served with the identical prerendered body, the homepage's, because the prerender list only covered blog posts. Google did the logical thing and ranked the homepage for every money keyword while the actual landing pages sat unindexed. The fix was boring. Every route in the sitemap gets its own prerender with its own title, description, canonical and hreflang for the four languages. Check it with curl, not with a browser: a browser will happily show you the JavaScript-rendered version and hide the problem.
Would I build it this way again
Yes. No accounts removes an entire category of work: no password resets, no account takeovers, no "delete my data" requests, because there is no data. What it demands instead is unusually careful copy at every failure point, because you cannot email anyone afterwards. The error state is the support ticket.
If you're building something similar and want to compare notes on crypto invoicing or eSIM provisioning, I'm in the comments.
