Comprehensive self-hosted data-protection guidance for payment, encryption, retention, and operational controls.

Data Protection Guide (Self-Hosted)

This guide provides a practical data-protection baseline for self-hosted deployments of the Payment Gateway.

It covers:

payment data boundaries (what is and is not stored),
encryption controls,
retention controls,
backup and recovery controls,
and operational responsibilities for your team.

1) Payment Data Boundary

For card-based payment flows, the gateway is designed to use provider-hosted or provider-tokenized collection components (for example, Stripe Elements).

This means:

the intended provider-hosted/tokenized card flows are designed so raw PAN and CVC values are not stored by gateway services,
the gateway stores transaction/business metadata and provider references,
provider credentials are stored encrypted at rest.

See Payment Data Boundary for provider-specific card-entry boundaries, transient token handling, and custom checkout extension responsibilities.

2) Data Categories Processed

The platform processes organization and operational data such as:

user and access data,
organization and site configuration,
transaction and invoicing data,
client and billing profile fields,
notification and provider integration secrets.

See Data Processing & Encryption for category and scope details.

4) Retention Controls

Under Settings > Retention (organization scope), configure:

transaction retention windows,
customer-data retention windows by field class (IP, addresses, email, items),
country retention behavior.

Document rationale for each value and align with jurisdiction/accounting rules.

For full tenant offboarding, use the global-admin organization offboarding workflow. It previews impacted collections, offers an optional redacted ZIP export, revokes access immediately, soft-deletes tenant configuration, and either schedules or immediately runs eligible cleanup. Offboarded organizations move to a dedicated Offboarding view with cleanup status and restore availability during the grace period. Statutory invoice, credit-note, numbering, and tax evidence is retained by default; anonymization and break-glass purge require explicit admin confirmation and legal review. Normal offboarding supports an optional audit reason; break-glass purge also requires a confirmation checkbox. Restore reactivates the organization/configuration and memberships captured in the run snapshot, but organization API keys remain revoked and must be rotated or recreated.

5) Backup and Recovery Controls

Data protection is not complete without verified recoverability:

configure scheduled MongoDB backups (mgob -> S3-compatible storage),
define how issued invoices, credit notes, PDFs, and e-invoice artifacts are archived outside the worker cache,
test restore procedures periodically and keep evidence.

Use Backup & Recovery (GDPR) as your runbook.

6) Access and Audit Controls

Recommended minimum controls:

least-privilege API keys and user roles,
key/API credential rotation and revocation process,
restricted infrastructure access paths,
centralized logs for admin and security-relevant operations.

7) Shared Responsibility (Self-Hosted)

The application provides technical capabilities, but as the operator you are responsible for:

infrastructure hardening,
secret management,
retention policy decisions,
backup storage policy,
legal/process controls (DPA, ROPA, DSR workflows, etc.).

[!IMPORTANT] This guide supports technical implementation for GDPR-oriented operations. It is not legal advice and does not by itself guarantee full compliance.

Trust Center
Dashboard Procurement Pack (signed-in operators only)
Configuration
Data Processing & Encryption
Payment Data Boundary
Backup & Recovery (GDPR)
Shared Responsibility Matrix
Retention Policy Playbook
Evidence & Audit Checklist

Data Protection Guide