Privacy-respecting ecommerceCopy wiki link

A privacy shop cannot promise that buying and shipping a physical product creates no records. Payment providers, banks, carriers, bookkeeping rules, consumer rights, and fraud controls create legitimate data flows.

The honest goal is a store with minimized linkage: collect only what the transaction requires, do not reuse order data to profile people, separate providers’ views, and delete operational detail when its purpose ends. This applies Privacy product architecture to ordinary retail.

Recommended first stackCopy wiki link

A practical first implementation is:

• a self-hosted WooCommerce store on a reputable EU host
• a small, maintained theme with local system fonts
• guest checkout enabled by default
• no customer account required for an ordinary purchase
• no Google Analytics, Meta Pixel, session replay, ad retargeting, third-party review widgets, or social-media embeds
• necessary cart and security cookies only
• Swish Handel and a hosted or redirected card payment option
• a Swedish shipping aggregator or direct carrier integration that receives only fulfillment data
• a separate support mailbox or ticket system using the order number as the initial reference

WooCommerce is not private merely because it is self-hosted. Its plugins, theme, host, payment gateway, email provider, shipping extension, and administrator practices determine the real boundary. Prefer a short dependency list over a feature-rich marketplace build.

Storefront without surveillanceCopy wiki link

Use server-side sales totals and stock data instead of person-level marketing analytics. If audience measurement becomes necessary, run a separately assessed, aggregate system without cross-site identifiers and do not load it before any required consent.

PTS states that nonessential cookies generally require prior, active, and revocable consent. Necessary cookies for a requested cart function can be exempt. The cleanest privacy interface is therefore often no banner at all because the site has nothing nonessential to ask permission for.

Do not fingerprint visitors, build advertising audiences, or attach browsing history to an order. Campaign performance can be measured with coarse landing-page codes and aggregate order counts.

Checkout dataCopy wiki link

Ask for:

• product and quantity
• delivery method and the address or pickup data that method requires
• an email address for the contract, receipt, delivery status, and rights communication
• a phone number only when the selected carrier or payment method requires it
• payment choice

Do not require:

• birth date or personal identity number for an ordinary product purchase
• an account and reusable password
• gender
• social login
• a marketing opt-in
• a reason for buying privacy equipment
• a global customer profile assembled across browsing, support, payment, and delivery systems

Offer parcel pickup or another lower-disclosure delivery option when the carrier and product permit it. Do not describe a pickup point as anonymous: the carrier may still require identification and the payment provider still processes a payer record.

Separate physical and digital checkoutCopy wiki link

A digital voucher does not need to inherit the fields required to ship a physical product. Use two checkout schemas under one brand:

• physical orders collect fulfillment and contract contact data
• eligible digital vouchers use a random order secret and optional notification contact
• a mixed basket follows the higher-data physical flow
• neither lane requires a reusable global customer account
• the two lanes are not joined into a marketing or behavior profile

Privacy voucher shop defines the code, Tor, Monero, tax, and consumer-law boundary.

Separate the viewsCopy wiki link

Use a random order identifier across systems. The storefront needs the order and contact route. The payment provider needs what is required to authorize and settle. The carrier needs delivery data. The supplier should not receive the customer’s identity unless direct fulfillment is explicitly necessary.

Avoid third-country dropshipping. It gives an opaque supplier the delivery address, weakens control over product safety and delivery, and still leaves the Swedish seller responsible to the customer.

Staff access should also be separated: fulfillment does not need payment instrumentation, support does not need complete payment records, and marketing does not need named order history.

PaymentsCopy wiki link

Offer at least one familiar Swedish method and one card method so the store is commercially usable.

Swish Handel integrates with a web checkout and signs the payment through BankID. It is convenient and relatively direct, but it is identified banking infrastructure, not an anonymous payment method.

Use a hosted or redirected card flow so the shop does not handle raw card numbers. Compare processors by:

• data fields and fraud signals shared with the shop
• subprocessor and transfer locations
• retention and deletion terms
• support for refunds and the statutory withdrawal flow
• plugin quality and update history
• exportability and termination procedure

Manual bank transfer can be a low-complexity fallback for B2B orders. Cash by mail creates theft, proof, refund, accounting, and customer-support problems. It should not be an early feature unless counsel and the bank approve a precise process.

RetentionCopy wiki link

Create a purpose-and-retention table before launch. Differentiate:

• abandoned carts and failed orders
• fulfilled order operations
• warranty and complaint records
• accounting records required by law
• payment-provider records
• carrier records
• support conversations
• marketing consent

WooCommerce can set retention periods and anonymize completed order data, but the configuration must respect legal retention duties. Where a statutory record must remain, restrict its use and access rather than pretending that GDPR requires immediate deletion.

Delete abandoned and failed checkout data quickly. Do not use completed orders for unrelated profiling. Keep marketing consent separate from the purchase and make withdrawal simple.

Security baselineCopy wiki link

• use hardware-backed MFA for every administrator
• give each staff member an individual account
• use least privilege and remove access promptly
• patch the operating system, WordPress, WooCommerce, theme, and plugins on a defined schedule
• test updates on staging without copying live customer data unnecessarily
• keep encrypted backups with a tested restore procedure
• protect the administrator interface with rate limits and network controls
• scan dependencies and remove unused plugins
• log privileged actions and security events, not every customer interaction forever
• maintain an incident and personal-data-breach procedure
• test checkout, refund, withdrawal, export, and deletion flows before launch

The privacy claim should be an auditable operating description, not a seal or slogan.

Customer-facing transparencyCopy wiki link

Publish a short data map that names:

• what the shop receives
• what the payment provider receives
• what the carrier receives
• why each field is needed
• the ordinary retention period
• how a person requests access, correction, deletion, or objection
• what cannot yet be deleted because of a legal duty

Also publish a lawful-request policy that promises review and lawful handling, not immunity from Swedish or EU law. Privacy trust and governance provides the wider posture.

Launch checklistCopy wiki link

1. Map checkout, payment, email, shipping, support, and accounting data.
2. Sign processor agreements and review international transfers.
3. Disable nonessential analytics and marketing integrations.
4. Enable guest checkout and remove unnecessary fields.
5. Set documented retention timers.
6. Publish privacy, cookie, purchase, delivery, withdrawal, complaint, and recall information.
7. Implement the website withdrawal function required for covered distance contracts.
8. Run a test purchase through refund, withdrawal, deletion, and accounting export.
9. Run a security review and rehearse restore and incident response.
10. Recheck the data map whenever a plugin or provider changes.

If digital vouchers are added, repeat the checklist for the separate voucher checkout and test order-secret recovery without email.

Swedish ecommerce compliance guidance records the main legal sources.