Re: [w3c/payment-handler] Payment Instrument architecture clarification (#381)

Hi all, 

Let me explain the question from more accurate point of view.

Let me introduce you a diagram of current behavior of BobPay: 
![BobPay](https://user-images.githubusercontent.com/71703038/101903225-a0a52500-3bbc-11eb-8819-d4fa5880342e.jpg)
Let me explain main points and problems of this approach (on my point of view).
The main problem is that Bob Pay and Basic Card payment instruments are handled on BobPay Payment Web App service worker. But I assume, It is, maybe, because basic-card is build in instrument.

Let me introduce you the architecture which seems to be logic (on my point of view).
![CustomPay (1)](https://user-images.githubusercontent.com/71703038/101903519-13ae9b80-3bbd-11eb-81f2-cfdf55fccca2.jpg)
There we have a CustomPay payment web app which includes NewPay and CustomCredit payment instruments. The main point is, that when user select NewPay (add needed data, or whatever) we send data to CustomPay service-wroker but than send request\message to NewPay service-worker in order to proceed with needed logic. After response from NewPay serice-worker, CustomPay serice-worker finalize payment or do whatever else. In this case, we assume that CustomPay service-worker it is a Web Server which interacts with 3rd parties.

**Question:** How to achieve this behavior or its analog in Payment Handler ? Is it possible?  

Best,
Roman.

-- 
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-handler/issues/381#issuecomment-743167630