[w3c/payment-request] Request: designated receiver for Payment Response (#660)

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](https://github.com/braintree/braintree-web/blob/master/src/payment-request/external/payment-request.js).

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`](https://www.w3.org/TR/payment-request/#details-attribute) 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](https://w3c.github.io/payment-handler/#dom-paymentinstrument) 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`](https://www.w3.org/TR/payment-request/#details-attribute) 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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/payment-request/issues/660