Reducing Cart Abandonment & Boosting Conversion Rates | Part 2

Table of Contents

• 3- Syntactic and Semantic Validations
• 4- Classification of Payment Errors and Messages to Be Displayed on the Front End

In the second part of the series, “What You Need to Do to Reduce Cart Abandonment Rate and Boosting Conversion Rates,” you will find details related to syntactic and semantic validations for boosting conversion rates.

3- Syntactic and Semantic Validations

Boosting conversion rates requires certain implementations. For boosting conversion rates, specific syntactic and semantic validations must be performed before sending a request to the bank on the card payment page. 

Before diving into the details, let’s start with a few statistics: Even if you perform all syntactic and semantic validations, approximately 15-20 out of every 100 payment requests sent to the bank result in failure. You can find the details of these failures in the following article.

Additional Information: The card’s first 6 or 8 characters are called the BIN Number. Based on the BIN Number, you can determine the card type (Visa, MasterCard, American Express), card category (credit card, debit card, prepaid card), card family (wings, bonus, maximiles, world, …), and the card’s issuing bank (Akbank, Garanti Bankası, İş Bankası, YKB, ..), as well as whether it’s an individual or business card. We can find basic payment system definitions in our previously published article.

To ensure that the payment request sent to the bank is as valid as possible, we recommend the following syntactic and semantic validations:

• Cardholder Name on the Card: This information must containat least two characters with a space between them (example: John Doe).
• Card Number: This must be numeric, and no letters should be included. ([0-9])
• Card Number: This should consist of 16 digits for Visa and MasterCard and 15 for American Express (Amex). Click here to learn about Visa, MasterCard, and Amex formats.
• CVC2 (Security Code): This should consist of 3 digits for Visa and MasterCard and 4 for American Express (Amex). Thus, the Card Number and CVC2 fields should total 19 characters.
• Card Number: It should be compliant with the Luhn Algorithm. Validation should be performed on the front end with JavaScript and on the server side.
• Expiration Date: This should be greater than or equal to the current month and year.
• If the entered card is a debit card or prepaid card:
  • The 3D Secure option must be mandatory (with some exceptions, payments cannot be made without 3D Secure for these cards).
  • Installment options should be hidden, and the full payment option must be mandatory (installment transactions are not allowed for these cards).
• If the entered card belongs to a bank with which you don’t have a virtual POS, installment options should be hidden, and the full payment option must be made mandatory (you cannot offer installment payments for bank credit cards with which you don’t have a virtual POS).
• Suppose the entered card belongs to a bank where you have a virtual POS, but the relevant virtual POS is inactive for various reasons. In that case, you should provide the user with an informative message and hide the installment options. The full payment option must be made mandatory (this payment request should be made in full, not through the virtual POS of their bank, but from the default virtual POS in the system at that time).

4- Classification of Payment Errors and Messages to Be Displayed on the Front End

In the final article of the series “What You Need to Do to Reduce Cart Abandonment Rate and Boosting Conversion Rate,” you will find details about the classification of payment errors and the messages/texts we recommend for display on the front end.

On the card payment page, messages that should be displayed to users who fail to pass both syntactic and semantic validations, both on the front end (client-side JavaScript) and the server side, can be as follows:

• Your name is invalid, … [If the name information is not entered, is less than 4 characters, or is not alphanumeric …]
• Your card number is invalid, … [If the card number is not 15 or 16 digits numeric or does not pass the Luhn algorithm …]
• Your expiration date is invalid, … [If the entered expiration date is earlier than the system date or is not numeric …]
• Your security code/CVC2 is not valid, … [If the security code is 3 digits (for Visa and MasterCard) or 4 digits (for Amex), not numeric, …]
• Installments cannot be applied to your card, … [If installments are selected and cannot be applied to the card, it may be a debit or prepaid card. It could be a bank card that doesn’t have a virtual POS with you, or even if the bank with a virtual POS is chosen, it may not be active now, …]
• Only 3D Secure transactions can be made with your card, … [If a bank or prepaid card is selected and a non-3D Secure transaction is attempted, …]
• Your desired product(s) are out of stock… [If products are sold out or no longer available during the cart steps, … (race-condition, sold-out)]

You’ve completed the syntactic and semantic validations, and the user has no validation errors. You’re ready to send the payment to the bank. Approximately 15-20% of every 100 payment requests sent to the bank result in failure. 

The distribution of these failures is roughly as follows:

% 33-38 “Your Limit is Insufficient”

% 15-18 “General Decline, Transaction Not Approved”

% 10-12 “Invalid/Expired Expiry Date”

% 2-3 “Invalid Security Code/CVC2”

% 29-40 Others: Internet-disabled card, exceeding the daily transaction limit, attempting installment transactions below 1 TRY, using a previously used order number, trying a transaction with a stolen card, card not authorizing a provision, inability to offer installment payments on the card, transactions not known to the cardholder, access issues, system problems, …

The bank returns an error code and message when a payment request fails. Unfortunately, error codes and messages can vary from bank to bank, and even within a specific bank, there may not be a unique message for each error code. Also, an error message may be found in different error codes.

For example:

• Error code 051, used by banks using the Payten/Asseco API and Garanti Bank, may indicate “Your Limit is Insufficient.” In contrast, error codes 061, 065, and 099 occasionally may also mean “Your Limit is Insufficient” based on the message they contain.

At this point, when you pass the error codes and messages received from the bank through a rule set, classify them, and convey them to the end user in an appropriate language, the user who understands the reason for the error will consciously try again. This will increase your cart conversion rate.

For example, if a user receives a “Your Limit is Insufficient” error, and you catch this error and tell the user, “Your card limit is not sufficient for an XX TRY transaction!” the user, if using a virtual card, will either increase their card limit or try to make the payment with another card in their wallet (Keep in mind that as of 2022, there are 161 million bank cards and 93 million credit cards in circulation).
If you’re interested in services that can increase your conversion rate, improve the customer payment experience on your website, and provide added value, you can contact us about Craftgate services.