Arrow Payments — P2PE Solutions Guide

Definition

What Is a P2PE Solution?

Core Definition

A Point-to-Point Encryption (P2PE) Solution is a combination of hardware, software, and processes that protect payment card data through encryption as it is passed between parties. P2PE solutions are designed to keep cardholder data unreadable until it reaches a secure decryption environment — the solution provider's Safe Harbor Platform — completely off the merchant's network.

Where P2PE Applies

Scope

In-person (card-present) transactions at a POI device
MOTO (Mail Order / Telephone Order) transactions
Does not apply to online (card-not-present / ecommerce) transactions

Validation Authority

PCI SSC

P2PE Solutions are validated by the PCI Security Standards Council (PCI SSC). Only PCI SSC-validated solutions appear on the official listing and qualify a merchant for PCI DSS scope reduction. A listing of all validated solutions is maintained at the PCI SSC website.

What a P2PE Solution Consists Of

Three Categories of Solution Elements

Category	Examples	Role
Components	Key Injection Facilities (KIFs), Certificate Authorities	Manage encryption key infrastructure and cryptographic trust
Applications	Payment Applications, P2PE Applications	Software running on or alongside the POI device handling encryption logic
Devices	Ingenico terminals, ID Tech readers	The physical POI hardware that captures and immediately encrypts card data

🔑

The Core Promise of P2PE

From the moment a card is presented at the POI device, cardholder data is encrypted and never exists in cleartext on the merchant's network. The merchant never sees the raw PAN — only an encrypted ciphertext and, eventually, a token they can store for future reference.

Transaction Flow

Card Present P2PE — End-to-End Data Flow

💳

Cardholder

Presents card

swipe / dip / tap

🔒
POI Device
Encrypts instantly

encrypted data

🌐

Gateway / EPS

Routes ciphertext

ciphertext

🏛️
Safe Harbor
Decrypts PAN

clear PAN

🏦

Issuing Bank

Approves / declines

approve / decline

🏪

Merchant

Gets token + result

Encryption at the POI Device

The Point of Interaction (POI) device incorporates physical tamper protections. The moment card data is captured — via swipe, dip, or tap — the device's P2PE software immediately encrypts it. The data never exists in cleartext on the merchant's hardware, software, or network. Even if the POS system or network is breached, the ciphertext is useless to an attacker.

Plaintext PAN → f45**8199*neuplak (ciphertext)

Encrypted Data Routed Through the Gateway

The encrypted ciphertext travels through the merchant's network and the payment gateway (EPS) to the solution provider's environment. At no point does the merchant's network handle cleartext cardholder data.

Decryption at the Safe Harbor Platform

The solution provider's Safe Harbor Platform — a secure, off-site decryption environment — decrypts the ciphertext back to the original PAN using keys that only the solution provider controls. The decrypted PAN can be re-encrypted to another format before being forwarded for authorization.

Authorization by the Issuing Bank

The clear PAN is sent from the Safe Harbor Platform to the issuing bank (via card networks and acquirer). The bank approves or declines the transaction based on the cardholder's account status.

Merchant Receives Notification + Token

The merchant receives an approve/decline notification. Along with it comes a token — a unique surrogate reference value that maps to the original transaction. The merchant stores the token (not the PAN) and can use it to process refunds, reference the transaction, or authorize future payments without ever needing the cardholder's actual card data.

Token: 1234 **** **** 5678

⚠️

The Critical Distinction: Encrypted Data vs. Tokenized Data

These are two different outputs. Encrypted data (ciphertext) travels from the POI device to the Safe Harbor Platform — it is the card data in scrambled form. Tokenized data is what comes back to the merchant — a surrogate reference value with no mathematical relationship to the PAN. Encryption protects data in transit; tokenization protects data at rest.

The Relationship Between P2PE and E2EE

P2PE Is a Subset of E2EE

Key Concept

Both P2PE and E2EE (End-to-End Encryption) encrypt payment card data. P2PE is a type of E2EE — specifically, E2EE solutions that have been reviewed and formally validated by the PCI Security Standards Council. Non-validated E2EE solutions are often called "E2EE" by vendors but are not P2PE in the PCI context.

All P2PE is E2EE | Not all E2EE is P2PE

