Layering is good idea in general. It would be great if virtual goods that
do not require shipping could be bought using a simpler API.
However, in current proposed form, your API would not work with a UI that
has a dropdown for shipping method. I envision this UI to update the total
price estimate based on the shipping method selection. Selecting a
different address might update the price as well based on distance or state
tax. This logic lives on merchant website or comes from their payment
processor. (See Adrian Bateman's example below.)
[image: Screenshot from 2016-02-09 13:15:39.png]
On Wed, Feb 3, 2016 at 6:23 PM Dave Longley <dlongley@digitalbazaar.com>
wrote:
> Hi all,
>
> I've put together a very rough, preliminary proposal for what I've
> called a "Checkout API". This API is really just a set of potential
> changes that could be made to the Payment Request API -- but is done so
> with the realization that the two "competing" browser API proposals are
> actually aimed at solving two different problems at two different layers.
>
> I believe that the Web Payments Browser API [1] aims to be a very
> low-level API with a specific focus on getting the user to pick a
> Payment App and complete a payment. The Payment Request API [2] aims to
> help streamline a more involved checkout process -- and can therefore
> add more *on top of* the lower-level API.
>
> My thoughts on this approach can be found here:
>
> https://github.com/w3c/webpayments/wiki/Checkout-API
>
> We may find that "merging" the competing specs isn't necessary, but
> rather, we could produce two different outputs that rely upon one
> another but operate at different layers.
>
> 1. http://wicg.github.io/web-payments-browser-api/
> 2. http://wicg.github.io/paymentrequest/specs/paymentrequest.html
>
> --
> Dave Longley
> CTO
> Digital Bazaar, Inc.
>
>
