The popularity of online payments is growing. Yet many card holders are not savvy when it comes to “making a payment online”. Creating a payment page that limits problems and helps card holders to feel secure during the checkout process is vital. This document looks at key areas around payment page design and functionality that maintain a simple and secure checkout experience.
Top 10 Features to Include on your Payment Page
1. Error Handling
Alerting card holders to commonly made mistakes on the payment page limits frustration. By using in-line error handling, the number of payment processing steps is also reduced. The transaction request does not proceed to the bank or the payment provider before a card holder’s information is accurately entered. This prevents time being wasted between web pages, lessens card holder confusion and reduces payment page abandonment. There is nothing more frustrating than the card holder having to press the back button after all details were entered only to be rejected in the next step. Error handling on the payment page alert the card holder to ensure a card number and CVV are correctly entered before proceeding with the transaction.
Simple java scripting on the payment page will allow for errors, like failing to enter the CVV,and can perform a mod-10 Luhn check to advise the user of a digit error during card number entry. Displaying this information on the payment page avoids the card holder being redirected to another page where they would have to click a back button on the page or browser, only to find all the details entered previously are missing from the refreshed pageand have to be re-entered.
2. Numeric Validation
Only allow numeric characters to be entered in fields intended for numeric characters. Being unable to enter alpha or special characters into the text box during the entry of card details or payment information will reduce finger error.
These fields include:
▪ Card Number – the 14 to 16 digit PAN on the card
▪ CVV – the 3 or 4 digit number on the back of the credit or debit card
▪ Payment Amount – in the event that the value may be inputted by the card holder. Typically used for donation pages.
3. Mod 10 Luhn Checks
The Luhn algorithm or Luhn formula, also known as the “modulus 10” or “mod 10” algorithm, is a simple checksum formula used to authenticate a variety of identification numbers like credit card numbers. Most credit cards use the Luhn algorithm as a way to
distinguish valid numbers from collections of random digits. Designed to detect accidental errors, this is a quick way to eliminate credit card number errors before a transaction is submitted to the payment gateway. Including the simple mod 10 check offers an opportunity to explain the error in a user-friendly way, encouraging the card holder to revise the credit card number before proceeding with the payment process.
The check can be set to activate as the card holder clicks the “pay now” button.
4. Expiry Date
Make it clear to the card holder which box is for month and which is for year. This can be indicated by placing a label next to or above a text box or by making month/year a selection choice in a drop down menu.
The recommended option is to enable selection of the expiration date using two separate dropdown lists: one for month and one for year. This will reduce errors in expiry date entry.
If the card holder does not select a month or year, they may be asked to do so before leaving the payment page to ensure a selection is made prior to clicking on “pay now”.
Make sure that previous years are not offered as choices in your selection menu. Sometimes you will see a day on the credit card expiration date but this is not required for processing.
The card verification value (CVV or CVV2), sometimes called the card verification value code (CVVC), card security code (CSC), card verification data (CVD), card verification code (CVC or CVC2) or card code verification (CCV) is a security feature providing increased protection against fraud during credit or debit card transactions.
Every credit card has a special three- or four-digit code generally known as a CVV2 or CVV number, for additional account protection. Cardholders are required to enter this code when processing an online payment. An identity thief who has acquired credit card information illegally cannot know the CVV number unless they have had physical access to
Validating the CVV Length
Visa, MasterCard, and Discover Card use a three-digit CVV number placed on the back of the credit card. American Express uses a four digit number placed on the front of the credit card. We recommend validating that that the CVV code contains the correct number of digits for its credit card type. To do this you will work with two parameters: the card number and its CVV number. The main card number is used to determine the associated account linked to the card. The first six digits of the main card number identify the card issuer, for example, American Express or MasterCard. If the card is issued by American Express, the code you will
check for is 4 digits long. For all other cards, the CVV code has 3 digits. If the CVV entered by the card holder is too long or too short to match the card type selected, you can alert the user with a friendly request to re-enter the correct CVV.
Simple CVV Explanation on Payment Page
For card holders new to online payments, the CVV may become confusing as they may not know what this is or where it is located on their card.
- Providing a short description next to the CVV input field. For example: “Enter the last 3 digits on the back of your card.”
- Providing a HTML hyperlink that will open up a box with picture and description.
6. Card Types
The card type is equal to the associated card issuer. Examples are Visa, MasterCard, Amex, Diner’s Club and JCB.
Here are some tips for implementing card type on your payment page:
- Have “please select” or “select card type” as the default in the drop menu and if cardholder does not select one, prompt them to select card type.
- Don’t activate validation for this field – Banks do not validate this field.
- If required: you can work out the Association from the BIN and populate the card type in the transaction request message without card holder entering this information.
7. Successful and Failure Pages
Successful and failure pages are used to notify the customer if the payment was successful or whether it failed. Based on your integration type, this will either be done by a response form post or by merchant interpretation of the result / response message in a web service call.
8. Processing Icons
There is little that is more confusing for a card holder than being left to wonder whether their payment is being processed or if the page has frozen. After leaving the payment page, a short message and some action script to advise the cardholder that their payment is being processed is all that is needed to alleviate concern.
9. Security Logos
Boost confidence and show that your page is secure. Card holders want to know that their card details are 100% safe and secure when making purchases from a merchant online.
Clearly displaying approved security logos on the payment page is a great way to do this. Recognized SSL security logos like Verisign, McAfee and Geotrust can help build customer trust. Testing has revealed that uplift is increased by 3 to 5% when these logos are included on your payment page.
Carefully consider the placement of approved security logos on the page to ensure that card holders can see them easily.
Logos are available for download from the MyGate’s Developer Centre.
SSL Provider Logo – i.e. Thawte, Geo Trust
3D secure logos – i.e. Verified by Visa / MasterCard Secure Code
MyGate Secure Merchant
10. Page Security
Disable Double Clicks
Disable Right Clicks
Disable Shift + Clicks
Disable Status Bar Links
Managing the Bank Response Message
A bank response message is returned in a 5002 MyGate response code. The bank response message presents the bank’s response to an authorization request and is found in data elements within MyGate’s authorization response. A bank response contains the transaction results that identify the specific reasons why a transaction has failed or been declined. These reasons are classified against bank response codes. Linked to each bank response code is a response message and response description.
Bank Response Codes:
The bank response code is a unique code linked to the failed or declined reason. Response codes are numeric and are returned in the data element of the transaction result.
Bank Response Messages:
The response message is a brief message outlining the specific response code. Response messages are returned in the data element of the transaction result.
Bank Response Descriptions:
The response description is a detailed description of the response code and in some cases a resolution to fix the specific failed reason. Response descriptions are returned in the data element of the transaction result.
When to notify a card holder of a failed transaction
In the event that a transaction fails, you can display the response messages on the failure page to notify the card holder of the reason why.
Bank Response Code: 51
Bank Message: Insufficient Funds
Bank Description: Contact Bank
In the above scenario, the card holder knows why the payment failed.
When to NOT notify a card holder of a failed transaction
If a transaction fails due to suspicious behaviour, it is recommended to not display this to the card holder.
Bank Response Code: 43
Bank Message: Stolen Card
Bank Description: Contact Bank
Fast payment processing times
A fast transaction response from the time the card holder clicks “pay now” to the time a transaction response is received from the payment provider will minimize card holder frustration and prevent their abandoning a payment. Acceptable processing times are between 6 to 8 seconds.
Payment Email Confirmation
Increase your customer confidence by sending an email to confirm the payment and order were successful. This can be achieved by the card holder entering their email address from within your shopping cart application, by entering the email address on MyGate’s hosted payment page or by populating the email address into the API message request.
- In the event that communications drops, the card holder will receive an email notifying them that the payment was successful.
- A detailed email provides the card holder with an overview of what was ordered.
- An additional opportunity is provided to communicate with your customer.
Tips for Payment Confirmation Emails
1. From Email Address
Choose an email address that shows whether the customer can respond or not. An example of an email showing a customer cannot respond is firstname.lastname@example.org.
2. Email Subject Line
Create a subject line that makes it clear the email is about the order and payment. Examples are to use an order number, customer number or payment reference. An example subject line would be ‘MyGate Order Number 965’.
3. Include Merchant Details and your Company Logo
Customers like to see a phone number and email address. Make sure you add the country code to your phone number if you are selling outside of the country you operate in. When selling to companies you may want to add your company registration number and VAT / Sales Tax number.
4. Personalize mail with Customer Name
The customer will feel more special if you customize the email with a Dear (Name) or Hi (Name)
5. Make it clear that the Payment was Successful in the Post Script
Example: Thanks for your order. Your payment was successful.
6. If possible show Which Items were Purchased and Order Summary
Believe it or not, people do sometimes forget what they ordered.
7. Provide Link directly to the Shopping Cart
Example: Click here to return to your cart.
8. Include payment details returned from the payment provider, for example:
- Transaction Date
- Transaction Status
- Transaction Reference
- Card Holder Name
- Hashed PAN
9. Avoid superfluous navigation, links and calls to action
In other words, don’t clutter your page!
10. Include Customer Details
11. Display the customers details including the shipping address
This can act as another failsafe in the event that any information was entered incorrectly during checkout.
Payment Page Deployment Options
Enterprise Solution Range
If you are a merchant using any of MyGate’s Enterprise solutions, you will host your own payment page. The developer will be required to optimize your payment page.
Virtual Solution Range
If you are a merchant using any of MyGate’s Virtual solutions, the payment page will be hosted by MyGate. MyGate’s hosted payment pages and processes have been optimized to reduce payment page abandonment and ensure maximum conversion ratios.