Payment Security

PCI DSS 4.0.1 is the mandatory security standard for any company that stores, processes or transmits cardholder data. Berghem defines the scope and cardholder data environment (CDE), runs the gap assessment, supports remediation and delivers the penetration test required by Requirement 11.4 — the evidence a QSA needs to sign off.

Our offensive work validates network segmentation, tests applications and APIs inside the CDE and confirms controls resist real attacks, not just checklists. See our PCI DSS consulting and the compliance and audit pillar for the full certification cycle.

The standard organizes controls around a secure network, cardholder data protection, vulnerability management, access control, continuous monitoring and security policy. The merchant level and SAQ type set the depth of validation — from self-assessment to a Report on Compliance (RoC) signed by a QSA.

PCI MPoC (Mobile Payments on COTS) is the standard that turns an ordinary smartphone into a payment terminal, reading the card by contactless and, where applicable, entering the PIN on the screen. It consolidates and replaces the earlier SPoC and CPoC standards, broadening software assessment and continuous attestation.

Berghem assesses MPoC solutions from the attacker's view — app resilience, PIN protection, device and channel integrity — aligned to the standard's software security and attestation requirements. Details on the dedicated PCI MPoC page.

The EMV ecosystem — chip cards, contactless transactions, ATMs and point-of-sale (POS) terminals — remains central to card-present fraud. We assess the transaction flow, track and PIN cryptography, physical and logical terminal protection, and resistance to relay, skimming and message-tampering attacks.

For acquirers, payment facilitators and terminal makers, we combine firmware analysis, embedded application testing and EMV flow review, producing evidence that supports security and compliance decisions across the acceptance chain.

On ATMs we assess jackpotting, black-box attacks and dispenser manipulation; on POS, terminal and capture-software integrity. The goal is to demonstrate real impact — cloning, transaction diversion or cardholder-data extraction — before a fraudster does it in production.

Instant payments and open-banking data sharing widened the attack surface of financial institutions. We test payment-initiation APIs, the consent flow and anti-fraud controls, hunting for authorization flaws, business-logic abuse and exposure of sensitive data.

This work connects to open finance security and to adequacy with the BACEN/CMN resolutions on cybersecurity, including 4.893. For the full sector view, see security for banks and fintechs.

We also review certificates and mTLS between participants, dynamic client registration and consent scopes, making sure an institution neither exposes data beyond what the account holder authorized nor accepts requests forged by a malicious ecosystem participant.

Our work follows recognized methodologies — OWASP, PTES and NIST SP 800-115 — adapted to the payment context. We combine black-box, gray-box and white-box testing depending on the target, always focused on business impact: fraud, value diversion and cardholder-data leaks.

For the full offensive program, see the EHT — Ethical Hacking Team and our offensive security, which extend payment testing to the institution's applications, APIs, internal networks and cloud.