Privacy voucher shopCopy wiki link

A Swedish shop can plausibly resell fixed digital service vouchers without requiring an account, name, email address, or shipping address for every eligible order. It can potentially accept Monero directly for its own sales and expose the same storefront as an onion service.

That is a viable legal-design hypothesis, not a launch clearance. The exact reseller contracts, voucher tax treatment, consumer flow, crypto handling, sanctions controls, and data retention need written Swedish advice. Swedish privacy voucher compliance guidance records the legal sources.

The productCopy wiki link

Sell partner-issued, service-specific bearer codes for a fixed product or duration. The customer receives one code and redeems it directly with the partner.

The shop should not:

• issue a reusable cross-partner balance
• let customers deposit or withdraw value
• exchange one crypto-asset for another
• custody or transmit customer assets
• run an escrow or customer wallet
• create partner accounts on the customer’s behalf
• sell codes without an explicit reseller or voucher agreement

Those boundaries preserve the difference between selling inventory and providing payment, electronic-money, or crypto-asset services.

Low-data checkoutCopy wiki link

The default digital flow can be:

1. The buyer selects a country and one fixed voucher.
2. The shop displays the price in SEK or EUR and a time-limited Monero amount and address.
3. The browser receives a random order secret.
4. The shop confirms payment and displays the partner code behind that secret.
5. Email or another notification is optional.
6. The shop deletes operational linkage when refund, abuse, and support purposes end, while preserving legally required accounting records.

Country remains necessary for catalog eligibility, VAT, sanctions, and partner restrictions. An onion service cannot infer it reliably from an IP address, so the buyer must declare it and high-risk or restricted sales may require stronger evidence or refusal.

What the privacy claim can sayCopy wiki link

A defensible claim is:

No account or identifying information is required for eligible low-value digital voucher purchases.

It should immediately explain the limit. The merchant still learns the product, price, time, payment route, voucher serial or inventory batch, and any support contact. The partner sees the redeemed code and its own account and service activity. Timing, code inventory, compulsion, or collaboration can create correlation.

Do not claim:

• we do not know who you are
• anonymous payment
• untraceable VPN
• no records
• no link between purchase and use

The honest product is minimized necessary identity and reduced routine linkage. It is not mathematical unlinkability.

Tor storefrontCopy wiki link

An onion address can be an optional access path to the same Swedish company, terms, prices, support, and withdrawal function. It does not create a separate offshore business or remove Swedish and EU duties.

The onion version should have:

• a signed and prominently published onion address
• no third-party resources
• no analytics or visitor fingerprinting
• a small static catalog and hardened order API
• the same company and consumer information as the ordinary site
• an order-secret recovery flow that does not require email
• isolated administration that is never exposed as an onion service

No specific Swedish prohibition on offering an onion mirror was found in this research. That is an inference from the ordinary rules, not a formal legal opinion.

Monero boundaryCopy wiki link

Direct receipt into the merchant’s own wallet for its own voucher inventory is the narrowest planning model. The merchant should price the sale in fiat, record the fiat value and tax, and treat later conversion as its own treasury activity.

Refunds need a predetermined route that does not turn the shop into a transfer service. Volatility, wrong amounts, expired quotes, chain outages, and refunds all need operational rules.

Licensed European conversion partners may not support Monero, and regulated intermediaries can have identity and reporting duties. The shop must never imply that adding an intermediary preserves the direct-payment data boundary.

Partner orderCopy wiki link

The first partner target should be Mullvad. Its official reseller program already uses scratch-card vouchers designed so that neither Mullvad nor the reseller can directly connect the customer’s payment to the VPN account. Mullvad already lists Swedish and European resellers, so the pitch must add a distinct customer segment, privacy-preserving checkout, or physical kit rather than merely another storefront.

The next candidates should be European services with explicit code or reseller programs, especially storage, password management, encrypted mail, email aliases, and local encryption software. Swedish and EU privacy suppliers ranks the outreach.

Integration with the physical shopCopy wiki link

Use one brand but two data lanes:

• physical checkout asks for fulfillment data
• digital voucher checkout does not inherit shipping fields
• never require a global customer account
• never combine physical and digital orders into a person-level profile
• explain that a mixed basket takes the higher-data physical path

A physical kit can contain an unactivated voucher card. The seller may know that a kit was shipped, but should not receive the partner account or learn when and how the voucher is redeemed.

First experimentCopy wiki link

Before building custom payment infrastructure:

1. Obtain one written voucher or reseller agreement.
2. Ask Swedish tax counsel to classify that exact voucher.
3. Ask financial-regulatory counsel to review the direct Monero and refund flow.
4. Ask the bank, insurer, and accounting provider to accept the documented model.
5. Manually sell one fixed voucher through random order secrets.
6. Limit value, countries, and daily volume.
7. Test refunds, support, expired orders, sanctions refusal, and deletion.
8. Add the onion mirror only after the ordinary flow is stable.

The experiment succeeds when the partner relationship is repeatable, support stays bounded, the margin survives crypto and refund handling, and customers value the reduced linkage.