From 78c274e822beef790bfd64ec1ecdf98948e12b67 Mon Sep 17 00:00:00 2001 From: Ian Jacobs Date: Thu, 27 Apr 2017 02:54:12 -0500 Subject: [PATCH 1/4] =?UTF-8?q?=CB=9C=20moved=20from=20pmi=20spec?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- proposals/method-practice/index.html | 33 ++++++++++++++++++++++++++-- 1 file changed, 31 insertions(+), 2 deletions(-) diff --git a/proposals/method-practice/index.html b/proposals/method-practice/index.html index 86a1daf..7526c81 100644 --- a/proposals/method-practice/index.html +++ b/proposals/method-practice/index.html @@ -172,13 +172,42 @@

Structure of a Payment Method Specification

  • Information that parties must provide as input to the payment request API that is specific to the payment method (and not general information about the transaction). This is done via the data parameter of the PaymentRequest constructor.
  • Information that will be in the response from the payment request API. This will typically be information collected from the user (e.g., card number for card payments) through user interface displayed by the browser.
  • Any other payment method-specific requirements that are not addressed by the underlying payment request API, and that developers of payment apps need to take into account when building support for the payment method. See the next section for some payment method specific considerations.
    • -
  • Recommended behavior to handle exceptions (e.g., in case of network failures)
    • - +
  • Recommended behavior to handle exceptions (e.g., in case of network failures)
    • + + +

    Payment Method Specific Considerations

    +
    +

    + Conditional Matching Beyond Payment Method Identifier Matching +

    +

    + For some payment methods, merchants may wish to express that they + accept a payment method but only under certain conditions (e.g., "I + only credit cards from brand A and debit cards from brand B"). The Web + Payments Working Group has discussed several ways to support more + sophisticated matching beyond initial payment method identifier + matching. +

    +
      +
    • Parties may mint payment method identifiers to represent different + conditions. This scalable approach may work well for a small number of + independent conditions, but may not scale well for complex + relationships. +
      • +
    • A payment method can define "filters" that enable callers of the + API to describe in finer detail the conditions under which they accept + that payment method. User agents and third party payment apps can + similarly scope their support for that payment method with these + filters. In this scenario, a match between payee and payer depends + first on matching payment method identifiers, then on filter alignment. +
      • +
    +

    User Experience

    For some payment methods that require a variety of From 15c7cbea987f5c943ba13e35a681e8d50abb2445 Mon Sep 17 00:00:00 2001 From: Ian Jacobs Date: Thu, 11 May 2017 12:45:47 -0500 Subject: [PATCH 2/4] Moved --- proposals/tokenized_cards.html | 194 +-------------------------------- 1 file changed, 1 insertion(+), 193 deletions(-) diff --git a/proposals/tokenized_cards.html b/proposals/tokenized_cards.html index 2a8591f..386b2ea 100644 --- a/proposals/tokenized_cards.html +++ b/proposals/tokenized_cards.html @@ -65,199 +65,7 @@

    -

    - The Tokenized Card Payment specification describes the data formats used by the - PaymentRequest API [[!PAYMENTREQUESTAPI]] to support payment by tokenized payment cards. -

    -
    - -
    -

    - 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. -

    -
    -

    Sending comments on this document

    -

    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 is a Payment Transaction Message Specification used by the PaymentRequest API - [[!PAYMENTREQUESTAPI]] to support payment by tokenized payment cards.

    - -

    Tokenization provides some advantages over traditional card payments - tokenized credentials are often narrowly scoped, for example single-use or merchant/amount/time scoped. Tokenized credentials also help alleviate some concerns about merchant data breaches since the merchant does not have the raw PAN. This provides some additional security for a consumer. -

    -
    - -
    -

    Dependencies

    -

    - This specification relies on several other underlying specifications. -

    -
    -
    Basic Card Payment
    -
    The term BasicCardResponse is defined by the Basic Card Payment specification [[!BASICCARD]].
    -
    Payment Request API
    -
    The term PaymentRequest constructor is defined by the PaymentRequest API - specification [[!PAYMENTREQUESTAPI]].
    -
    Payment Method Identifiers
    -
    The term Payment - Method Identifier is defined by the Payment Method Identifiers specification - [[!METHODIDENTIFIERS]].
    -
    Web IDL
    -
    The IDL in this specification is defined by Web IDL [[!WEBIDL]].
    -
    -
    - -
    -

    Payment Method Identifier

    -

    The payment method identifier string for the Tokenized Card Payment method is card-token.

    -
    - -
    -

    Payment Method Specific Data for the PaymentRequest constructor

    -

    This section describes payment method specific data that is supplied as part of the data - argument to the PaymentRequest constructor. This specification extends the BasicCardRequest (defined in [[!BASICCARD]]) with some additional fields required for tokenization.

    -
    -

    TokenCardRequest

    - 
    -        enum TokenCardType { "emv", "issuer" };
