Payment
Maximise conversion at the payment stage by reassuring users , and employing convenient input methods , such as : scanning cards , payment options and express payment for first time users ; and pre-populating data for return users ; etc .
Costs are transparent ( itemised and total costs )
Shopping baskets should display all of the items within it and their associates costs , discounts or savings , and total cost . Checkouts should also display the associated taxes , delivery costs and total costs .
For return user , payment details are prepopulated ( for convenience )
Automatically pre-populate payment data , for the same benefits as above . The only field that requires manual entry each time - for security reasons - is the CVV field .
User is only presented with payment options accepted in their country
Provide users with payment methods appropriate to their country . Provide multiple options to users to ensure you capture the full range that users would pay with in each country , e . g . credit card , debit card , Paypal , etc .
Express payment / checkout option is provided ( e . g . Google Wallet , PayPal , Apply Pay )
Some customers prefer express payment / checkout methods as a more convenient alternative to credit and debit cards and manually entering personal and address details . Certain types of goods also lend themselves more to these methods , such as low-cost or one-off purchases , which the user doesn ’ t have to consider too hard . Reducing the number of steps in the checkout process and amount of data input required will increase the app conversion rate . Alternative methods include PayPal , Apple Pay and Google Wallet . With Apple Pay , avoid displaying the payment button if the user can ’ t pay that way ( i . e . no authenticated card set-up or not on an Apple support device ).
For first time user choosing a card payment , after entering the first four digits of the long card number , the Card Type is automatically detected ( e . g . Visa debit card )
For first-time users or guest checkout , avoid asking users to choose their card type . After they ’ ve entered their cards ’ first four digits the - credit or debit - card should be automatically recognised , and displayed for their recognition and reassurance .
For first time user choosing or registering a card , all data can be entered sequentially in a single field ( e . g . 16-digit long number , then MM / YY and finally CVV )
For first-time users or guest checkout , avoid forcing users to toggle between multiple fields in order to populate their card details . Instead , request all data be entered in a single field , with in-line instructions for each piece of sequential data required . For example , when users reach the payment card details they will already have provided their full name , and now just need to provide their card : 16-digits long number , MM / YY , and CVV . This is far more convenient for users than toggling between multiple fields and pogoing up-and-down between fields and the number pad . ( See image 25 )
For first time user choosing a card payment , an option to scan it is displayed ( for convenience over manually entry )
Give users the option to conveniently scan their payment card instead of manually entering data . Benefit to user is convenience ( it takes a few seconds instead of a minute ) and benefit to business is 100 % accurate data captured and less basket abandonment - no more long numbers entered incorrectly , or names not entered exactly as they appear on the card , etc . ( See image 25 )
30