Upgrade Your Payment Form

What's wrong with existing credit card forms?

Mistakes and Solutions

• Using Basic Text Input for Card Number

  • Regular text inputs don't prevent many errors that occur during the clumsy process of entering credit card numbers. While glancing from credit card to keyboard to screen, it's easy to lose position in a long string of numbers, drop digits, and add additional characters.
  • Example:
  • Text inputs also allow illegal characters like letters, requiring delayed validation to warn users instead of just ignoring these characters. The same validation usually also flag characters like spaces or hyphens that some users type between groups of digits.

• Smart Card Number Input

  • Card Number Security Code ? Name on Card

    Expiration

    MMYY

    American ExpressDiscoverMasterCardVisaDiners ClubJCB
  • Creditcard.js helps users quickly spot mistakes and also automatically corrects certain errors with the following techniques:
  • Automatically splits number to match format on card, e.g. '42424242' -> '42424242'. This splitting logic adapters to the card type, e.g. Visa numbers are split after every fourth digit.
  • Restricts input to numbers, spaces, and hyphens. Spaces and hyphens are only allowed at split locations.
  • Limits maximum number of digits (varies with card type) so accidentally duplicate digits are quickly noticed.
  • Catches many typos by calculating the Luhn checksum.

• Misleading Card Type Detection UI

  • The example below attempts to improve usability by automatically detecting the card type, but the UI increases confusion. The card type icons look like buttons, but they are unclickable. Users must first enter their card number before the detected card type is selected with JavaScript. The card type icons likely attract confused and frustrated clicks.
  • Screenshot of initial payment form
  • Screenshot after card type detected

• Clear Card Type Detection

  Card Number Security Code ? Name on Card

  Expiration

  MMYY

  American ExpressDiscoverMasterCardVisaDiners ClubJCB

  American Express
  • Creditcard.js reveals the card type only after its detected. It displays the card type with clear, legible text instead of small images. If users enter an unsupported card, e.g. China UnionPay, a warning is shown in the card type location.

• Expiration Format Mismatch

  • Many payment forms force the user to convert the expiration date from format on the card (MM/YY) to an arbitrary format: spelled-out month (e.g. January), abbreviated spelled-out month (e.g. Jan), numeric month (e.g. 01 or 1), 4 digit year, etc.
  • This mental translation adds another opportunity for errors, e.g. mixing up the number to month name mapping, swapping month and year, etc. These problems are worse for customers used to different date orderings or non-native English speakers.
  • Expiration Date Format Variations
  • January2013
  • 12013
  • 1 - January2013
  • Jan13

• Matching Expiration Format

  Card Number Security Code ? Name on Card

  Expiration

  MM010203040506070809101112YY1415161718192021222324
  • Creditcard.js's expiration date format matches the card's. The form fields are located near the actual location of these values on credit cards. For a detailed analysis, please read Baymard Institute's overview of expiration date usability.

• Text Input for Expiration

  • Using a text input instead of a drop-down/select element adds room for error and complexity. A text input allows illegal values (e.g. '33' for month, non-digit characters) and unexpected formats (e.g. '1' for January instead of '01', 4 digit years instead of 2 digit). These values must be sanitized or generate warnings, which increases code complexity and opportunities for user and programmer error. Interacting with inputs with JavaScript is notoriously error-prone and should only be tolerated when text inputs are the only suitable entry type, e.g. for card numbers.
  • Example

• Drop-down for Expiration

  Card Number Security Code ? Name on Card

  Expiration

  MM010203040506070809101112YY1415161718192021222324
  • Drop downs eliminate entire classes of errors by presenting only valid options. The only logical error that requires JavaScript to detect is expired dates. By using regular HTML drop downs, Creditcard.js gains many usability benefits for free such as big, touch friendly selection popups on mobile and keyboard navigation on non-mobile devices.

• Missing Card Security Code Diagrams

  • It's easy to assume customers no longer need help locating the card security code, but there are still many reasons to diagram the location of this value.
  • Many merchants accept but don't validate security code, leading some customers to mistakenly use one the other three digits codes unhelpfully printed on their cards. For example, American Express cards sometimes unhelpfully contain random three digit codes.
  • Security code has many naming variations (CVC, CSC, CVV, CVV2, CVD, CVVC, CVC2, CCV, SPC, CID), and customers understandably may be confused by the chosen variant.

