What PCI DSS is, and why payment security matters
The Payment Card Industry Data Security Standard (PCI DSS) is a set of security requirements for any business that stores, processes or transmits payment card data — or whose systems can affect the security of that data. It is maintained by the PCI Security Standards Council, founded by the major card brands. Travel is an attractive target: bookings are high-value, often taken remotely, and card details can end up in emails, call notes and booking records long after a trip is paid for.
Why travel agencies may need to address PCI DSS
If your agency accepts card payments — for tickets, service fees, packages or ancillaries — PCI DSS is likely to apply to you, through your acquirer or payment provider, regardless of how small the business is. What changes with size and setup is how much of your environment is in scope and which validation route you can use.
How the IATA programme applies to accredited agents
IATA asks its accredited travel agents to be PCI DSS compliant and to provide evidence of their compliance status. IATA explains that airlines requested the BSP card sales channel be made PCI DSS compliant. Agents update their status in the IATA Customer Portal under IATA Accreditation & Changes, selecting the relevant agency code and attaching supporting documentation where applicable. IATA's guidance points agents to PCI SSC-recognised partners, such as Qualified Security Assessors, for obtaining evidence.
Why a GDS, consolidator or booking platform doesn't remove your responsibilities
Using Amadeus, Sabre, Travelport, a consolidator or a third-party booking engine can move a lot of risk to those providers — but not all of it. Your staff still answer phones, read emails, use back-office tools and may see card details in booking records. PCI DSS responsibilities are shared, and you need to know which ones stay with your agency and get written confirmation of what your providers cover.
Why phone, email, virtual terminal and online workflows need careful assessment
Each channel exposes card data differently. A card read out over the phone may be heard, written down or recorded. A card number emailed by a customer sits in an inbox and every backup of it. A virtual terminal makes the staff computer part of the story. An online booking page can be compromised by a script that never touches your servers. The table below shows what we look at in each.
| Channel | Where card data can be exposed | What we assess |
|---|---|---|
| Online booking website | Card entry on your own page, scripts on the payment page, redirects and iframes | Whether payment is fully outsourced to a PSP-hosted page or field, and which of your systems can affect it |
| Telephone bookings | Agents hearing, keying or writing down card details; call recordings | How cards are captured (virtual terminal, PSP pay-by-link, IVR), recording practices and desk procedures |
| Email & messaging | Card numbers arriving in inboxes, chat tools, tickets and attachments | Policies and controls that stop card data being requested or kept in these channels |
| Virtual terminal | Card details keyed on staff computers | Device and network isolation, user access and how the terminal is used |
| Card-present / POS | Terminals in branches or ticketing offices | Terminal type, inventory, tamper checks and where the terminal connects |
| GDS & back office | Card data in PNRs, remarks, queues, mid/back-office exports and reports | Masking, retention, form-of-payment handling and who can see what |
How hosted payments and tokenisation can reduce scope
When customers enter card details directly into a page or field hosted by a PCI DSS-validated payment service provider, and your systems only ever receive a token, much less of your environment handles card data. That can make you eligible for a simpler validation route. It is not automatic: the pages and systems that can affect the payment flow still need protecting, and the actual reduction depends on how it is implemented and on the eligibility criteria for each validation route. Sensitive authentication data, such as the CVV, must never be stored after authorisation.
Implementing controls vs validating compliance vs programme acceptance
- Implementing controls means the security measures PCI DSS requires are actually in place and operating, every day.
- Validating compliance is the formal check: a Self-Assessment Questionnaire completed by eligible businesses, or an assessment by a Qualified Security Assessor, recorded in an Attestation of Compliance. Some routes also require quarterly external scans by an Approved Scanning Vendor.
- Programme acceptance or certification is when a specific programme — such as IATA's, or your acquirer's — receives and records your evidence under its own rules.
Documents without working controls are not compliance, and working controls without validation will not satisfy IATA or an acquirer. You need both.
Official references: IATA — PCI DSS for travel agents · PCI Security Standards Council · PCI SSC document library (PCI DSS, SAQs) · PCI SSC Qualified Security Assessors · PCI SSC Approved Scanning Vendors
Last reviewed: . This page is general information, not legal advice or a compliance determination.
