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

Hi @RomanKaliupin,

I am not sure to fully understand the requirements yet, but I appreciate your diagram and commands. I'll try to be helpful.

I think the following is true:

 * The Chrome implementation of Payment Handler API shows one name/logo pair per payment handler. This name/logo pair might be a payment app (e.g., "Google Pay") or it might be a payment instrument (e.g., "Visa *****4567"). 

 * If you wish for a name/icon to be shown in the browser's "sheet" (the selector of shipping address, contact information, and payment handlers), then you should create a payment handler for that name/icon. So if you want the user to see an instrument, you should create a payment handler just for that instrument.

 * For "add an instrument" you could thus create one payment handler with the appropriate name/icon. That payment handler's job would be to enroll new instruments.

 * If you redirect the user (in the "add" payment handler) to your origin (e.g., pay.com), then you can install a new payment handler for the newly added instrument. The job of that specific payment handler is to fulfill payments with that instrument.

 * The next time the user goes through payment request, the user will see that payment handler (for that specific instrument) in addition to the "add an instrument" payment handler.

Is that what you would like to do?

Ian

-- 
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-744680683