Request: designated receiver for Payment Response

[rektide]

Hello. I recently went looking for a way to accept payments (donations) on my site via the Payment Request API.

PSPs and iframes

Alas most of the PSP's I found with Payment Request support provided some wrapper component that I had to use, typically creating an iframe and issuing the Payment Request from within the iframe. For example, Braintree's implementation does exactly this.

The downside is that I never get to see the Payment Request API. So I don't have the flexible, interesting new web API that I've been excited for & yearning to use. I'm reliant upon a more limited set of capabilities that Braintree gives me. There's no address updated capability, for example- I don't get updating orders or other things. The very important upside of this approach is that I do not need PCI DSS or SAQ A-EP compliance, which entails a (rather-exhausting) 12 point set of requirements on your online systems & software development lifecycle. I don't need it because I never have to see the PaymentResponse information, which includes the credit card number- Braintree's iframe asks for it, and the security compliance is all on them.

But this state of affairs means many many people wanting to accept payments will been ineligible to use the Payment Request API, because they do not want to have to make it through PCI compliance.

Designating A Payment Reciever

I would like to see the spec be able to designate a recipient for the PaymentResponse. Rather than have the page directly read the PaymentResponse (which will often contain information like credit cards), there ought to be some means to designate who to send the payment response to. This designatee would run the PaymentResponse, and return data to the user-agent that would then become the a new details to the original PaymentRequest.

PayeeInstruments

There's a lot of flexibility and possibilities for how this kind of setup might be created. A lot of the work in Payment Handler would, in my opinion, serve as a good template.

As a merchant, the ideal situation that I would imagine would be to provide a list of payment receiver URL's in my PaymentRequest.

As a payment gateway, I'd want to be able to have a ServiceWorker that registers a set of new PayeeInstruments, declaring what supportedMethods this service-worker supports. If my page is designated by a PaymentRequest, and my ServiceWorker has registered a matching PayeeInstrument for the request, the original PaymentResponse is sent to my service worker. I thereby process the payment, and return a new object with success or failure and the details that will be visible to the page that designated me as the payment receiever.

In this way, as a merchant I can designate who to send the critical credit card or other data to, I can permit that person to run the card, and return me the final status of that payment. This way, there is no PCI sensitive data that I ever see.

Conclusion

By doing this, I believe many many more folks will have the possibility of getting to interact with & use the Payment Request API. There are many users for whom PCI DSS or SAQ A-EF compliance is a hard burden- myself included- but who still want to be able to receive payments online. There are options out there for users like me, but they involve walking away from directly consuming Payment Request & using a more limited, less user-empowering component provided directly via my payment gateway. I would like it if the Payment Request API had the capability to plug my payment gateway into my Payment Request, such that I could remain out of the loop, and thus free from the PCI compliance burdens. I further believe that following the ideas of Payment Handlers provides a good example form for implementing this system.

[cyberphone]

There are many users for whom PCI DSS or SAQ A-EF compliance is a hard burden- myself included- but who still want to be able to receive payments online

I believe encrypted payment cards would serve this purpose.

As a payment gateway, I'd want to be able to have a ServiceWorker that registers a set of new PayeeInstruments, declaring what supportedMethods this service-worker supports

This doesn't sound right, payment gateways are usually only middlemen, not involved in issuing user-related data like payment instruments and such.

[ianbjacobs]

@rektide,

We have two areas of work that may help regarding PCI-DSS: Encryption [1] and Network Tokenization [2]. They are both still in development.

Ian

[1] https://github.com/w3c/webpayments-methods-tokenization/wiki/Generalisation-of-Encrypted-Card
[2] https://github.com/w3c/webpayments-methods-tokenization/wiki/Tokenized-Card

[rsolomakhin]

You can also use tokenization through such payment methods as Android Pay, for example.

[rektide]

Thanks for the replies. I'm going to leave this issue open for a day or two while I process this information. At first blush these seem reasonable.

@ianbjacobs To be clear, it's capitally important to me to make it well beyond PCI-DSS. Even looking at much laxer SAQ A-EP (sorry I typo'd A-EF in my original post), there's still a huge amount of change-control & systems-modelling that PCI SAQ A-EP demands that is very very cumbersome & incompatible with modern software development. I'm going to try to understand these proposals in this context. I am however far from an expert here- I'm a dabbler that thought finally I could do payments & found out the hard way there was a lot to go- & it'd be great if others closer to this area might sounds off with their thoughts on webpayments-methods-tokenization and what PCI if any compliance it requires & why.

[michelle]

It's probably also reasonable to file a feature request for Braintree's integration to expose more of the underlying APIs! Stripe's clientside library, for example, give you access to the underlying Payment Request callbacks.

(I work at Stripe on the team that works on our Payment Request integration.)

[marcoscaceres]

@rektide can we close this?

[marcoscaceres]

closing. Let me know if I should reopen.