Credit card guide

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

Contractual obligations

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 by identity theft and to ensure that card data is protected and handled properly.

Rapid 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:

https://www.pcisecuritystandards.org

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 http://www.pcisecuritystandards.org.

Is Rapid 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 Rapid'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 prepaid reservations will fail.

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: http://www.pcisecuritystandards.org/
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.

Rapid is not responsible for any misuse of content on the partner site. As stated in your partner contract, each partner is responsible for following all rules and requirements, including those of Rapid, third party entities, and laws.

SSL required on all booking, confirmation, itinerary, and 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.

Mandatory card brand parity requirements

These mandates are enforced by credit card companies.

• If your site 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 sites for compliance of brand parity.

Brand parity means that no specific preference is displayed on payment selection options and that no one payment option is displayed with larger images or less equality than any other.

The user must land on your payment options with a "blank" choice until a selection has been made. 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 sites 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 ("Get Accepted Payment Types") returns those cards that can be used with the currency being submitted in the reservation 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 payment-options response.
2. Refer to the Get Accepted Payment Types Documentation for additional information.

Examples of unacceptable display

These are considered to display a pre-determined preference or pre-selected choice. These would all fail the launch requirements.

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.