This specification describes data structures and formats, and a simple processing model, to facilitate card-based payments on the Web. It is used by other specifications to facilitate monetary transactions with a "basic card", such as credit, debit, or prepaid card.

The working group maintains a list of all bug reports that the group has not yet addressed. Pull requests with proposed specification text for outstanding issues are strongly encouraged.

If you wish to make comments regarding this document, please raise them as GitHub issues. Only send comments by email if you are unable to raise issues on GitHub (see links below). All comments are welcome.

Introduction

This specification defines the "basic-card" payment method for use, for instance, with the Payment Request API. With it, merchants can request the card details (card holder name, card number, etc.) from the end user as an alternative to collecting the same information through a [[!HTML]] form.

The basic card payment method provides information to merchant websites that can be used for multiple transactions over a potentially very long period of time, typically on the order of several years at a time. At the time of the development of this specification, it is commonplace for merchant sites to store this information long-term to reduce the friction of a user entering a credit card number for every future purchase.

The decision whether to retain credit card information for future transactions remains a matter of local policy for web sites; however, the introduction of a programmatic way to retrieve credit card information from a web browser affects some key factors that typically motivate storage of such information.

Because the web browser will retain credit card information, and make it available – subject to user approval – whenever a merchant needs it, the friction that merchants seek to avoid is reduced. This can also potentially reduce some liability considerations of storing information on a persistent basis, such as financial liability that can result from unauthorized access to the databases used to store credit card information.

Additionally, web sites that call the Payment Request API for each transaction avoid the friction that can result when users’ credit card numbers and/or expiration dates are updated. From a user’s perspective, this avoids the hassle of having to update a large number of merchant web sites any time they are issued a new card.

Finally, by letting the web browser determine user authentication information, the merchant site is relieved of the duty of ensuring that a time-local and sufficiently strong authentication has occurred. Additionally, payment handlers can make use of local affordances, such as biometrics and hardware tokens, to authenticate users in a way that is more convenient, more secure, and lower friction than web sites currently can.

Payment Method Identifier

The standardized payment method identifier for this specification is "basic-card".

Model

This section defines concepts used in this specification, and how those concepts are represented in an API via [[!WEBIDL]].

A card is a physical or virtual payment instrument that has details, a type, and optionally is part of a network.

The details of a card are the primary account number (PAN), card holder's name, security code (sometimes known as the CVV, CVC, CVN, CVE or CID), expiry month, expiry year, and optionally a billing address. These are represented as the members of the BasicCardResponse dictionary.

A card can be of type "credit", "debit", or "prepaid", as derived from the issuer identification number (the first eight digits of the primary account number). The different types are represented as the BasicCardType enum.

A card is identified as belonging to a network via its issuer identification number [[!ISO7812-1]] (e.g., those belonging to "visa" start with a "4"). In an API, each network is represented by a string matching one of the card network identifiers [[!card-network-ids]].

A supported card is a card that when passed to the steps to check if an instrument is supported, together with a list of types and networks returns true.

A payment handler's known networks are networks it supports. A payment handler MAY support zero or more networks from the [[!card-network-ids]] list.

BasicCardRequest dictionary

      dictionary BasicCardRequest {
        sequence<DOMString> supportedNetworks;
        sequence<BasicCardType> supportedTypes;
      };
    

The BasicCardRequest dictionary contains the following members:

supportedNetworks
A sequence of identifiers for card networks that the merchant accepts. W3C maintains a list of approved card network identifiers.
supportedTypes
A sequence of card types that the merchant accepts.

Interfacing with a payment request

Steps to check if a payment can be made

The steps to check if a payment can be made by a Payment Handler that handles "basic-card" takes BasicCardRequest request as input. It returns either true or false:

  1. Let cards be a list of cards associated with this payment handler.
  2. If cards is empty, return false.
  3. Let networks be an empty DOMString sequence.
  4. Let types be an empty BasicCardType sequence.
  5. If request["supportedTypes"] is present, append each item in request["supportedTypes"] to types.
  6. If request["supportedNetworks"] is present, append each item in request["supportedNetworks"] to networks.
  7. For each card in cards:
    1. Let isSupported be the result of running the steps to check if an instrument is supported, passing in card, networks, types.
    2. If isSupported is true, then return true.
  8. Return false.

