"Your Comprehensive Guide to Preventing Potential Revenue Loss"
For e-commerce websites, traffic is an extremely valuable yet equally costly phenomenon. To generate this traffic, there are various marketing activities available. In this article, we will proceed through a scenario where users are brought to your e-commerce website as a result of these diverse marketing activities. Of course, it is essential for these users to register on your website, like your products upon seeing them, and add them to their cart to make a purchase. When all these happen, it is crucial not to lose the user who has added your product to the cart from your website.
On a global scale, when examined in 2023, the abandonment rate for shopping carts is 75%. The lower this rate, the higher the counterargument, which is the cart conversion rate, will rise. Our goal here is to reduce the cart abandonment rate and, consequently, improve the cart conversion and payment success rates.
So, what is the payment conversion rate in shopping? How can the rate of cart abandonment be reduced? How can the payment success rate be enhanced? We will explore the answers to all these questions in the following sections.
Content
Shopping Cart and Payment Steps Design
1.1. Cart and Product Selection
1.2. Delivery and Billing Address Selection
Payment Page
Card Payment Page
2.1. Syntactic and Semantic Validations
Smart and Dynamic Payment Routing
Classification of Payment Errors and Messages That Need to Be Displayed
Payment Retry
Payment and Refund Tests
Payment Tests
Refund Tests
1-Shopping Cart and Payment Steps Design
Shopping steps on e-commerce websites generally consist of roughly three stages:
--> Cart and product selection
-->Delivery and billing address selection
-->Payment page
If a user abandons the shopping process at any stage of these steps, it is referred to as "Shopping Cart Abandonment." On the other hand, if the user successfully completes the shopping process, it results in cart conversion, or simply "Conversion."
When designing the shopping cart and payment steps, you will observe an increase in your cart conversion rate and a decrease in your shopping abandonment rate if you adhere to accepted design principles (DP). We can list these design principles as follows:
DP1 - Minimum Page Transitions: Making the payment process easily accessible for users who have successfully added your product to their cart will increase your cart conversion rate. It is crucial to streamline the shopping steps by providing the user with a minimum number of page transitions. The shopping cart and payment steps should not exceed three pages. Each additional page will decrease your cart conversion rate and increase your shopping abandonment rate.
DP2 - Minimum Clicks: The fewer clicks required for users to complete a transaction, the higher your cart conversion rate will be (ideally, one-click/express checkout).
DP3 - Minimum Distraction Elements: Elements that can distract users during the shopping steps should be removed, and links/banners that lead outside the shopping steps should be eliminated. If you must display buttons, links, or banners, opt for lightbox or pop-up displays on the current page instead of opening a new page when these elements are clicked.
DP4 - Maximum Information: Users should be informed about which step of the shopping process they are in; the products they are about to purchase and delivery/billing address information should be presented in a summarized form.
DP5 - Stay Within the Visible Limits of the Screen (Above the Fold): The most viewed and clicked sections of the page are those visible on the screen; as the page scrolls down, visibility and click-through rates decrease. Presenting all content as much as possible within the visible limits of the screen can be beneficial.
1.a-Cart and Product Selection
-->At the top of the page, there is a three-step online purchasing experience (DP-1). The user sees a prominent and colorful "Confirm Cart" button. Besides that, there are no other attention-grabbing calls to action.
-->The user cannot navigate away from this page, except for the homepage, as there are no banners or links (DP-3).
-->On the cart page, the user is provided with information about the current step and the total price (DP-4).
-->All content on the page is within the visible limits of the screen, and in case there are multiple items in the cart, the "Confirm Cart" button is placed in the top right to ensure visibility (DP-5).
1.b Delivery and Billing Address Selection
--> Again, at the top of the page, there is a three-step online purchasing experience (DP-1). --->The checkbox with the statement "'My Billing Address,' 'Same as My Delivery Address'" is pre-checked as the billing address is typically the same as the delivery address. Similar to the previous page, the "Proceed to Payment" button is used as a single attention-grabbing element (DP-2).
-->When clicked to edit the address, it doesn't redirect to a separate page but presents the content on the same page using a lightbox (DP-3).
-->On the address page, information about the current step and the address is displayed (DP-4)
-->All content on the page is within the visible limits of the screen (DP-5).
1.c Payment Page
-->The user completes the third and final step on this page (DP-1).
-->By entering three correct pieces of information related to their card, checking the agreements in just one checkbox, and clicking the "Complete Payment" button, the user can successfully leave the payment page (DP-2).
-->There is no distracting element on the screen that could divert the user's attention or make them unfamiliar with the payment step (DP-3).
-->The system displays the card visual appropriately according to the Bank Identification Number (BIN) information, and it colors and displays logos according to the card family, card type, and bank (DP-4).
-->Although the agreements are placed at the bottom of the page, the agreement checkbox and the "Complete Payment" button remain in the visible part of the screen (DP-5).
-->We will provide a detailed examination of the payment page in our second subsection titled "Card Payment Page."
2-Card Payment Page
When optimizing your credit card payment page, there are several points to pay attention to. These points contain important tips that will increase your payment success rate. In addition to these points, the 5 design principles (DP) mentioned in our previous subsection will also be applicable for this and subsequent subsections.
1. If you offer multiple payment alternatives, you should initially present the credit card payment page as the default option.
2. Since payment can also be made with debit cards and prepaid cards, it is more accurate to use terms such as "Card Number" and "Name on Card" instead of "Credit Card Number" and "Name on Credit Card."
3. Gathering the name on the card information in a single input field instead of two separate input fields will support the minimum click principle.
4. Displaying the card number in a spaced format like "4043 0812 1111 2222" will reduce the likelihood of errors during user input.
5. For the expiration date, it should be captured in two separate combo boxes as 08/25 or 08/2025. If you capture it as August/25, it may confuse the user about which month August corresponds to since the card indicates 08/25. Date boxes should be writable as well as selectable.
6. Presenting input fields in the following order, matching the card design, will be effective: Name on Card, Card Number, Expiry Date, CVC (Security Code). For example, if you collect the security code before the expiration date, the user will need to flip the card to the back while on the front and then return to the front afterward.
7. There is no need to prompt for the bank and card type (Visa, Mastercard, American Express). It is possible to obtain this information from the first 6 or 8 digits of the card, known as the Bank Identification Number (BIN).
8. If possible, provide the 3D Secure option to allow users to pay with 3DS if they prefer.
9. In our country, with 111 million credit cards and 182 million bank cards, users can change their card preferences during payment based on the offered advantages. Therefore, displaying all the opportunities of the banks you work with (installment options, installment deferral, earning extra points, etc.) through a lightbox/banner or similar informational tool would be beneficial.
10. Installment options and special offers for the card/bank can be shown after entering the card number.
11. The checkbox indicating that the user has read and approved the Distance Sales Agreement and Preliminary Information Form should not come pre-checked by default, ensuring that the user has not made a transaction without their consent.
12. The payment page must have an SSL certificate (HTTPS). Displaying logos of affiliated banks, cards, and payment infrastructure providers can help ensure that the user is using the correct card.
13. Syntactic and Semantic Validations should be performed on both the front end and the server side, and necessary informational messages should be displayed to the user.
2.aSyntactic and Semantic Validations
In the credit card payment page, there are certain syntactic and semantic validations that need to be performed before sending a request to the bank. By paying attention to these validations, you can increase your successful payment rate and basket conversion rate.
To ensure that the payment request sent to the bank is as valid as possible, the syntactic and semantic validations to be performed can be listed as follows:
Preliminary Information: The first 6 or 8 characters of the card are referred to as BIN (Bank Identification Number). Based on BIN, the card type (Visa, MasterCard, American Express), card category (credit card, debit card, prepaid card), card family (Wings, Bonus, Maximiles, World, etc.), and the bank of the card (Akbank, Garanti Bankası, İş Bankası, QNB Finansbank, etc.) can be determined.
1-"Name on Card" field should consist of at least two characters each with a space between them (example: Jo Lu).
2-The "Card Number" must be numeric, and letters should not be entered. (0-9)
3-The "Card Number" should consist of 16 characters for Visa and MasterCard, and 15 characters for American Express (Amex). The CVC2 (security code) should have 3 characters for Visa and MasterCard, and 4 characters for American Express (Amex). This way, the total length of the "Card Number" and "CVC2" fields will be 19 characters.
4-The "Card Number" must pass the Luhn algorithm; it should be compliant with this algorithm. Validation should be performed both on the front end using JavaScript and on the server side.
5-The "Expiration Date" should be greater than or equal to the current month and year.
6-If the entered card is a debit card or prepaid card:
Since these cards mostly cannot proceed with payments other than 3D Secure, the 3D Secure option should be mandatory.
Installment options should be hidden, and the option for paying in cash should be mandatory. (Because installment transactions cannot be processed with these cards.)
7-Since you do not have a virtual POS for bank credit cards, installment options should be hidden, and the option for paying in cash should be mandatory.
8-If the entered card belongs to a bank with an active virtual POS but, for various reasons, the virtual POS is inactive at that moment, the user should be informed with a message. Installment options should be hidden, and the option for paying in cash should be mandatory. This payment request is expected to be processed as a cash payment through a virtual POS from another default bank in the system, not from the user's bank's virtual POS at that moment.
However, if we proceed based on statistics, even if you perform all syntactic and semantic validations, roughly 20-25 out of every 100 payment requests sent to the bank will end in failure. We will delve into the details and solutions of these failed payments in the subsequent subheadings.
3-Smart and Dynamic Payment Routing
Smart and dynamic routing allows you to process your payments through the virtual POS or payment/e-money institution with the lowest commission at the time of collection. This way, you can reduce your payment-related expenses and increase your payment success rate.
While not present in every payment gateway, through payment orchestration, you can implement smart and dynamic routing, directing the payment that the user attempting to make to the fastest-responding, lowest-cost, and highest acceptance rate POS.
4-Classification of Payment Errors and Messages That Should Be Displayed
We previously discussed syntactic and semantic validations performed both on the client-side (using Client-side JavaScript) and the server-side on the card payment page. In accordance with the fourth design principle, referred to as "DP4" users who fail these validations should be provided with necessary messages for maximum information. Depending on the situation, some of the messages that can be displayed are listed below:
1. The "Cardholder Name" field should consist of at least two characters with a space between them (e.g., "John Doe").
2. The "Card Number" should only contain numeric characters (0-9).
3. For Visa and MasterCard, the "Card Number" should be 16 characters long; for American Express (Amex), it should be 15 characters long.
4. The "CVC2" (security code) should be 3 characters for Visa and MasterCard, and 4 characters for American Express (Amex).
5. The entered card should belong to a bank or prepaid card; hence, the 3D Secure option is mandatory, and installment options should be hidden, with only the upfront payment option available.
6. Your expiration date is not valid: If the entered expiration date is less than the system date or is not numeric
These messages aim to inform users about the specific issues they need to address for a successful payment.
If you have conducted syntactic and semantic validations, and there are no validation errors from the user, you are ready to send the payment to the bank. However, as mentioned before, despite this preparation, approximately 20-25% of every 100 payment requests sent to the bank will end up in failure. The distribution of errors for these unsuccessful payments is roughly as follows:
%33-38: Your Limit is Insufficient
%15-18: General Decline, Transaction Not Approved
%10-12: Incorrect/Invalid Expiry Date
%2-3: Incorrect Security Code/CVC2
%29-40: Other: For example; card offline, exceeding the daily transaction limit, attempting installment transactions below 1 cent, using a previously used order number, attempting a transaction with a stolen card, card not providing authorization, inability to offer installments on the card, transactions not authorized by the cardholder, access issues, systemic problems, etc.
When a payment request results in failure, the bank sends an error code and message associated with the error. It should be noted that these error codes and messages can vary from one bank to another, and there is a possibility that error codes and messages may not be unique to a specific bank. Not only does each error code not have a unique message, but different error codes may also share the same error message.
To illustrate a scenario where a message corresponds to multiple codes, let's take the example of the "Your Limit is Insufficient" error. This error is typically associated with the error code "051," but occasionally, it might also be associated with error codes "061," "065," and "099," depending on the message content. For a scenario where one error code has multiple messages, consider the "99" error. If the message for the "99" error contains "Fraud," it indicates that the attempted transaction is suspicious. On the other hand, if it contains "System," it signals a system or communication error.
In light of these messages, if a user enters incorrect information and knows where the mistake occurred, providing clear and informative messages can increase the likelihood of a successful payment in their second attempt. Consequently, this can improve your conversion rate.
For example, if a user receives the "Your Limit is Insufficient" error and you catch this error, providing a message like "Your card limit is not sufficient for a transaction of XX TL!" can prompt the user to either increase their card limit (if using a virtual card) or try making the payment with another card.
5- Payment Retry
Your software or software solution that allows you to integrate with POS. After classifying the payment errors returned from banks and payment/e-money companies, it tries to transfer your payments a second time from your other Virtual POS with the lowest commission or from the payment/e-money institutions you have an agreement with in 8 different error groups. Payment Retry should ensure that you increase your payment conversion rate by not reflecting these 8 error groups to the end user and preventing your customer from repeating the same payment steps a second time or exiting the page due to an error not caused by them.
6-Payment and Return Tests
You have implemented all the "best practices" in the cart and payment steps, performed syntactic-semantic validations, categorized payment errors, and displayed meaningful error messages on the frontend for users. You are ready to go live. But how will you conduct payment and refund tests? First, it's worth noting:
--> The payment system is a "real-time" system, meaning the effects of any changes you make are reflected to users immediately at the second level.
--> The payment system does not tolerate errors; you must go live with zero (0) errors.
--> It is better for the payment system not to work at all than to work incorrectly. It is more reasonable not to process any transaction than to process it incorrectly.
--> If a payment doesn't go through within 2 minutes, alarm bells start ringing.
Given these points, to avoid errors in a "real-time" payment system, you need to conduct certain unit and functional tests. Moreover, even if you make very minor changes to the live system, you should perform detailed tests to fully understand their effects. We will discuss these tests under two subheadings: "Payment Tests" and "Refund Tests".
6.a Payment Tests
Let's assume that you have multiple virtual POS systems, meaning that you work with multiple banks, offer installment options for credit cards from these banks, and also have alternative payment methods. Even for card payments alone, you will need to perform tests in different combinations for each virtual POS, including credit cards, debit cards, and prepaid cards from that bank, with options for cash payments, installment payments, normal payments, 3DS payments, single products, multiple products, gift certificate inclusion, exclusion, installment at a different rate, cash price installment, etc. The formula can be generalized as:
(Number of Virtual POS) x [Credit Card, Debit Card, Prepaid Card] x [Cash, Installment] x [Normal Payment, 3DS Payment] x [Single Product, Multiple Products] x [With Gift Certificate, Without Gift Certificate] x [With Interest, Cash Price Installment] ... ~= 100 + payment tests
Whenever you make even the smallest change in the payment system, you need to conduct these tests. However, manually performing these tests may take several days, which is not realistic. Automating these tests as much as possible with test automation tools, making them independent of human labor, will save you time and enhance the quality of the project. Especially for 3D Secure transactions, completing end-to-end tests manually is not feasible. You can conduct cross-browser tests using test users, test cards, and products/orders on browsers such as Chrome, Firefox, IE, Safari, Opera, etc.
6.b Refund Tests
The same considerations in testing apply to the refund of a received payment. Since most e-commerce websites have a shopping cart and users can purchase multiple products, the following refund combinations will arise:
1. Full refund and cancellation of a 100 TL order (-100 TL cancel),
2. Full refund of a 20 TL order (-20 TL refund),
3. Partial refund of 5 TL for a 20 TL order (-5 TL refund),
4. Second partial refund of 10 TL for a 20 TL order (-10 TL refund),
5. Cancellation of the refund for a 100 TL order.