Buy an eSIM With JavaScript Off

Try it first

Open pikasim.com/lite. Pick a country, pick a plan, pay in Bitcoin, Lightning or Monero, install. Every page on that path is plain HTML with one stylesheet. Right-click, View Source, and look for a script tag. There is none.

If you use Tor Browser: set the security level to Safest, visit pikasim.com, and click the ".onion available" button in the address bar. The onion service opens straight on the Lite catalog.

Why we built it

The people most likely to want a private eSIM are the people whose browsers break ordinary checkouts. Tor Browser at the Safest level disables JavaScript on every site. NoScript users block it by default and leave rather than allow it. People who have read about payment-page skimmers and canvas fingerprinting are right to be nervous about scripts on a page where they are about to pay.

A privacy store that stops working for exactly those people undercuts its own pitch. We sell eSIMs with no account, no email and no KYC. That promise should hold with scripts off too, and it did not. Our normal checkout loads the plan list with JavaScript, creates the invoice with JavaScript, and then sends you to a hosted payment page that needs JavaScript. With scripts off you saw an empty catalog and a dead button.

There was a second problem we only noticed while fixing the first. Visitors on our onion service who clicked Buy were redirected to the payment page on a regular clearnet hostname, in the middle of the purchase. That is the opposite of what someone on Tor expects. The Lite checkout removes that hop entirely: we render the payment address, amount and QR code ourselves, so the purchase never leaves the site you started on.

And there is a plain practical benefit. A page with no scripts and no third-party requests is a few kilobytes. It loads on hotel Wi-Fi and roaming data that is almost gone, which is exactly when people buy eSIMs.

How it works

1. Catalog. The plan list is rendered on the server from the same package data as the main site, with the same prices and the same rules about which plans are shown. Search is a plain form.
2. Buy. Each plan is an HTML form with a coin picker and a Buy button. Submitting it creates an invoice through the same code path as the scripted checkout. We did not fork the pricing or the invoice logic; the only thing that changed is that the browser posts a form instead of running a script.
3. Pay. The payment page shows the address as text, the exact amount, a QR code, a link that opens your wallet, and the time the rate is locked until. It reloads itself every 30 seconds using a meta refresh tag, which needs no script. While the payment confirms it shows what our node has seen, how many confirmations are needed, how long ago the payment was seen, and how long that coin usually takes.
4. Install. The same link becomes your installation page: one-tap install for iPhone and Android, the QR code, and the manual entry details. That link is your only receipt. There is no account and no email.

Support works the same way. A plain form opens a ticket and gives you a private link to the thread, with a reply box.

What we learned building it

Three things bit us, and each one is a reason most stores never bother.

• Monero addresses are lazy. Our payment server only generates a Monero address when a checkout page activates that method. A self-rendered page has to make that call itself, otherwise the address field is empty on first load.
• Every Tor visitor has the same IP address. Traffic from an onion service reaches the web server from the Tor daemon, so per-IP rate limits would have let ten visitors lock the whole mirror out of checkout. Those limits had to become per-mirror budgets.
• The last page counts. Our first version handed the finished order to the normal order page. It rendered fine with scripts off, but its source contained the site's usual scripts, which broke the "view the source" promise on the final step. The flow now ends on its own script-free page.

Images were the easy part. Tor Browser on Safest blocks some image types, so QR codes are rendered on the server as PNG data embedded in the page, not as a separate request.

What is not there, and why

• Card payments. The card processor's page needs JavaScript. Cards stay on the normal checkout.
• Some coins. Lite offers Bitcoin on-chain, Lightning and Monero. Coins that go through a swap partner need that partner's page. USDT will be added once its address pool is large enough to expose to a plain form, which is the cheapest spam tool on the internet.
• Phone-number plans and day passes. They need extra facts and a day-count picker that the Lite rows do not show yet. They are on the main site.
• Analytics. None. Lite orders are counted on the server from the order record, nothing else.

Refunds follow the same rules as everywhere else on the site. One honest limit: claiming a Bitcoin refund uses a page that needs JavaScript, so a scripts-off customer owed a refund enables scripts once for that page, or sends us an address through a ticket.

Verify it in sixty seconds

1. Open pikasim.com/lite and view the page source. Count the script tags.
2. Run curl -I https://pikasim.com/lite and read the Content-Security-Policy header.
3. Open the same page in Tor Browser on Safest, or in any browser with JavaScript disabled, and buy a plan.

If any of that stops being true, tell us. The build gate is there to make sure it does not, but a claim you can check beats a claim you have to trust.