Should we standardise a callback mechanism for payment apps to communicate to 3rd parties? about webpayments

[zkoch]

Hey Adrian, interesting question. A few thoughts:

• Can you clarify use cases around this and how common those use cases are? I'm skeptical there is a real need for this.
• This creates a rather strange implementation on the side of the merchant. It's the client that created the payment request, but now it's the server that is receiving certain change notifications? So now both the client and server have some sense of the paymentrequest state? I do not think I would want to implement such a system.
• Technically, this is possible given the current paymentRequest API if both the merchant and the chosen payment app wanted to take advantage of it. But again, I'm not so sure this is a case we need to support.

-Zach

[dprophet]

Many times communication and updates happen using out of bands communications. Asyncronous communications add a lot of development value even if its hard to find business justification. We utilize web rpc endpoint mappers to accommodate business and development use cases.

[adrianhopebailie]

Can you clarify use cases around this and how common those use cases are?

1. Payer adds a coupon to their payment and the payee has to recalculate the price
2. The payment method supports DCC and they payment app needs to get a quote from the payee or their PSP for a price in an alternative currency
3. Payer provides some detail that changes their tax calculation
4. Payer indicates they are part of a loyalty program that qualifies them for a different deal (free delivery or lower price)

It's the client that created the payment request, but now it's the server that is receiving certain change notifications

True, but it's quite unlikely that sending this via the client (using events or similar) would be very different. Consider that if the client needed to recalculate the payment request they would likely request it from the server anyway.

This is not a difficult flow to implement at all. When the client gets the payment response their first step would be to poll the server for any updates. The flow is still simple and linear from the perspective of the client.

Technically, this is possible given the current paymentRequest API if both the merchant and the chosen payment app wanted to take advantage of it. But again, I'm not so sure this is a case we need to support.

I agree. I logged it here to get input from the group because technically it's possible but we should decide if it's likely to be implemented widely enough to justify standardizing it.

[halindrome]

It occurred to me that it might be useful to tie this (and some other issues) back to our use cases at https://www.w3.org/TR/web-payments-use-cases/. On the other hand, there are no use cases in the document that explicitly call out for this feature IMHO. Moreover, any merchant site should have gathered coupon, loyalty, and shipping options before they call paymentRequest anyway. If that is not the case (or the customer has some late breaking information), I would just abort the paymentRequest call and re-issue it with the updated information if it were my site. That would work better with issue #79 anyway.

Having said all of that, here are a handful of use cases that I think are related to this issue:

6.1 (Point of Sale Kiosk) - the various interactions would result in things like recalculating prices as coupons are applied.

6.1.2 (One-time Payment) - if there were an option to upgrade to a recurring purchase for a discount that might result in a recalculation.

6.1.3 (all of them) - coupons, credits, cards - these things might get applied during the wallet action, and the wallet would need to iterate with the merchant server.

6.2.2 (manual selection of payment instrument) - selecting different payment instruments might result in pricing changes; use your debit card, get a discount; use your store-provided card, get a discount; use american express, pay a premium.

6.3.2 (funds verification) - I could see an iterative cycle where the wallet identifies funds available in multiple payment accounts, the payer wants to use several instruments, and then there are varying
discounts or fees associated with the multiple cards.

[rsolomakhin]

As a browser developer, this feature does not affect my implementation, so I have no strong opinion on it. However, I would prefer to keep the API simple at least in the initial iterations for the web developers' sake.

[adrianba]

It's easy to envisage a way to add this to the PaymentRequest API but I'm not in favour of doing so. The use cases seem very theoretical and I'm not convinced they will occur in practice. This doesn't seem like it is needed as a v1 feature and is something we could add later if needed.

I'm not a fan of setting up arbitrary communication channels between pages and plug-ins - it means that the payment method ecosystem will struggle to scale since people will have to write lots of payment app specific code.

I think the answer for now should be no.