Head-to-Head Comparison

Attribute	P2PE (PCI SSC Validated)	E2EE (Non-Validated)
PCI SSC Validation	Yes — formally reviewed and listed	No — vendor-claimed only
Encryption Point	At the POI device	At the POS / point of entry
Decryption Destination	Off-site at the solution provider's secure environment	Directly at the acquirer
Who Controls Keys	Solution provider — merchant never touches them	Merchant is responsible for the decryption key
PCI DSS Scope Reduction	Yes — SAQ P2PE (shorter, fewer controls)	No — still requires SAQ D or equivalent
Merchant Key Responsibility	None — fully offloaded to solution provider	Merchant must manage and protect decryption keys

⚠️

Scope Reduction Requires a Validated P2PE Solution

Per the PCI Council, PCI DSS scope reduction can only be achieved through the use of a PCI SSC validated P2PE Solution. A vendor claiming their product is "end-to-end encrypted" or even "P2PE-like" without formal validation does not qualify. Verify solutions against the PCI SSC listing before claiming scope reduction.

SAQ D vs SAQ P2PE — Why It Matters

Without P2PE — SAQ D

The most extensive SAQ type
Applies when cardholder data touches the merchant's environment
Covers all 12 PCI DSS requirement domains
Requires extensive documentation, network segmentation, log review, and more
Significantly more controls to implement and maintain

With Validated P2PE — SAQ P2PE

Significantly shorter and narrower in scope
Cardholder data never enters the merchant network — scope is dramatically reduced
Fewer controls required because encryption is the solution provider's responsibility
Merchant still responsible for physical device security and training
Lower compliance burden, lower risk

Solution Listing Structure

What the PCI SSC Listing Shows

Reference

Each entry on the PCI SSC validated P2PE Solutions list includes:

Company Name — the solution provider (e.g., Bluefin Payment Systems)
Solution Name — the specific validated product (e.g., Bluefin P2PE)
Reference Number — unique identifier (e.g., 2023-00897.035)
P2PE Standard Version — the version of the P2PE standard assessed against (e.g., P2PE v3.1)
P2PE Assessor Company — the QSA that validated the solution (e.g., Foregenix Ltd.)
Annual Revalidation Date — when the solution must be re-assessed to remain listed
Reassessment Date — deadline for the next full reassessment

📋

Annual Revalidation Is Not Optional

A solution must be revalidated annually to remain on the PCI SSC listing. If a solution's revalidation lapses, it is removed from the list and merchants using it can no longer claim scope reduction. Always verify a solution's current listing status before deployment.

Solution Components — What Gets Validated

Four Areas Covered in Solution Details

Component Area	Description
P2PE Components Supported	Key injection facilities (KIFs), certificate authorities, and other cryptographic infrastructure components included in the validated solution
P2PE Applications Supported	The specific payment and P2PE applications validated as part of the solution — merchants may only use these listed apps
POI Devices Supported	The exact hardware terminals approved for use within the solution — using an unlisted device invalidates the scope reduction claim
HSMs Supported	Hardware Security Modules used for secure key storage, generation, and management within the solution's decryption environment

⚠️

Only Listed Devices Count

A merchant cannot substitute a similar-looking terminal and still claim P2PE scope reduction. The specific POI device model must appear in the solution's validated component list. Each device also carries a PTS approval expiry date — an expired device falls out of scope for the solution.

Common P2PE Solutions

Market Overview

~124 Validated Solutions

As of 2024, there are approximately 124 PCI SSC validated P2PE Solutions across a wide range of providers and use cases.

CardConnect CardSecure P2PE

CardConnect

Clover P2PE

Clover / Fiserv

Bluefin P2PE

Bluefin Payment Systems · Assessor: Foregenix Ltd.

FreedomPay Commerce Platform P2PE

FreedomPay

Global Payments P2PE

Global Payments

Windcave P2PE

Windcave

Example POI Devices (Bluefin P2PE Solution)

Manufacturer	Device	PTS Approval
ID Tech	SecuRED, SREDKey, Spectrum Pro	Varies by model
Ingenico	iCMP, iPP310, iPP320, iPP350, iPP315, iSC250	Varies by model
MagTek	DynaPro, DynaPro 3.0	30 Apr 2021
Datecs	BluePad-50 v2	30 Apr 2024
Anywhere Commerce	Nomad 2.0	30 Apr 2021
Infinite Peripherals	Prima M	30 Apr 2021