-
-        dictionary TokenCardRequest : BasicCardRequest {
-          sequence<TokenCardType> supportedTokenTypes;
-        };
-
    - -

    - The TokenCardRequest dictionary contains the following fields: -

    - -
    -
    supportedTokenTypes
    -
    The supportedTokenTypes field contains a sequence of token card types that the merchant - accepts. The values mean the following: -
      -
    • "emv": These are tokens (typically single-use) provided by card networks (cf. supportedNetworks) that represent the underlying PAN.
      • -
    • "issuer": With these tokens, a provider serves as a card issuer by generating a new card number. This new card number is backed by the original PAN or by another funding source. During charging of these tokens, the provider translates the generated card number back into the original PAN or original funding source.
      • -
    -
    -

    A payment service may wish to use emv tokens if its infrastructure supports sending a token/cryptogram combination. Issuer tokens may be preferred in cases where the card is not emv-tokenizable or if the merchant is unable to handle emv tokens.

    - -

    The supportedNetworks and supportedTypes fields are both optional. - If neither is provided then any card may be returned. If supportedNetworks - is provided then any card that matches one of the supported networks is returned. - If supportedTypes is provided then any card that matches one of the supported types is returned.

    - -

    Implementations will determine how to match values of supportedTypes.

    - -

    - This specification covers a limited number of supportedTokens. There are other types of tokens such as gateway tokens, but because they involve substantially different flows of information (e.g., merchant onboarding), this specification does not cover them.

    -
    -
    - -
    -

    Payment Method Response

    -

    - The TokenizedCardResponse dictionary contains the response from the PaymentRequest API when a user accepts payment with a Tokenized Payment Card payment method. This specification extends the BasicCardResponse (defined in [[!BASICCARD]]) with some additional fields required for tokenization. It should be noted that the "cardSecurityCode" from the BasicCardResponse will contain a card security code for issuer-based tokens, but will contain the cryptogram for network tokens. The combination of cardNumber (the token number) + cardSecurityCode (either cryptogram or security code - note that security code can be 3 or 4 digits) establishes a one-time use credential. -

    - - 
    -        dictionary TokenizedCardResponse: BasicCardResponse {
-            required DOMString          cardLast4;
-            DOMString          tokenType;
-            DOMString        tokenRequesterId;
-        };
-
    - -

    - The TokenizedCardResponse dictionary contains the following fields: -

    - -
    -
    cardLast4
    -
    The cardLast4 field contains the last 4 digits of the original (non-token) primary account number (PAN) for the payment card. This may be used for display purposes during the purchase.
    -
    tokenType
    -
    The tokenType field contains the token type selected by the user. This is one of the values of supportedTypes.
    -
    tokenRequesterId
    -
    The tokenRequesterId field contains ID of the entity that requested the token from the network (likely the creator of the payment app). This field is only applicable when tokenType is "emv".
    -
    -
    - -
    -

    Example request/responses

    - -
    -

    emv Request/Response

    - -
    - -
    -

    issuer Request/Response

    - -
    -
    - - - - - - -
    -

    Appendix: Flow Diagrams

    - -
    -

    Issuer Token Flow

    -

    issuer token flow

    -
    - -
    -

    Network Token Flow

    -

    network token flow

    -
    +

    Moved to new repo.

    From 933eb2ecad3baba8aea274abf68684d29ea52d1e Mon Sep 17 00:00:00 2001 From: Ian Jacobs Date: Thu, 8 Jun 2017 10:03:00 -0500 Subject: [PATCH 3/4] add bit about validation --- proposals/method-practice/index.html | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/proposals/method-practice/index.html b/proposals/method-practice/index.html index 7526c81..b555be0 100644 --- a/proposals/method-practice/index.html +++ b/proposals/method-practice/index.html @@ -221,6 +221,17 @@

    User Experience

    +
    +

    + Validation +

    +

    To ensure the best user experience, browsers and other implementations of Payment Request API may perform validation on a payment method's request data. The Web Payments Working Group has the following expectation:

    +
      +
    • For payment methods identified by URL, browsers will treat payment request data as opaque data and not perform validation.
      • +
    • For payment methods defined by W3C (and identified with short strings), browsers may validate data according to the normative statements of the payment method specification. This includes both WebIDL requirements (e.g., enum values) and normative statements in prose (e.g., relationships among fields).
      • +
        +
    +

    Security and Privacy

    @@ -281,7 +292,7 @@

    Failures and Reconciliation

    -

    Versioning

    +

    Versioning

    We anticipate that payment methods will change over time. The Working Group anticipates that the ecosystem will use different payment method identifiers to distinguish versions. A merchant that accepts multiple versions of a payment method can supply multiple identifiers.

    From a612f48a5afa59e9e56b7ee38caf7ed401f4f2fa Mon Sep 17 00:00:00 2001 From: Ian Jacobs Date: Mon, 17 Jul 2017 09:24:36 -0500 Subject: [PATCH 4/4] added security statement re: merchantId --- proposals/method-practice/index.html | 2 ++ 1 file changed, 2 insertions(+) diff --git a/proposals/method-practice/index.html b/proposals/method-practice/index.html index b555be0..1c5093d 100644 --- a/proposals/method-practice/index.html +++ b/proposals/method-practice/index.html @@ -267,6 +267,8 @@

    Payee Identity

    }], shoppingCart).show(); +

    For security reasons, merchant IDs should not be the + merchant's acquirer bank merchant ID number.