Concepts

Compliance posture

OID4Pay's compliance story has two pillars: SOC2 Type II (operational controls) and eIDAS qualified-trust posture (audit-chain integrity). Each lands on a distinct milestone. This page documents what ships when.

Status in the public beta: the technical controls are in place; procedural certification is in progress. This page records the compliance commitments for the public-beta window.

SOC2 Type II

Control area	What is shipped now	What lands with the Type II report
Security (CC6)	Algorithm whitelist enforced at every JWS/JWT verifier; DPoP sender constraint; `alg=none` rejected; key rotation runbook on a 90-day cadence.	Type II evidence collection across the entire trust-service-criteria set.
Availability (A1)	Multi-host fleet with WireGuard mesh; Cloudflare TLS; primary Postgres + warm standby; SLO targets on the status page.	Cross-region failover drill recorded quarterly; observed availability published monthly.
Confidentiality (C1)	Secrets in SOPS only; per-service Postgres roles; PgBouncer pool isolation; no PII in logs.	Annual confidentiality penetration test scoped to AS, Wallet, and merchant SDKs.
Processing integrity (PI1)	The audit chain; per-tenant sequence numbers; prev-hash chaining; hourly chain-head signing.	Auditor-reproducible chain verification with the published JWKS.
Privacy (P)	Minimum disclosure in SD-JWT VC mandates; selective disclosure on presentation; GDPR data subject rights at `wallet.oid4pay.com/privacy`.	Annual DPIA refresh; data subject access automation end-to-end.

eIDAS qualified-trust posture

The OID4Pay audit chain is designed to align with Regulation (EU) No 910/2014 Annex IV requirements for qualified trust services regarding the trustworthy lifecycle of audit data. Specifically:

Collection: every SSF event is sequenced and prev-hash chained at the moment of recording (see the audit chain).
Signing: the chain head is signed every hour with a dedicated Ed25519 key whose JWKS is published at the AS.
Retention: per-class retention is enforced at archive time. retention_class=eidas-10y entries land in WORM storage with S3 Object Lock for 10 years.
Retrieval: the per-tenant audit log API lets a merchant pull their own slice for their own auditor.
Verification: the chain is auditor-reproducible from the published JWKS plus the exported WORM data.

The technical controls have shipped; the procedural controls required for qualified status are in progress.

Settlement and fund custody

OID4Pay merchants settle through their own Stripe Connect accounts. OID4Pay does not hold customer funds and is not a payment institution: Stripe is the payment processor, and money settles to each merchant's own account.

GDPR / AVG / UAVG

OID4Pay is a Dutch-domiciled service. Data subject rights are exposed via the Wallet Portal at wallet.oid4pay.com/privacy. The data controller is OID4Pay; the data processor for the Stripe Connect rail is Stripe Payments Europe (Ireland). The standard GDPR data processing addendum is signed with every merchant at onboarding; see support for the request channel.

OpenID Foundation Implementer's Draft

On the roadmap, OID4Pay submits the OID4AC specification to the OpenID Foundation as an Implementer's Draft. The IPR contribution agreement and the OIDF working group acceptance correspondence are the artefacts that confirm it. Once accepted, OID4AC becomes an OIDF-track spec and OID4Pay becomes the reference implementer.

Roadmap

Stage	Deliverable
Shipped	Audit chain technical controls
This beta	Public docs, security.txt, status page, sandbox AS
Planned	OIDF Implementer's Draft submission
Planned	SOC2 Type II report published