A summary deck from a larger presentation on international checkout pages. lots of general facts and findings about specific tailoring of forms to your international users needs. this has examples from the travel industry but can be applied to any industry. For the full presentation please get in touch

1. The anatomy of an
international payment page
November 2015
Ben Scammels

2. • Usability test of our payment pages
• International staff review
• Competitor benchmarking (Expedia,
Booking.com, Amoma, Hotels.com)
• Stakeholder and fraud team input
• ...and reading a ton of online articles
on checkout best-practice
Sources of research

3. Our page today

4. Form field: Title
Facts
• Amazon, John Lewis, Swinton Insurance don’t ask for it
• 1/3 of UK users do not use it if it’s not mandatory
• It MUST be internationalised… but how do we know what
the various formats and conventions are?
• Norway consider it outdated
• Not having Ms. is considered sexist by some people
• Master is only relevant to boys under 13 - can under 18’s
be lead guests?
• BA get absurdity award for asking for random titles
(corporal, rabbi, viscount)
Source
http://www.siliconglen.scot/usability/courtesytitles.html

5. Form field: First & last name
Facts
• Many countries do not adhere to this format
• The Spanish typically have 4 parts to their names
• Malaysians refer to their family name first
• Many names contain (apostrophes, numbers, hyphens,
full-stops) (Smith-Johns, O’Reilly, William John 3rd,
Sammy Davis Jr.)
• ...therefore allow capitalisation of later letters and characters
• Best practice: ‘Full name’ single form field
Source
http://www.w3.org/International/questions/qa-personal-names
http://blog.jgc.org/2010/06/your-last-name-contains-invalid.html

6. Form field: Email address
Facts
• People get cagey about providing contact details so
explain why you are asking for it
• Email address can contain _%!$|{}^ and spaces. Be wary
of validating it against characters
• “...users with atypical (but real and entirely valid) e-mail
addresses are blocked by overly sensitive e-mail validators
that effectively prevent the user from finishing their
checkout
• Auto-capitalisation and correction can mess things up.
Turn it off!
Source
http://haacked.com/archive/2007/08/21/i-knew-how-to-validate-an-email-address-until-i.aspx/
http://baymard.com/blog/validations-vs-warnings
https://en.wikipedia.org/wiki/Email_address#Validation_and_verification

7. Form field: Phone number
Facts
• People get cagey about providing contact details (especially if
you already have an email) so explain why you are asking for it
• “We did notice one exception in the behavior of the test
subjects: the more expensive the order was, the more tolerant
the subjects were.”
• Some phone numbers contain hyphens, spaces and brackets
and are differently formatted between countries so beware
about pre-formatting and barring characters.
• When you add an international code you do not need the 0
from the phone number but people are confused about this
Source
http://baymard.com/blog/checkout-experience-seemingly-unnecessary-information

8. Form field: Address (line1, line 2, city/town, state)
REALLY? Do we really need this data? We don’t send
people a physical item...
REALLY?
Facts
• Our fraud department use the address to do some manual
fraud ‘detection’... it’s an inexact process
• If you do ask for it, varying address formats need considering
as to not exclude anyone

9. Facts
• Ireland, Congo, Bahamas, Angola don’t use a postal code
• ‘Zip code’ is an American term. ‘Postal code’ is
internationally generic
• Most countries use numbers-only postal codes, few
exceptions are Canada, Argentina and the UK that use
alphanumerical codes.
• Brazil has a hyphen in there ‘CEP’ which as 8 countries,
Iceland has 3, The UK has a space between their code
• Postcode can be used to find an address (or auto-populate
a state/city in the US)
• Usability issues: “Customers entering the letter ‘O’ when a
zero was required. Error messages were generic so users
couldn’t see the issue. These cause a 2.5% abandon rate!”
Form field: Zip code/Postal code
Source
https://medium.com/user-experience-design-1/the-anatomy-of-a-credit-card-payment-form-32ec0e5708bb
http://yadayadablah.com/125/postal-code-vs-zip-code/
https://econsultancy.com/blog/10959-are-online-retailers-being-tripped-up-by-postcode-entry/

