Eliopi will be a payment platform built on Stripe Connect. The posture documented below describes the architecture and controls we are putting in place ahead of launch, so a Stripe Risk reviewer or a security-aware merchant prospect can evaluate the platform on its merits. No production cardholder data flows through Eliopi today (the platform is pre-launch). At launch, cardholder card data (PAN, CVV) will be captured by Stripe Elements directly in the cardholder's browser and tokenised by Stripe. Eliopi infrastructure will never receive or persist full cardholder card data. Our PCI DSS scope will be SAQ-A — the lowest-scope merchant category for fully outsourced card capture.
Posture · Security
Security & compliance.
PCI DSS scope
SAQ-A — no PAN at rest, no CVV ever.
Capture mechanism
Stripe Elements (iframed card form, hosted by Stripe)
Card data path
Cardholder browser → Stripe tokenisation endpoint (TLS 1.2+) — Eliopi infrastructure not in path
What Eliopi receives
Stripe-issued payment-method token, brand, last4, BIN, country, 3DS authentication result
What Eliopi never receives
Full PAN · CVV · CVV2 / CVC · Track 1 / Track 2 data · cardholder authentication secrets · raw expiry as entered by the cardholder (Stripe-issued
exp_month / exp_year may be retained as PaymentMethod metadata)
PCI form
SAQ-A · self-assessment renewed annually
QSA validation
Not required for SAQ-A · we self-attest
Authentication & risk
3DS forced. Liability shift on every charge.
3D Secure
request_three_d_secure: 'any' on every PaymentIntent · challenge enforced where issuer supports it
Liability shift
Yes · authenticated 3DS shifts liability to issuer for fraud disputes (Visa 10.4 / MC 4837)
Stripe Radar
Enabled at the platform level · cascades to destination charges · custom rules per vertical
Velocity / BIN monitoring
Card-testing detection via Stripe Radar · platform-level allow / block lists
Strong Customer Authentication (PSD2)
Enforced for EEA cardholders
Infrastructure
Encryption in transit and at rest. Hardened by default.
Transport
TLS 1.2 minimum · TLS 1.3 preferred · HSTS · HTTP/2
Encryption at rest
AES-256 for stored personal data, audit logs, dispute evidence files
Secrets management
Cloud-provider KMS · no plaintext secrets in source · per-environment isolation
Edge protection
Cloudflare WAF · DDoS mitigation · bot detection · rate limiting
Hosting
AWS (us-east, eu-west) · Vercel · Railway — see sub-processors
Backup & recovery
Encrypted daily snapshots · 30-day rolling retention · documented restore drills
Access & identity
Least privilege. Audited.
Authentication (employees)
SSO with mandatory MFA · hardware-key required for production access
Authorisation
Role-based access · least privilege · production access on documented break-glass
Audit logging
Immutable logs of administrative actions and data access · 13-month retention
Authentication (customers)
Email / password with bcrypt · MFA opt-in · forthcoming SSO for Scale plan
API keys
Live / test separation · rotatable · scoped permissions on roadmap
Audits & attestations
In progress, not yet attested.
We do not display logos or badges for audits we have not completed. Below is the truthful state today.
SOC 2 Type II
Auditor selected · readiness assessment underway · target attestation Q1 2027
PCI DSS
SAQ-A self-attestation in place · refreshed annually
ISO 27001
Not yet pursued · roadmap consideration after SOC 2
Penetration testing
External pen test scheduled before launch · summary letter available to enterprise customers under NDA
DPA / SCCs
Standard DPA with EU SCCs and UK Addendum · available on request to privacy@eliopi.com
Sub-processors
Named, scoped, auditable.
Full list with purpose, jurisdiction, and data scope: /sub-processors.
Vulnerability disclosure
Reach us at security@eliopi.com.
If you believe you have found a security vulnerability in the Eliopi platform, please email security@eliopi.com with the subject line [security]. Provide reproduction steps, impact, and any artifacts that help us triage. PGP key available on request.
What we ask of you
- Give us reasonable time to investigate and fix before public disclosure (we target 30 days for triage and fix on critical issues, 90 days max).
- Do not exfiltrate live customer data or perform service-degrading actions (DoS, social engineering of staff, physical attacks).
- Do not retain personal data; if you encounter it during research, stop and notify us.
- Comply with applicable law in the jurisdictions you operate in.
What we offer in return
- Acknowledgement within 2 business days.
- Triage update within 7 business days.
- Public credit (if you wish) once the issue is fixed.
- For high-impact reports we offer ex-gratia bounties; we do not run a formal public programme yet but treat researchers fairly.
- Safe-harbour from legal action when you act in good faith and follow this policy.
Incident response
If something goes wrong, our process.
We maintain a documented incident response plan (IRP). Key elements:
- 24/7 on-call rotation for production incidents.
- Severity matrix with response-time targets per severity.
- Notification policy: customers materially affected by a security incident are notified within 72 hours of confirmation, including a description of the impact, our remediation, and recommended action.
- Regulator notifications: GDPR Art. 33 data-breach reporting within 72 hours where applicable; cooperation with Stripe Risk per the Stripe Connected Account Agreement.
- Post-mortems: blameless, written, and shared with affected customers within 14 days of resolution.