Security is the product.

Merchants hand Paybyrd two things that are hard to recover once damaged: their money in flight, and their customers' card data. Our promise is that both are treated with more care than our own. We run the company under the supervision of financial-services regulators, we hold PCI DSS Level 1 — the highest merchant/service-provider tier in the payment-card industry — and we treat cardholder data as radioactive: it is touched by as few systems, as few people and for as few reasons as the service permits.

This page covers the entire production estate of Paybyrd's payment services: the public APIs, the merchant dashboard, the POS fleet and the backing platform on which authorisations, captures, refunds and webhook delivery run. Corporate IT and internal tooling are governed by equivalent policies but are out of scope for this document.

The commitments that follow are written to be verifiable. Every claim on this page is something we are prepared to evidence in a security questionnaire, a regulator audit or a scheme examination.

Paybyrd aligns its security programme to the frameworks that matter in payments, in the EU and in the jurisdictions we serve.

• PCI DSS Level 1 — certified. Annual Report on Compliance refreshed every 12 months by an independent Qualified Security Assessor; quarterly ASV scans against our public ingress; attestation available to merchants under NDA.
• ISO/IEC 27001 — information-security management system maintained across the platform; independent certification in progress.
• SOC 2 Type II — report in preparation, with a 12-month observation window commencing 2026; bridge letter available on request once the first report is issued.
• PSD2 — strong customer authentication. Authentication flows implement RTS-compliant SCA with exemption handling (TRA, low-value, MIT) and 3-D Secure 2.x for remote card transactions.
• GDPR / AVG. Full alignment with Regulation (EU) 2016/679 and the Dutch implementation; DPO appointed; records of processing activities maintained; breach-notification procedure aligned to articles 33 and 34 (see Privacy Policy).
• NIS2. Where the Directive applies to Paybyrd or to a group entity, we operate an aligned risk-management, supply-chain and incident-reporting regime.

We do not claim certifications we do not hold. Where a control or certification is in progress, we say so.

The platform is designed so that compromise of any single component does not compromise the cardholder data or the money-movement path.

• PAN tokenization on ingress. Primary Account Numbers are tokenized at the first system that sees them; downstream services hold and transmit tokens, not PAN. Detokenization is gated, audited and limited to the minimum set of processes that require it.
• Encryption in transit. TLS 1.2+ enforced on every public endpoint (TLS 1.0 and 1.1 disabled); HSTS with preload; modern cipher suites only; mTLS for sensitive service-to-service calls and for partner integrations that require it.
• Encryption at rest. AES-256 encryption for all production data stores, backups and snapshots; separate encryption domains for PCI-scoped data.
• Key management. Cryptographic keys are generated, stored and used within HSM-backed key-management infrastructure; key usage is logged; rotation runs on a published cadence with emergency re-keying procedures.
• Network segmentation. Production runs in isolated VPCs with private subnets, egress-only NAT and no inbound internet reachability for compute. The PCI DSS scope is a distinct environment with its own ingress, its own identities and its own change-control.
• Immutable audit logs. Security-relevant events — authentication, authorisation, configuration change, data access — are written to append-only storage with tamper-evident retention suitable for forensic review.

Who can touch production is as important as how production is built.

• Least privilege. Access is granted through role-based access control, provisioned from HR systems and reviewed against job function. Default is no access.
• Hardware-key MFA. Hardware security keys (WebAuthn / FIDO2) are mandatory for every production touchpoint — SSO, cloud console, bastion hosts, deployment pipelines, administrative tooling. Software one-time codes are not accepted for production.
• Quarterly access reviews. Every production entitlement is re-certified at least every 90 days by the owning manager; stale grants are revoked automatically at the end of the review window.
• Just-in-time elevation. For incident response and rare operational tasks, privileged access is obtained through time-bounded JIT grants with documented justification; standing admin rights are avoided wherever practicable.
• Session recording. Privileged shells are session-recorded and retained for forensic replay.
• Offboarding SLA. On termination or role change, production access is revoked within one hour of the triggering HR event, irrespective of business hours.

Attacks are detected by the controls that see them, not by hope.

