Guideline: Use a form filling sequence that prompts the caller to provide one piece of unambiguous information at a time. Confirm this information after each piece of information is provided.

Discussion: Generally speaking, four types of information are required for credit card processing:

• Credit Card Type: Algorithms exist for determining the credit card type by the number entered. For this reason, it is best not to ask callers for their credit card type. Rather, confirm the type when confirming the number. Example:
  • System: “Visa Card Number 123-456-789. Is that right?”

Credit Card Number: Card numbers can be either spoken or entered via DTMF. Both input modalities should be permitted. In either case, because of the criticality of data, always confirm what was entered.

• Credit Card Expiration Date: The same guidance for entered credit card number applies to the expiration date. The format for the entry, however, should be localized to the expected user population. For example: in the United States, the accepted date reporting format is mm/dd/yyyy. In other countries, however, it may be accepted as dd/mm/yyyy (where the day is optional). If the possibility of date reporting format errors exists, it is best to provide an example of the format expected of the caller. Example:
  
  • System: “Enter your credit card expiration date. For example, if the date on your card is 09/14, then you would enter nine, one, four.”

(Note that the grammar should also accept entry of 0 9 1 4 in case the caller begins responding before the example plays. Optionally, the grammar could accept spoken inputs such as “September two thousand fourteen”, but callers are most likely to say what they see on the card rather than performing the mental translation to month and year – something that many websites haven't figured out.)

• Credit Card Security Code: Typically the last three digits printed on the signature strip on the back of the card, or, in the case of American Express cards, a group of four digits on the front towards the right. Entry of this number may be spoken or entered via DTMF.

Confirmation: The collection of credit card information is a high cost transaction. That is, the cost of error is high in terms of getting this information wrong; a payment may not be processed. For this reason, we recommend always confirming all credit card information provided by the caller. Confirm this information after each piece of information is provided as opposed to soliciting a summary confirmation of all information collected.

Note that for testing purposes, the number 4111-1111-1111-1111 will work for Visa card number inputs. Also, see: <https://support.cybersource.com/cybskb/index?page=content&id=C5&actp=LIST_POPULAR>.

The algorithms mentioned below usually include a checksum. You have more design flexibility if the checksum occurs outside the grammar. For example, accept 16 digits, then run against the checksum. It allows you to message differently for each failure point. Rather than telling the caller it's invalid or not the right format when checksum fails, consider using a simple retry prompt, “I don't think I got that right. Please say or enter your credit card number.” “Invalid” really tells them nothing, and the chances are high it failed checksum due to a recognition error or fat finger issue. “Invalid” starts to make people panic about their account.