The safest buyer data is the data we never store

The strongest protection for buyer personal data is not storing it.

• Marketplace orders are mirrored without buyer identity · order numbers, line items and amounts only.
• The buyer's name and address are fetched from the marketplace at the moment of fulfilment, used in memory to produce the shipping label, and discarded.
• There is no buyer-PII table to breach, export or leak · in the database, in logs, or in backups.
• Invoices follow the same model · your identity, the lines and a PDF fingerprint are kept · buyer details are merged live on re-download.

• Vercel (application) · Supabase (PostgreSQL and authentication · ISO 27001 and SOC 2 Type II certified) · Railway (background workers) · all SOC 2 certified providers, audited annually.
• The database is never publicly reachable · access flows through the platform's API layer only · service keys are restricted to backend workers.
• No self-managed servers, file stores or desktop endpoints hold customer data.

• All traffic encrypted in transit with TLS · data at rest encrypted with AES-256 by the database provider.
• Marketplace and carrier API credentials get an extra application-level layer · sealed with libsodium public-key encryption (X25519 / XSalsa20-Poly1305). The web application can only encrypt · decryption keys exist solely in the backend worker environment's managed secret store.
• No secrets live in source code or repositories.

• Every merchant's data is isolated with database-enforced row-level security · isolation is a property of the database itself, not just the application code.
• Role-based access with per-module permissions · staff see only what their job requires · order-fulfilment roles are the only ones that can trigger the transient buyer-data fetch · permission changes reach the employee's screen in moments.
• Individual named accounts only · no shared logins · multi-factor authentication · centrally revocable sessions with trusted-device controls · every new workspace is reviewed by MARGIXA before it goes live.

• Application-level audit trails cover staff actions, inventory movements, pricing pushes and channel events · tied to the individual account · every scan, grade, move and ship carries the person and the time.
• Automated health monitoring alerts on worker outages, failed jobs and provider errors · structured logs across all services · Supabase security advisors run against every schema change.
• Logs are reviewed on a scheduled cadence · security events escalate to a named incident contact.

• Strict static type-checking and code review before every release.
• Continuous dependency scanning · critical advisories are patched and deployed immediately.
• Changes are exercised in dedicated test environments (test tenants, sandbox marketplace accounts, preview deployments) with synthetic data only · production buyer data is never used in testing.

• A documented incident-response plan with defined roles, reviewed every six months.
• Detect and triage · contain (revoke credentials, isolate the service, rotate keys) · assess scope · notify affected parties and marketplaces within their required windows (including Amazon within 24 hours where Amazon data is involved) and authorities per GDPR timelines · recover · close with a post-incident review.

• Every control on this page ships to every merchant on every plan · security is not a tier.
• Built to pass marketplace partner requirements, the Shopify App Store review and Amazon-grade security questionnaires.