• 24/7 SIEM correlation. Security telemetry from the platform, the cloud control plane, endpoints and identity providers is centralised and correlated in real time; detection rules cover known attacker techniques and are tuned against Paybyrd's own threat model.
• Anomaly detection. Authentication events, transaction flows and API-usage patterns are modelled for deviation; anomalous behaviour triggers automated containment and a human review.
• On-call and pager SLA. A security on-call rotation answers Sev-1 pages within 15 minutes, 24/7. Engineering, platform and fraud on-calls are paged in parallel for incidents that cross domains.
• SOC staffing. Monitoring is delivered by an internal security operations function supported by a vetted managed-detection partner for out-of-hours coverage; handover runbooks are rehearsed.

Finding problems early is cheaper than explaining them later.

• Third-party penetration tests. Independent pentests are commissioned at least quarterly, covering the public APIs, the merchant dashboard, the POS estate and the internal authenticated surface. Findings are tracked to closure with SLA-bounded remediation.
• Continuous SAST and DAST. Static analysis and dynamic application security testing run on every deploy; pipelines block merges that introduce critical findings.
• Software composition analysis. All dependencies are continuously scanned against authoritative CVE feeds; critical patches ship with a 7-day SLA from disclosure, shorter where active exploitation is observed.
• Bug bounty. Paybyrd operates a responsible-disclosure programme open to good-faith security researchers. Reports go to security@paybyrd.com.
• Safe harbour. Good-faith research within the scope of the programme is authorised and will not be subject to legal action by Paybyrd. Researchers who respect scope, avoid degradation of service and do not exfiltrate or disclose data beyond what is strictly necessary to evidence a finding are covered by this safe harbour.

Incidents are rehearsed, not improvised.

• Classification. Incidents are triaged into four severities — Sev-1 (payments systemically impacted, suspected data breach, regulatory exposure), Sev-2 (significant degradation without systemic impact), Sev-3 (localised impact or single-merchant/partner), Sev-4 (low-impact, workaround available).
• 72-hour breach notification. Where a personal-data breach meets the article 33 GDPR threshold, Paybyrd notifies the competent supervisory authority without undue delay and, where feasible, within 72 hours. Affected merchants are notified in parallel so that controllers can discharge their own obligations; where the breach is likely to result in a high risk to data subjects, article 34 notification follows without undue delay.
• Scheme and regulator reporting. Card-scheme operational-incident reports and financial-regulator notifications are filed on the timelines prescribed by the relevant rules.
• Monthly IR drills. The response team runs at least one tabletop or technical drill every month, covering a rotating set of scenarios (ransomware, key compromise, fraud wave, third-party outage).
• Public post-mortem. For every Sev-1 affecting merchants, Paybyrd publishes a post-incident review to the status page within a reasonable period, describing impact, root cause and remediation.

Data is handled on the principle that the safest record is the one we never collected, and the next safest is the one we have already destroyed.

• Residency. Production data for the payment platform is stored in the European Economic Area by default (primary region: eu-central-1, Frankfurt). Cross-border transfers occur only with appropriate article 46 safeguards and are documented in the Privacy Policy.
• Retention. Data is retained for the periods required by legal, regulatory and scheme obligations, as set out in the Privacy Policy. Retention is enforced by automation, not memory.
• Destruction. At end of retention, data is destroyed through cryptographic shredding — the encryption keys that protect the data are destroyed within the HSM, rendering the ciphertext unrecoverable — in addition to logical deletion from the data store.
• Environment separation. Live and sandbox environments are strictly separated: separate networks, separate identities, separate keys, separate datasets. Production data is not used in sandbox or development.

Payments cannot pause, and the platform is engineered to keep moving when components fail.

• Multi-AZ deployment. Core payment services run across multiple availability zones within a region; the loss of a single zone is expected and handled automatically.
• Automated failover. Database primaries, API gateways and message brokers are configured for automated failover with health-checked routing.
• RTO and RPO. For production payment services, the recovery-time objective is ≤ 4 hours and the recovery-point objective is ≤ 15 minutes for a regional-level event requiring activation of the disaster-recovery plan.
• Tabletop exercises. Business-continuity and disaster-recovery plans are exercised at least once per quarter, including at least one full-scope exercise per year that spans engineering, security, operations and customer-facing functions.