Open ianbjacobs opened 5 years ago
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.
For the sake of clarity below is the content of encrypted payload containing payment credentials:
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.
@tblachowicz what would you think of this in the payment method response data:
Ian
Related to my note on shipping addresses and consumer details: https://github.com/w3c/payment-handler/issues/337
Here are the Basic Card response [1] fields (first) and the current corresponding SRC response names (second):
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