Re: [webpayments] Abstract payment architecture (#11)

@ianbjacobs 

> I am not sure to understand why that would be the case. Can you explain in more detail?

The example that @adrianhopebailie gave states that that an issuer changes what they accept and releases a new payment app that supports this. The merchant PSP must support this also. This makes supporting this a two party solution, this dependency reduces options for innovation IMO, hence my comment.

The example I was thinking of was when the PSP independently creates an innovation. Granted the PSP can rollout a new payment method to solve this, but then this introduces other issues;

1. How can the new payment method share data with an old payment method? (covered in issue #15)
or
2. How can the Merchant PSP dynamically register this new payment method? (covered by issue #14 )

Whilst these are covered somewhat under other issues, my specific proposal in this  architectural issue is that the architecture should support some sort of pipelining.

To support the use case I mention, it could be very basic such that the payment request could specify some preprocessing to be performed prior to sending the payment details to the merchant.

How this might be handled is very different between the two current proposals on the table. This is principally because the CG proposal allows for interaction directly with a Merchant specified PSP/Processor who would be specifying this preprocessing, whereas I don't believe the Google/Microsoft proposal allows for this (at least not on my last reading)

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments/issues/11#issuecomment-163942113