10. Form field: Country
Facts:
• Different sources consider there to be different numbers and
they can change (Sudan and Montenegro became countries in
2011 and 2008 respectively)
• Country select menus do have known usability issues (200+
options is too much, scrolling through them is arduous etc)
...but regardless Amoma, Booking.com, Airbnb all use it.
• There is a pretty good open source autocomplete tool made
from Baymard (http://baymard.com/labs/country-selector)
but it doesnt support translation.
• A standard approach is to auto populate the country (from
the IP address or site country version) but this may not be the
country of Billing address...
Source
http://www.worldatlas.com/nations.htm
http://www.smashingmagazine.com/2011/11/redesigning-the-country-selector/

11. Form field: Payment/Card type
Facts:
• Countries have different card options (ie. France has ‘CarteSi’)
• “International cards (Visa and MasterCard) have a less than 40%
online payment market share in countries such as Germany, Russia
and China”
• If their card isn’t accepted , Paypal, Google Wallet, Alipay and
Amazon, provide good alternatives. These options allow all
manner of cards to be accepted so you inherit their payment
accessibility
• In Russia it is very common to pay couriers for the online purchase
of a physical product
• You can assess card type (and whether it’s Credit, Debit...) by the
card number...
Source
https://medium.com/user-experience-design-1/the-anatomy-of-a-credit-card-payment-form-32ec0e5708bb
http://baymard.com/blog/payment-method-selection

12. Form field: Card number
Facts:
• Card brands have different number formats (IIN). First
numbers include: 4 (Visa), 34/37 (Amex), 51-55 (Mastercard)
- These numbers are an international standard and cannot
change.
• Cards numbers can be instantly validated using IIN
• Cards can have varying amounts of numbers (Visa =
13,16,18,19) but never more than 20
• Card numbers have spaces between them and can
contain hyphens
• Enforcing spaces can cause users to attempt to delete them
Source
http://www.dirigodev.com/blog/ecommerce/anatomy-of-a-credit-card-number/
http://www.stevemorse.org/ssn/cc.html
http://designmodo.com/ux-credit-card-payment-form/

13. Form field: Name on card
Facts:
• Names can contain characters
• The name must match the card so the label should be:
‘Name on card’
Source
https://medium.com/user-experience-design-1/the-anatomy-of-a-credit-card-payment-form-32ec0e5708bb
http://designmodo.com/ux-credit-card-payment-form/

14. Form field: Expiry date
Facts:
• “Format Field For Expiration Date Exactly As It Appears On
Credit Card“
• Select menu of MM YY (01, 02, 03... 15, 16, 17...)
• No names for months (Jan, Feb...) no 4 number years
(2015)... let’s not make our users have to do calculations
Source
http://www.smashingmagazine.com/2011/04/fundamental-guidelines-of-e-commerce-checkout-design/
http://baymard.com/blog/how-to-format-expiration-date-fields

15. Form field: Security code
Facts:
• Amex cards have 4 numbers, All other cards have 3
• The code can only be numbers (no spaces or characters)
• The code has non-standardized naming convention:
• MasterCard — card validation code (“CVC2”)
• Visa — card verification value (“CVV2”)
• Discover — card identification number (“CID”)
• American Express — “CID” or “unique card code”
• Debit Card — “CSC” or “card security code”
• And there are even more permutations:
• Card verification data
• Card verification number
• Card verification code
• Card code verification
Source
https://medium.com/user-experience-design-1/the-anatomy-of-a-credit-card-payment-form-32ec0e5708bb

16. Summary
Be aware of all of the varying international formats and
conventions of information you are asking for
Over-zealous validation and restricted select options can
easily exclude your users and block completion
...especially if the field is mandatory.
Reduce the question set as much as possible and consider
mandatory vs optional