mc_geo, mc_currency) — those stay on so prices display correctly. Analytics + marketing cookies are off until you accept. See the privacy policy for the full list. A plain-English summary of how we protect merchant + end-customer data. Where claims need external validation (SOC 2, ISO 27001, PCI), we say where we actually are — not where we'd like to be.
Last updated · May 2026
Mercentia is built as a multi-tenant SaaS. Every merchant's data is isolated at the database layer, encrypted in transit and at rest, and accessed only through the gateway's authenticated API. We never see cardholder data — the payment processor handles that.
This page is the current operational reality. The compliance roadmap at the bottom describes the external attestations in progress.
Every table containing merchant data carries an org_id column, and PostgreSQL row-level security policies enforce that the current request can only read or write rows where org_id matches the authenticated organisation. The policy is set per-transaction by the gateway middleware — there is no application code path that can bypass it.
Cross-tenant aggregations (peer benchmarks, network insights) require explicit opt-in via the stores.analytics_opt_in flag, are k-anonymised with a minimum cohort size of 5, and never expose individual-store identifiers.
Mercentia never touches card data. We use hosted payment elements from Stripe (global), Razorpay (India), and Paystack (West Africa). The merchant's customer enters card details directly into the processor's iframe; we receive a tokenised reference (e.g. pm_*) that lets us charge / refund / authenticate without ever seeing the PAN, CVV, or expiry.
That puts Mercentia in PCI DSS Self-Assessment Questionnaire A scope — the lightest tier, for merchants who fully outsource cardholder data handling. We complete SAQ A annually. Merchants on Mercentia inherit this scope: by using our hosted checkout you stay in SAQ A scope too.
Every state-changing API call writes a row to the staff_audit_log table: who did it, when, from which IP, what changed, and (for risky operations) the explicit confirmation token. The log is append-only, retained for 7 years, and searchable from the dashboard.
GDPR data-subject requests (export, erase, consent updates) are recorded the same way and mapped to the relevant GDPR article in the metadata — Article 17, 20, 15, 7.
Detection: synthetic checkout monitoring every 60 seconds, error-rate alerting on the gateway, anomaly detection on auth + payment endpoints.
Response: on-call engineer paged for any severity-1; incident commander + comms lead assigned for severity-1 and -2. Affected merchants notified within 72 hours for any incident involving personal data (GDPR Article 33). Post-mortem published within 14 days on the status page.
| Framework | Status | ETA |
|---|---|---|
| GDPR / CCPA / CPRA | Aligned — DSAR endpoints, audit log, consent ledger, sub-processor list, DPA available | Now |
| PCI DSS SAQ A | In scope — Stripe / Razorpay / Paystack hosted elements only | Annual self-assessment |
| SOC 2 Type I | In progress — control framework documented, gap remediation in flight | Q3 2026 |
| SOC 2 Type II | Planned — observation window opens after Type I attestation | Q2 2027 |
| ISO 27001 | Planned — initiated after SOC 2 Type II | 2027–2028 |
We will not claim a SOC 2 / ISO 27001 attestation until we have the signed report. Enterprise prospects under an NDA can request the in-flight gap-remediation document at [email protected].
We run a coordinated-disclosure programme. Email [email protected] with reproduction steps. We acknowledge within 48 hours, triage within 5 business days, and fix high-severity issues within 14 days. Researchers who responsibly disclose get credited on this page with permission.