Use this checklist to reduce payment card failures, then follow all compliance for payment card rules and policies.

Preventing and Recovering Payment Card Failures:

  1.  Set default currency according to the following guidelines.
  2.  Send the correct  creditCardType code, i.e. CA for Mastercard.
  3.  Validate card numbers, security values and expiration dates for proper suffix, format, or character length.
  4.  Use Payment Types Request to obtain valid card types.
  5.  Use Itinerary ID to resubmit a failed booking on a declined payment card in order to convert a failed itinerary to a successful one.
  6.  Use the localized presentationMessage field to inform the customer of the reason their card has failed. See Credit Card Errors for details.

Contractual Obligations

All partners, through their affiliate contract, are obliged to follow all PCI, credit card company, and electronic security policies as mandated by each of these areas of liability.

Companies own the responsibility to protect their users' privacy and personal data. Burdened by this liability, credit card companies have united to establish the Payment Card Industry (PCI) council, in order to create a common and accepted set of security guidelines for anyone handling sensitive consumer data. These guidelines are designed to keep retailers and their customers from victimization of identity theft and to ensure that card data is protected and handled properly.

EAN may request a PCI Attestation of Compliance (AOC) for your integration. To provide an AOC, or to find out if your integration meets the requirements for an AOC, complete this questionnaire from the PCI Security Standards Council:

PCI Best Practice Short Guide:

  • Build and maintain a secure network: This includes firewall installation and a secure password policy. 
  • Protect the cardholder's personal data: This entails implementing data encryption across any public network. 
  • Maintain a network vulnerability management program: This includes regular updates to anti-virus software and other security software applications. 
  • Implement strong access control measures: This requires a unique ID assignment for each employee with network access. 
  • Regularly monitor and test networks: This means monitoring and keeping track of all access to cardholder data. 
  • Maintain an information security policy: Adhere to all of the above, and document the policy as part of IT standard operating procedures.
  • Do not store any payment card information without a PCI certificate.
  • PCI compliance is required even if you do not store payment card information, as sensitive data still passes through your network and servers during processing and transmission of requests.
  • Learn more about PCI Security Standards and becoming PCI certified at

Is EAN PCI compliant and certified?

Absolutely. We meet and exceed all such compliance and certification standards for the establishment, implementation, monitoring, review, maintenance and improvement of all EAN’s management systems. We also undergo a rigorous annual audit to renew our certification each year.

Card Security Values Required on All Booking Requests

The Card Security Value (sometimes called CSV, CVV2, CVN, CID, CVC2) is referred to as creditCardIdentifier when making an API reservation request. This is found on the back of the card as illustrated.

  • If the CSV value is not sent in reservation requests the card processor will reject the purchase and the reservation is failed bookings on any prepaid reservations.

DO NOT store CSV values beyond the completion of the transaction and payment process as required for PCI Compliance.

Mandatory Requirements Regarding Card Number Truncation 

Displaying payment card numbers on receipts, web pages or emails

  1. Display ONLY the last 4 digits of the card number or do not display at all
  2. DO NOT display the expiration date of the card. 
  3. DO NOT store payment card numbers, expiration, name or address in a manner that is inconsistent with PCI Security Standards:
  4. If you have any doubt about PCI Security Standards, do not store any card data at all

Any partner that breaches any PCI required mandates regarding payment card information will incur fines or penalties directly from the offended source for misuse of payment card information.  All partner contracts require full compliance of all PCI regulations.

EAN is not responsible for any misuse of content on the partner website. As stated in your partner contract, each partner is responsible for following all rules and requirements, both by EAN, third party entities, and laws.

SSL Required on all Booking, Confirmation, Itinerary, Cancellation Pages 

Secure the transmission of payment and personally identifiable data by using a secure certificate with any forms servicing email addresses, names, payment information, physical addresses, phone numbers, etc.

This is required with no exceptions. 

  • All booking forms, confirmation, itinerary, and cancellation pages MUST be secured with a trusted certificate. 
  • NO payment card numbers are to be re-displayed on any of these pages once the user has entered the information. 
  • NO payment card numbers should be stored in any partner applications as this is a violation of bankcard policies. 
  • Since we are the host of the transmission of data from your server to our servers, WE are responsible for providing the certificate. Your certificate will not be used in this transmission. 
  • Failure to send your reservation request to us with the HTTPS protocol will result in an exception message as seen below:

verbose message = Reservation requests must be made through HTTPS;

presentation message = Reservation requests must be made through HTTPS

Mandatory Card Brand Parity Requirements

TIP: Follow the information below to pass final Launch Requirements and site reviews for Payment Card Brand Parity.

These mandates are currently being enforced by credit card companies.

  • If your website does not follow ALL items listed below, your site is in jeopardy of extensive non-compliance fines starting at $20,000 and quickly escalating to $100,000.
  • Credit card companies randomly audit websites for compliance of brand parity.

Brand parity means that no specific preference is selected or displayed on payment selection choices, and that no one payment option is displayed with larger images or less equality with be default or by choice.

The user must land on your payment options with a "blank" choice until a selection has been made. And, all payment types must be presented equally.

From the Card Brand Parity Outline

"No Brand, Logo or Acceptance Mark or Symbol of a payment method may be of greater dimension or in any way appear larger or appear to be of more importance than any other Brand, Acceptance Mark, Logo or Symbol."

  • Check out pages on websites must list accepted payment methods - a drop down menu is not acceptable on its own. 
  • Any drop down menus or radio buttons cannot be pre-selected. This explicitly indicates a preference for a specific payment type. 
  • Include card logos of available payment types in equal size and distribution. The preferred layout is a single line or equally dispersed table in order to avoid inadvertent display of preferred payment types. 
  • "Payment Options" is preferred over the term "Credit Card" as indicated below in order to avoid inadvertent preference for credit cards over debit/check cards or other payment types.

Acceptable Format Examples:

Note that no card type is pre-selected and that all examples start with a blank selection.  The user must always enter the page with a BLANK choice.

Sample Images:

Note that the payment types request method ("getPaymentInfo") returns those cards that can be used with the currency being submitted in the reservation request. 

  • Including "locale" in the payment types request will return more options than omitting locale from the payment types request.

When making this request method before loading payment input form, users will be able to select the applicable payment methods that can be used with that currency.

  1. ONLY display the card types returned in the PaymentTypesResult.
  2. Refer to the Reservation Request <creditCardType> for additional information.

Examples of Unacceptable Display

These are considered with pre-determined preference or pre-selected choice. These all fail the Launch Requirement.

  1. Drop down list without images of payment types 
  2. Payment types are divided into two separate graphic displays 
  3. Instructional messages are separate in graphic displays 
  4. Card descriptor suggests debit/check cards are not accepted 
  5. Sizes of comparable objects are NOT the same 
  6. Graphical displays ordered vertically as if an order of preference
implementation example which breaks rules 1, 2 and 3

implementation example which breaks rules 1, 2 and 3