🃏

Tap any card to reveal the answer

28 cards covering P2PE definition, the transaction flow, P2PE vs E2EE distinctions, scope reduction, and solution components.

P2PE

Point-to-Point Encryption — a PCI SSC-validated combination of hardware, software, and processes that encrypts cardholder data at the POI device and keeps it unreadable until it reaches a secure off-site decryption environment.

E2EE

End-to-End Encryption — a broader category of encryption methods that protect data from point of capture to the final destination. P2PE is a formally validated subset of E2EE. Non-validated E2EE does not qualify for PCI DSS scope reduction.

POI Device

Point of Interaction — the physical terminal (e.g., Ingenico iPP320, ID Tech Spectrum Pro) where a customer presents their card. In a P2PE solution, the POI device encrypts card data immediately upon capture.

Safe Harbor Platform

The solution provider's secure, off-site decryption environment. This is where encrypted cardholder data is decrypted back to the clear PAN before being forwarded to the issuing bank for authorization.

Token / Tokenization

A surrogate reference value returned to the merchant after a P2PE transaction is authorized. The token has no mathematical relationship to the PAN. Merchants store and use tokens — not PANs — for refunds and future transaction references.

KIF

Key Injection Facility — a secure facility that loads encryption keys into POI devices. KIFs are a component of a P2PE solution and are themselves subject to PCI SSC validation requirements.

HSM

Hardware Security Module — a tamper-resistant physical device used to generate, store, and manage cryptographic keys. HSMs sit within the solution provider's Safe Harbor environment and are listed as a supported component in each validated P2PE solution.

SAQ P2PE

Self-Assessment Questionnaire for merchants using a PCI SSC validated P2PE solution. Significantly shorter and narrower than SAQ D because cardholder data never enters the merchant's environment.

SAQ D

The most comprehensive Self-Assessment Questionnaire — applicable when a merchant's environment handles cardholder data directly. Covers all 12 PCI DSS requirement domains. Merchants without a validated P2PE solution typically must complete SAQ D.

PCI SSC

Payment Card Industry Security Standards Council — the independent body that validates P2PE solutions and maintains the official listing of approved solutions, components, and devices.

MOTO

Mail Order / Telephone Order — a transaction type where cardholder data is collected remotely (by phone or mail) rather than in person. P2PE solutions apply to MOTO transactions in addition to card-present transactions.

Ciphertext

The encrypted, unreadable output produced by the POI device when it encrypts the cardholder's PAN. Ciphertext is what travels across the merchant's network — it is useless to an attacker without the corresponding decryption key.

Scope Reduction

The reduction in PCI DSS compliance requirements a merchant achieves by using a validated P2PE solution. Because cardholder data never enters the merchant's network, fewer systems and controls fall within the cardholder data environment (CDE).

PTS Approval

PIN Transaction Security approval — a PCI SSC certification for physical POI devices confirming they meet tamper-detection and physical security requirements. Each device in a P2PE solution listing carries a PTS approval expiry date.

Annual Revalidation

The requirement for a P2PE solution provider to be reassessed each year to remain on the PCI SSC validated listing. A solution with a lapsed revalidation is removed from the list and no longer qualifies merchants for scope reduction.

P2PE Assessor

A QSA company certified by the PCI SSC to assess and validate P2PE solutions. Examples include Foregenix Ltd. (assessor for Bluefin P2PE). Not all QSAs are qualified to assess P2PE solutions.

Certificate Authority (CA)

A trusted entity within the P2PE solution's component chain that issues and manages cryptographic certificates used to authenticate devices and establish trust in the encryption infrastructure.

Re-encryption

After the Safe Harbor Platform decrypts the PAN, it may re-encrypt the data to a different format before forwarding to the issuing bank or acquirer — adding an additional layer of protection for data in transit beyond the merchant environment.

Knowledge Test

20 questions on P2PE architecture, the P2PE vs E2EE distinction, scope reduction mechanics, and solution components. Questions are designed to test applied understanding, not surface recall.