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 developer preview: the technical controls are in place; procedural certification is in progress. This page records the compliance commitments for the developer-preview 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.

Funds and card data

OID4Pay is not a stored-value wallet: it keeps no balance. Card details are held by the payment processor, not by OID4Pay. The service is a developer preview and runs in test mode, so no real money moves.

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.

Standards bodies

OID4AC is published here as version 1 of an open profile. It is not a specification of any standards body. Agent-payment standardisation is moving through the FIDO Alliance and EMVCo, and we follow that work and align the mandate format with it where we can.

Roadmap

Stage	Deliverable
Shipped	Audit chain technical controls
This preview	Public docs, security.txt, status page, test mode
Planned	SOC2 Type II report published