Steps to check if an instrument is supported

The steps to check if an instrument is supported takes as input a card card, a list of type types, and a list of network networks. It returns true if the card is supported, false otherwise.

  1. If types is empty and networks is empty, return true.
  2. If networks is not empty:
    1. If networks does not include the card's network, return false.
  3. If types is not empty:
    1. If types does not include the card's type, return false.
  4. Return true.

Steps to respond to a payment request

The steps to respond to a payment request are given by the following algorithm. If the end user inputs or selects a card that meets the constraints of BasicCardRequest data, the algorithm returns a card as a BasicCardResponse.

  1. Let networks be data["supportedNetworks"], or an empty list if data["supportedNetworks"] is missing.
  2. Let types be data["supportedTypes"], or an empty list if data["supportedTypes"] is missing.
  3. Let card be a BasicCardResponse.
  4. Set card["cardNumber"] to a string of digits of length between 10 to 19 items representing the primary account number.
  5. While the steps to check if an instrument is supported with card, networks, types returns false, ask the user to correct the card's details. Only when the card is a supported card, continue.
  6. Set card["cardholderName"] to the card holder's name, or the empty string if the user chooses not to provide it.
  7. Set card["cardSecurityCode"] to a three or more digit string, or the empty string if the user chooses not to provide it.
  8. Set card["expiryMonth"] to two-digit string ranging from "01" to "12", or the empty string if the user chooses not to provide it or the type doesn't require an expiry month.
  9. Set card["expiryYear"] to a four-digit string in the range "0000" to "9999", or the empty string if the user chooses not to provide it or the type doesn't require an expiry year.
  10. If a billing address is not required for this card type, then set card["billingAddress"] to null. Otherwise:
    1. Let redactList be « "phone" ».
    2. Let billingAddress be the result running the steps to create a PaymentAddress from user-provided input with redactList.
    3. Set card["billingAddress"] to billingAddress.
  11. Optionally, validate card's details to make sure they adhere to any additional type and/or network requirements and assist the user in fixing any issues encountered.

    The validation a user agent performs on the card's details is a quality of implementation detail and outside the scope of this specification. There is nevertheless an expectation that user agents will make a best effort to check that a card number is valid as per the Luhn algorithm [[!ISO7812-1]], check the length is correct for the expected type, check that the issuer identification number is correct for the selected network, check that the expiry date on the card hasn't lapsed, and so on.

  12. Return card.

BasicCardType enum

          enum BasicCardType { "credit", "debit", "prepaid" };
        
"credit"
A credit card.
"debit"
A debit card.
"prepaid"
A prepaid card.

BasicCardResponse dictionary

        dictionary BasicCardResponse {
          required DOMString cardNumber;
          DOMString cardholderName;
          DOMString cardSecurityCode;
          DOMString expiryMonth;
          DOMString expiryYear;
          PaymentAddress? billingAddress;
        };
      
cardholderName member
The card holder's name as it appears on the card.
cardNumber member
The primary account number for the card as a string of digits that ranges from 10 to 19 digits.
expiryMonth member
A two-digit string for the expiry month of the card in the range "01" to "12".
expiryYear member
A four-digit string for the expiry year of the card in the range "0000" to "9999".
cardSecurityCode member
A three or more digit string for the security code of the card.
billingAddress member
A PaymentAddress that represents the billing address associated with the card, or null.

There is only one class of product that can claim conformance to this specification: a payment handler.

A conforming payment handler MUST:

Security and Privacy Considerations

Due to differences in quality of implementation" and the end user's ability to input data into unconstrained input fields, merchants are expected to revalidate all BasicCardResponse returned by APIs that make use of this specification.

In particular, merchants need to treat the values of any details with the same scrutiny that they would apply to a [[HTML]] input element, by, for example, sanitizing all the members of a BasicCardResponse before rendering them anywhere.

Owners of web sites SHOULD NOT store the payer's card information except where warranted, such as storage for future and recurring payments. When card information is stored, web site owners SHOULD take measures to prevent its disclosure.

Depending on jurisdiction, users of this specification (implementers, merchants, payment processors, etc.) can be subject to PCI DSS or other regulations. Discussion of those considerations are outside the scope of this document.