Skip to main content

Legal · Security

Security

Version 5.1 Effective April 1, 2026 Attestation cycle Annual

Plain-English summary

PayMullet is certified as a PCI DSS Level 1 Service Provider — the highest tier in the card-industry's security standard — and undergoes an annual on-site audit by a Qualified Security Assessor (QSA). Card data is encrypted at the point of capture using a PCI-listed P2PE solution, tokenized in an HSM-backed vault, and never touches application servers in cleartext. We also maintain SOC 2 Type II (Security, Availability, Confidentiality), run continuous penetration testing, and operate a public bug bounty program. This page describes those controls in auditable detail.

Certifications and attestations

PCI DSS Level 1 Service Provider
Assessed annually under PCI DSS v4.0.1. Attestation of Compliance (AoC) available to merchants and partners under NDA via security@paymullet.com. Listed on the Visa Global Registry of Service Providers.
PCI P2PE v3.1
Our terminal-to-vault path uses a PCI-listed P2PE solution. This is what lets P2PE-HW merchants use SAQ P2PE with dramatically reduced scope.
SOC 2 Type II
AICPA Trust Services Criteria for Security, Availability, and Confidentiality. 12-month observation period, audited by a Big-Four firm. Report available under NDA.
SOC 1 Type II
For financial-reporting controls relevant to merchant auditors. Scope includes settlement calculation, fee accuracy, and reserve balance reporting.
NACHA Third-Party Sender rules
Annual rules compliance audit and risk assessment per Nacha Operating Rules §2.17.
Network attestations
Visa AIS, Mastercard SDP, American Express DSOP, Discover DISC — all current.
How to request reports: Enterprise customers can request our AoC, SOC 2 Type II, and penetration test letter through the Dashboard (Settings → Compliance → Reports) or by emailing security@paymullet.com. An MNDA must be on file.

Card data handling (the short version)

  1. Capture: PAN is encrypted at the read head of a PCI-P2PE terminal (TR-31 key-wrapped) or entered into a PayMullet-hosted field (iframe) served from checkout.paymullet.com.
  2. In transit: TLS 1.3 with modern ciphers only (TLS 1.2 permitted for legacy EMV terminals; TLS 1.0/1.1 and SSL forbidden).
  3. Decrypt zone: Decryption happens exclusively inside an HSM-bounded decryption enclave that never exposes plaintext PAN to application code.
  4. Tokenize: PAN is replaced with a PayMullet token or a network token (Visa VTS / Mastercard MDES / Amex Token Service).
  5. Store: Only the token lives in application databases. The PAN-to-token map is stored in a separate, segmented vault with its own key hierarchy.
  6. Return path: No API ever returns a full PAN to a merchant. Last 4, BIN, and brand are the maximum disclosure.

Cryptography

  • In transit: TLS 1.3 (preferred), TLS 1.2 with AEAD ciphers (AES-GCM, ChaCha20-Poly1305) for legacy clients. HSTS preload on all public hostnames.
  • At rest: AES-256-GCM for application data. Envelope encryption with per-tenant data keys wrapped by a master key in FIPS 140-2 Level 3 HSMs.
  • Key management: TR-31 for payment key exchange. Master keys are split (m-of-n) across geographically separated safes with documented dual-control ceremonies and recorded key custodians.
  • Key rotation: DEKs rotate quarterly or on compromise; KEKs rotate annually; TR-31 session keys rotate per DUKPT standard.
  • Quantum posture: We are tracking NIST PQC standards (ML-KEM, ML-DSA) and plan hybrid deployment across our TLS terminators in 2027.

Network and infrastructure

  • Cloud: Primary production in AWS across three regions (us-east-1, us-east-2, us-west-2), multi-AZ.
  • Segmentation: The Cardholder Data Environment (CDE) is a separate AWS account with its own VPC, private endpoints, and no peering to corporate or development networks. Data flowing between zones passes through inspection proxies with deny-by-default egress policies.
  • WAF / DDoS: Managed rulesets + custom rules against card-testing and credential-stuffing patterns. L7 rate limiting and shape-aware anti-automation on hosted checkout.
  • Secrets: AWS Secrets Manager / KMS with automatic rotation; no secret material in source control; CI scans every PR.

