Can we align response data names with Basic Card response data?

[ianbjacobs]

Here are the Basic Card response [1] fields (first) and the current corresponding SRC response names (second):

• cardholderName v. consumerFirstName and consumerLastName
• cardNumber v. accountNumber
• expiryMonth v. expirationMonth
• expiryYear v. expirationYear
• cardSecurityCode v. dynamicData
• billingAddress v. no corresponding field.

It would be great to align at least the first four. Also, do we need billingAddress for SRC?

[1] https://w3c.github.io/payment-method-basic-card/#basiccardresponse-dictionary

[tblachowicz]

As per SRC API specification [1] the payload containing payment credentials such as listed in the question above is encrypted for the recipient. Therefore, I doubt SRC payment method specification should explicitly define the payload members as Basic Card does.

To me, SRC Card Response dictionary should contain a subset of data received as a response form Checkout API. It is necessary to define the exact shape of the set of data, but among them, there should be encryptedPayload member containing actual credentials such as a token, dynamic data and so on.

[1] https://www.emvco.com/terms-of-use/?u=/wp-content/uploads/documents/EMVCo-Secure-Remote-Commerce-Specifications-API-1.0.pdf

[tblachowicz]

For the sake of clarity below is the content of encrypted payload containing payment credentials:

1. Card or token data depending on whether the credentials represent regular PAN or tokenized card;
2. Dynamic data i.e. application cryptogram of another form;
3. Shipping address as selected by the consumer;
4. Consumer details (name, email, phone number);
5. Output data related to tokenization;
6. Output data related to 3DS;
7. Billing address.

The Card dictionary contains:

• primaryAccountNumber
• panExpirationMonth
• panExpirationYear
• cardSecurityCode
• cardholderFirstname
• cardholderLastname
• cardholderFullName
• billingAddress
• paymentAccountReference

The PaymentToken dictionary contains:

• paymentToken
• tokenExpirationMonth
• tokenExpirationYear
• paymentAccountReference

Note, that both W3C Payment Request and SRC System can provide a shipping address and consumer details (name, e-mail and phone number) to the DPA/Merchant. To me, this overlap of functionality should be tabled as a subject for further discussion.

[ianbjacobs]

@tblachowicz what would you think of this in the payment method response data:

• paymentDetails ::= ...encrypted blob not specified in the payment method definition...
• paymentDetailsType ::= card | paymentToken | tokenReference

Ian

[tblachowicz]

Related to my note on shipping addresses and consumer details: w3c/payment-handler#337