• Clear Security Code Diagram

  Card Number Security Code

  Signature and digits from card #

  123

  On most cards, the 3-digit security code is on the back, to the right of the signature.

  ×

  XXXX XXXXXX XXXXX

  On American Express cards, the 4-digit security code is on the front, to the top-right of the card number.

  1234

  ×

  ? Name on Card

  Expiration

  MMYY

  American ExpressDiscoverMasterCardVisaDiners ClubJCB
  • Creditcard.js provides big, clear diagrams pinpointing the csc location. When the card type is detected, only the appropriate diagram is shown. These diagrams are just HTML and CSS, so they don't require additional images to load and scale seamlessly on zoom.

• Technical and JavaScript Mistakes

• Listening to the Wrong Events

  • Many JavaScript tutorials recommend the unreliable keyup/keydown/keypress events to detect user input instead of the more reliable HTML5 oninput event. Unfortunately, libraries like jQuery don't provide fallbacks for browsers that don't support oninput, so developers are left with proxy key events that misfire in following situations: when the user copies and pastes text, inputs text on mobile devices with physical keypads, uses voice assistance, etc.
  • Another incomplete alternative to detecting user input is listening to the change event. This event only fires after an input element loses focus, preventing form sanitation like immediately preventing non-numeric characters from the card number input.

• HTML5 input event

  • Creditcard.js reliably detects user input by listening to the HTML5 input event with fallbacks provided by Google's Closure Library. On browsers that don't support oninput, these fallbacks mimic oninput by listening to proxy key, paste, and change events while periodically polling for changes.
  • As a monolithic library, jQuery doesn't include a similar oninput fallback/shim because it avoids bloating file size for a feature that is not "universally needed". Google Closure has the luxury of assembling a comprehensive standard library, relying on its advanced compilation process to remove swathes of unused code during deployment.

• Incorrectly Finding Input Value

  • The keyCode, charCode, and 'which' properties on JavaScript events are often incorrectly used to determine which character the user typed, e.g. when filtering out non-numeric characters in the card number field. Unfortunately, these properties do not consistently reflect what the user is typing:
  • In certain browsers, keys typed on a numeric keypad generate different event properties than those typed on the top row of a regular keyboard.
  • Keycodes tend to reflect physical location on the keyboard instead of underlying character, which becomes problematic for non-Qwerty keyboards layouts.
  • On some mobile browsers, the keycode is erroneously fixed to 0.

• HTMLInputElement value property

  • The current value of the user's input can be accessed directly in JavaScript, bypassing the red herring of keyboard input handling.
  • Example code:
    document.querySelector('input').value;
  • The value property is older than most browsers and tends to be overlooked when JavaScript key events are used. Combined with the HTML5 input event, the value property provides simple and robust access to the user's input.

• Incorrect Card Type Detection

  • Most tutorials and resources on card type detection consist of regexes with no citations, so it's unsurprising that the process is filled with an accumulation of mistakes:

  • Missing Card Types

    Some resources omit detection for popular and unpopular card types like Discover and JCB.

  • Missing recent business developments

    Card type detection changes over time as credit card companies form partnerships or allocate new ranges of card numbers.

• Accurate Card Type Detection

  • Creditcard.js's card type algorithm detect all card companies. Sources for card number to card company mappings:
  • ANSI maintains a database mapping card number ranges to companies.
  • ANSI only shares to this information with credit card companies.
  • The most comprehensive secondary sources are the Wikipedia pages on bank card numbers and issuer identification numbers.
  • Technical aside
  • Regexes are a poor choice for representing numeric ranges. For example, here is the regex from the jQuery Credit Card Validator used to recognize Discover cards: /^(6011|622(12[6-9]|1[3-9][0-9]|[2-8][0-9]{2}|9[0-1][0-9]|92[0-5]|64[4-9])|65)/.
  • Instead of regexes, Creditcard.js use a data structure designed for number ranges. Thanks to the Google Closure compiler, this additional code adds less than 0.5 KB to the output size.

• Improve the usability of your payment form.