Encryption

See the Payment Method Encryption Specification.

This is a proposal for a mechanism to encrypt payment method response data for any payment method. End-to-end encryption from payment handler to processor can help address several use cases:

• Encryption of "raw card data" leaving the browser can lower PCI-DSS assessment burden (for card payments).
• Encryption of "tokenized card data" can reduce the risk that tokenized card information is misused.
• Encryption of payment handler data can protect against man-in-the-browser (MITB) attacks.

High-Level Proposal

• The party that calls Payment Request API (whether the merchant or their processor) provides a public key to be used by the payment handler to encrypt the entire response.
• Only the party who has the corresponding private key (e.g. the gateway) can decrypt the response.
• Each payment method defines which response fields are not sensitive. Those fields are returned in the response along with the encryption of the full response.

Additional Considerations

• Q. Do we need just one encryption, or might we need to encrypt for multiple parties?
• The data model described above has been conceived to enable experimentation with these ideas without requiring changes to the Payment request API or Payment Handler API specifications.
• Encryption could be done either within a payment handler or by the mediator.
• If the mediator were to take responsibility for the encryption, only the embedded data object would need passing to the payment handler. The payment handler could remain unchanged. However it should be noted that, at least for initial PoC, this is not required and the payment handler should deal with the encryption. This could then be generalized with the creation of standard libraries to aide implementation.
• This is not a proposal to replace TLS encryption or other transport encryption which occurs from the browser to the merchant and from the browser to the payment handler.

FAQ

Why is TLS not sufficient?

This specification allows encryption between the payment handler and the payment service provider, in general neither of these parties are at the end of the TLS connection which connects the Browser to the Merchant/Payee. The longer encryption tunnel enables, primarily, the merchant to avoid seeing sensitive data. For example, in the case of card payments, this reduces PCI certification burden.