[adrianhopebailie]

it means that the payment method ecosystem will struggle to scale since people will have to write lots of payment app specific code

I would consider this an argument in favor of standardization. If we standardize a mechanism to ask the payee for a new updated payment request via HTTP (which sounds like something we're talking about doing anyway in the HTTP API) then all that would be required in the browser API is a standard place to provide the callback URL.

I propose that we leave this out until we can demonstrate how it will be used (perhaps in conjunction with the HTTP API) and the value of standardizing it. It's a very minor change to the browser API spec if we do choose to add it.

[webpayments]

+1 to waiting until we can demonstrate it via the HTTP API before we
consider including such a hook in the browser API. As you say, it would be
a minor change to add a parameter.

On Thu, Feb 11, 2016 at 7:17 AM, Adrian Hope-Bailie <
[email protected]> wrote:

it means that the payment method ecosystem will struggle to scale since
people will have to write lots of payment app specific code

I would consider this an argument in favor of standardization. If we
standardize a mechanism to ask the payee for a new updated payment request
via HTTP (which sounds like something we're talking about doing anyway in
the HTTP API) then all that would be required in the browser API is a
standard place to provide the callback URL.

I propose that we leave this out until we can demonstrate how it will be
used (perhaps in conjunction with the HTTP API) and the value of
standardizing it. It's a very minor change to the browser API spec if we do
choose to add it.

—
Reply to this email directly or view it on GitHub
#76 (comment).

-Shane

[msporny]

Just chiming in to say I think this is important, but don't have the time to devote to it right now.

Here's why I think it's important:

Without a well-defined communication channel between payment app and merchant website, I don't think we can fulfill a number of our non-browser-based use cases. I'd say that the majority of the group doesn't understand that not standardizing this means that there are potentially no 3rd party payment apps that aren't tightly coupled. For example, actual native applications running on a mobile device. So, while I'm sure Google, Microsoft, and Apple would have no problem writing a native payment app for their mobile platforms that communicate w/ a merchant, I doubt a non-multi-billion-dollar-multinational would have an easy time doing such a thing.

This also asks the question - how does a non-browser-based flow get a request and respond to a request via the HTTP API? What communication channel is used for that? This is why we have a 'paymentRequestService' URL in the HTTP API: http://web-payments.github.io/web-payments-http-api/#h-payment-app-registration

It really wouldn't be that hard to add a number of HTTP-based callbacks for these communication purposes since we're going to have to do something like "paymentRequestService" anyway for the HTTP-based API.

[mattsaxon]

+1 to this being important, but I note this has not been migrated across to the browser api spec repo. If we are going to allow an open environment where Payment Methods can talk to Payment Processor, then we need a way of specifying this in a general way. I think the right way to explore this is to model some of the more complex payment types other than BasicCardResponse and we really need to do this asap to see if the API is fit for purpose.

[webpayments]

There is a huge difference between communications that happen before and
after the user's act of payment.

Any communications that happen before payment represent a tracking and
privacy threat, but after payment this no longer represents an issue.

In Taler, we actually have two round trips between the customer's wallet
and merchant. If the merchant invokes the payment API, then they have
committed to making the sale described in the contract they present, and
this shifts context to the wallet's extension. If the user clicks pay,
then the wallet builds the payment and invokes the merchant's
fulfillment URL.

That fulfillment URL makes additional API requests for the actual coins
that make the payment for that specific contract. Those requests
contain an alternative product URL, so that if the API requests fail,
like because the user forwarded the fulfillment URL to a friend, then
wallet transfers the top-level context to the product URL. This change
of top-level context improves user experience and prevents the
fulfillment API from being used for tracking users.

We should probably limit payment apps web communications to after the
payment action like this. After all, we are discussing payment apps
that should be considered hostile to the user's interests, like coupons
or whatever.

[adrianhopebailie]

Closing in favor of w3c/payment-request#109