PCI notice

This notice summarises how Pokopay handles cardholder data (CHD) and describes our PCI DSS posture. It is a plain-English complement to our full security documentation, which we're happy to share with prospective partners and buyers under NDA. For personal data more broadly see the Privacy Policy; for the terms that govern use of the platform see the Terms of Service.

Scope

In our PCI DSS scope:

• The POS Terminals themselves — PCI PTS approved PIN entry devices.
• The network path from the Terminal to the acquirer, including any Pokopay-operated hop.
• The backend HSM(s) and the key management ceremonies around them.
• The services that receive, route or authorise Transaction messages.

Out of scope, by design:

• The Pokopay dashboard (this web console) — it never accepts PAN, PIN, CVV or track data, and displays PAN masked to last four digits.
• The marketing website at pokopayng.com — static, no CHD, no payment forms.
• Internal corporate systems that don't touch CHD (HR, general email, marketing tools).

Roles

• Merchant — the business accepting the payment. The Merchant is the "merchant" in scheme parlance and remains responsible for its own PCI obligations at the point of acceptance.
• Pokopay — the service provider. We provide the Terminal fleet, the software and the routing layer; we act on the Merchant's behalf under scheme rules.
• Acquirer — the licensed institution that holds the Merchant's MID and settles funds. The acquirer is where scheme liability lands.
• Processor — the entity that authorises and clears Transactions on behalf of the acquirer.
• Scheme — Visa, Mastercard, Verve and other card networks whose rules govern authorisation, clearing, disputes and PCI compliance.

Where CHD lives

Cardholder data is captured on the POS Terminal, encrypted at the point of capture, and transmitted to our processing partners. The Pokopay dashboard does not accept card numbers, PINs, CVVs or track data. Any PAN rendered to an operator is masked to the last four digits.

Cryptographic keys

Cryptographic key material (working keys, PIN keys, session keys) is never entered into or displayed in the web console. Key operations happen inside our backend HSM path. Terminal key rotation is orchestrated via encrypted (wrapped) components; the Keys tab in the console shows KCVs only.

PIN entry devices

Every Terminal deployed to a Merchant is a PIN entry device (PED) approved under the PCI PIN Transaction Security (PTS) programme. We track model, firmware and PTS approval status for every Terminal in the fleet and refuse to provision devices whose approval has lapsed or been revoked.

Access controls

• Role-scoped access: SUPER_ADMIN, ADMIN, CSA, OWNER, MANAGER, CASHIER.
• Tenant isolation enforced at every read and write.
• Absolute session cap, idle timeout and cross-tab logout broadcast.
• Audit trail on every admin action (approve, suspend, terminate, key rotate, staff invite, etc).

Transport

HTTPS everywhere with HSTS (1 year, includeSubDomains,preload). Content-Security-Policy, X-Frame-Options: DENY,nosniff, strict-origin Referrer-Policy and a restrictive Permissions-Policy at the edge.

SAQ approach

Because we operate a shared PCI environment on behalf of Merchants and Partners, we are working towards validated Service Provider Level 2 status with a full PCI DSS Report on Compliance and the SAQ D-SP self-assessment as the working framework. This is a live workstream, not a finished certification, and the framing is deliberately aspirational until the QSA signs the Attestation of Compliance.

Reporting

Suspected security issues — security@pokopayng.com.

Status

Formal PCI DSS certification is in progress. This notice is intentionally transparent about the posture we've designed the platform to meet, in advance of the paperwork.

This is a public summary. The formal Attestation of Compliance and our supporting evidence are available under NDA.