Re: [w3c/webpayments] European market - Security concerns (#210)

> 1- We have only two technical solutions to provide payments : payment page redirection & Iframe.
> Currently, the specification does not allow any of these solutions, which raise our concerns about its adoption . We cannot ask our customer to migrate to a non PCI compliant solution.

> Does the specification intend to support existing payment solutions that follow PCI DSS rules ?

This is not true. As a PSP you can still provide your merchants with code that embeds an iframe, the content of which is hosted on your secure (and PCI DSS certified) web servers.

The Merchant can explicitly give that iframe permission to call the Payment Request API so when the user wants to pay the interaction is done directly with your systems.

For the redirect use case, nothing stops you from invoking the API when the user has been redirected to the payment page hosted on your secure servers.

> 2- Pay Apps are great piece of the specification, but they raise several issues
> - Payee may have his favourite Pay Apps. Is the PSP supposed to deal with all these Payment Apps and handle their own payment message structure (Android Pay sends token, Basic Card sends clear data, Maybe some app will send encrypted data) ?

A PSP does not need to have any knowledge of payment apps, only payment methods. Each payment method defines its own message structure and to support a payment method the PSP must be able to generate a request and handle a response from the API that conforms to the structure defined by that payment method.

The payment app that the payee uses is not even known to the PSP.

> - Regarding PCI DSS, every system where critical data transits must be certified PCI DSS in order to be compliant. Will the browser (Mediator) be certified, knowing that critical data can be stolen from a browser in a corrupted computer?

Since browsers already handle this when they provide the ability to auto-fill card forms I must assume they already meet all the requirements.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:

Received on Wednesday, 8 February 2017 09:03:58 UTC