Application security

  • Threat modeling on every new service before design review sign-off
  • Mandatory two-reviewer code review with CODEOWNERS enforcement
  • SAST (Semgrep), SCA (Snyk + osv-scanner), secret scanning, IaC scanning in CI
  • Dependency pinning + reproducible builds; signed container images; Sigstore provenance
  • Runtime protection: eBPF-based syscall monitoring in CDE nodes
  • Bug bounty program on HackerOne — see Coordinated disclosure

Offensive testing

  • Penetration tests: Two external firms annually — one for the CDE (PCI-qualified), one for the broader product. Retest after remediation is included in scope.
  • Red team: Quarterly objective-based engagements across identity, infrastructure, and application layers.
  • Purple team: Monthly tabletop with detection-engineering team to tune SIEM rules.

Identity and access

  • Employee access: SSO via Okta, WebAuthn/FIDO2 MFA required for all staff, hardware keys mandatory for production access.
  • Just-in-time access: Production access is request-based with dual approval, time-bound (max 8 hours), and session-recorded.
  • Least privilege: Role-based access control with quarterly access reviews by engineering leadership and an independent internal auditor.
  • Merchant dashboard: MFA required (TOTP, WebAuthn, or push). SSO via SAML 2.0 on Enterprise. Session timeout configurable per org; 15 minutes default.

Logging and detection

  • Append-only SIEM with 13-month hot retention, 7-year cold retention for CDE logs (PCI 10.5.1)
  • Detections for: unusual PAN access patterns, token-to-PAN reverse queries, after-hours production changes, OFAC near-match alerts, impossible-travel logins, card-testing velocity spikes
  • 24/7 security operations with MDR partner; PayMullet-led triage for P1 and P2
  • Canary tokens seeded in non-production databases, test vaults, and documentation repositories

Incident response

Incidents are classified P1–P4 with pre-defined RTO and notification commitments:

Notification commitments:
  • Security incidents affecting CHD (P1): Card brands notified within 24 hours, Sponsor Bank within 4 hours, affected merchants within 72 hours, and regulators per applicable state breach-notice laws and GDPR Article 33 (within 72 hours).
  • Material availability incident (P1): Status page updated within 15 minutes; root-cause analysis published within 5 business days.
  • Fraud/ATO on a merchant account (P2): Merchant notified within 2 hours of confirmation.

Our IR playbook is reviewed semi-annually; tabletop exercises cover ransomware, insider threat, cloud-provider compromise, third-party breach, and lost-terminal scenarios.

Business continuity and disaster recovery

  • RTO: 1 hour for authorization path; 4 hours for Dashboard; 8 hours for reporting
  • RPO: 0 for transaction data (synchronous multi-AZ commits); 15 minutes for Dashboard state
  • Annual full failover exercise with documented results; quarterly component-level failovers
  • Encrypted, air-gapped backups stored in a separate cloud provider

Vendor and supply-chain security

  • Tiered vendor review based on data sensitivity. All CHD-adjacent vendors require PCI DSS AoC + SOC 2 Type II.
  • Annual re-assessment; security addendum + DPA in every contract
  • Vendors lose network access on termination within 24 hours; access is reviewed automatically every 90 days

Personnel security

  • Background checks at hire (criminal, credit where role-justified, education, employment), and re-checks every 3 years for privileged roles
  • Annual security awareness + targeted training for engineers (OWASP, payment-specific)
  • Quarterly phishing simulations with just-in-time coaching
  • Access revoked automatically at offboarding; last-day exit ritual tied to identity provider

Coordinated disclosure / bug bounty

We run a public program on HackerOne. Rewards range from $250 (Low) to $25,000 (Critical), with additional bounties for novel payment-specific findings (e.g., token lifecycle abuse, chargeback logic, BIN-based bypass, AVS/CVV confusion). Safe-harbor terms cover good-faith research.

Out of scope: Attacks against production card data using real PANs, denial-of-service, social engineering of employees, physical attacks on offices or datacenters. Use our sandbox environment and the test PANs in developer docs.

Physical security

All production systems run in audited cloud datacenters (AWS). Office access is badge-controlled with visitor logs, camera coverage on entries, and secure disposal bins for paper. HSM ceremonies occur in a dedicated secure room; key shares travel with two-person integrity controls.

Contact the Security team

Report security issues to security@paymullet.com (PGP key at /.well-known/security.txt). For urgent CDE-affecting issues, call the 24/7 hotline listed in the Dashboard.