Push Payments and PR API -- 18 Oct 2016

<Roy> https://github.com/w3c/browser-payment-api/issues/287

https://github.com/w3c/browser-payment-api/issues/224

<scribe> scribe: Ian

Roy: One question is whether this is for payment apps to support or mediator
... another proposal has been a callback URL
... indeed one for the payment app to call the merchant AND a callback for the merchant to pull the payment app

IJ: Can we generalize to talk about the merchant pinging the payment method provider (might be app, might be a server)
... the callback URL is to some entity with the authoritative state (which might be the payment app or a server)

Roy: If you force the payment app to expose a callback URL, this goes into Adam's thread about the semantics of the transaction ID
... if you expect the callback Url to reference the browser-provided ID, then you are expecting something meaningful...@@
... If you are providing a transaction ID from the mediator..it is trivial for people to use that as a safety mechanism to map from browser ID to something in their own system that is meaningful
... but if you create a callback Url at the mediator level, you are forcing people to apply additional semantics on top of that transaction ID
... the thread calls out some issue like SEPA (can't have other parties generating the IDs)

IJ: Are both push and pull callback URLs necessary and what is used in the real world?

AdamR: We have been talking about returning a URL to the merchant to poll...that can be provided per payment-method
... I think that's the right thing to do since how to use that URL (how to GET and format of results) will be specific to that URL.

IJ: When does the handoff happen?

AdamR: Leave that aside for a moment.
... The other way that could be possible (and could be generalizable and would make use of mediator-generated ID)
... app would be able to query the URL with standardized data
... the URL itself becomes an internal matter of the payment app
... I think this approach is cleaner

MattS: One thing that wasn't clear to me was about whether we are polling an instance of an app or a back end server

IJ: I want to frame this as a question of "poll authoritative info"

MattS: So that sounds like the intent is a long-term URL

PROPOSAL #1

- URL for a merchant-callable service for authoritative payment information that is returned in payment response data with a standardized name.

AdamR: I think that's low value. That's a very small part of what needs to happen.
... for any given payment method you need to know how you use the URL and what the response looks like.

IJ: This could vary by service, not even just payment method

AdamR: I am correlating status information with payment method

Roy: I think that for proprietary it may be too much to consolidate responses with status info into something standard.
... A good way to back up here is for us to reach consensus on the first goal

E.g.: Have infrastructure in place to enable someone to get status information (whether easy or hard)
... another goal is "standardization to enable push payment methods"
... for me personally it would be valuable to have facilities in place for someone to figure out "what happened to my payment"

AdrianHB: Regarding the second goal, we've been here before on other topics - when you get to the question of "what implementers have to write" if you only have a bit of standardization, then that bit may not be worth it.

PROPOSAL #2

- URL for a payment service to call a merchant to send status information

AHB: ..but I think that without a standard format that won't be very useful
... Are we thinking of creating a "Basic Push" spec that includes a few terms?

Roy: I propose that we punt on the "Push Payment" part and handle just the error-handling
... I think transaction ID is not contentious but you need to be able to do something with it.

AdrianHB: In card world, if you don't get a response you fail

IJ: I want to posit "We just need one callback URL" since one entity can say "Call me back here"

Pascal: For scalability it matters who starts the communication

AdrianHB: If you are just synchronizing on state, it's a simple matter of chatting back and forth
... an alternative to staying synchronized on state of transaction is for orgs to be able to send reversal requests

MattS: Scope question - synchronization of state has multiple use cases. Is our focus just failure?
... I think we have three use cases we are potentially conflating. Let's nail down the use cases
... I hear thre

1) I want to recover from a failure

2) I want to stay up to speed with an async transaction

(pull)

3) I want to stay up to speed with an async push transaction

<Roy> Proposal: scope ourselves to providing minimal infrastructure to recover from failure at the spec level, iterate on it later

AdrianHB: I think we are just focused on push

MattS: There are payment methods where the merchant contacts the payment providers - the payer gives the merchant credentials and the merchant contacts the PSP...but I think that's out of w3c use case
... so I conclude that our focus should be PUSH
... there may be an interesting split use case - the payment app does the authorization ,but the merchant does the execution. Paypal works sometimes this way.

AdrianHB: I would still call that "pull"...I think the thing we are MOST worried about is that the payment is processed and the merchant doesn't know it.

MattS: When authorization is async and outside of browser view, it would be useful for the merchant to know some intermediate states

PROBLEM: merchant needs authoritative information about whether a payment was processed.

MattS: Often there's three answers: success/failure/pending
... Worth capturing (but not considering now)...you want to know the status of a pending authorization....I agree we should be focused on TRANSFER OF FUNDS and not FUNDS ON HOLD
... the reason it's still worth considering is that CHARGES CAN ACCRUE when funds are put on hold

<Roy> yes

PROPOSAL: Provide infrastructure to enable a payee to determine authoritatively whether there was or will be a transfer of funds

MattS: BACS transfer can take 5 days...during 5 days you might poll PSP and the answer is still pending
... +1

Roy: +1
... I think to get this we want (1) transaction ID and (2) reference to a service that uses it
... I think the transaction ID needs to be routed to the mediator to the payment app

IJ: When is transaction ID handed to merchant? EG when control handed to payment app

Roy: Yes, but I think the merchant should get back the ID when they release payment request data to to the browser.

AdamR: The way the current proposal happens - you get the transaction ID at the creation of the payment object
... we can specify that it's meaningless until you call call() or whatever

<AdrianHB> +1 for having an ID as early as possible

PROPOSAL: Transaction ID generated by the mediator returned at construction time

<AdrianHB> COUNTER-PROPOSAL: Transaction ID generated by the mediator and available via a property of the PaymentRequest object at construction time.

IJ: Question is who should provide the URL: payee or PSP?

<AdrianHB> Payee

Roy: Large PSPs want to push notifications to avoid being pinged a lot

AdamR: I think response data will be payment-method specific

AdrianHB: If there were a single callback URL where the payload is standardized across payment methods that would provide value.
... you don't have to expose new endpoints for new payment methods

AdamR: Sounds reasonable

IJ: So to the data could be something like:

* transaction ID

* Origin

* State (one of success/fail/pending)

(strike Origin)

IJ: Is that useful enough as a starting point?
... I want to answer the question - were funds transferred?

AdrianHB: I think that as a merchant I will be able to determine that based on the payment method.

IJ: But you didn't say anything yet.

AdrianHB: I think the state is payment method specific, and that would be private data
... e.g., paypal might say "we're checking for fraud"
... merchants need to know how to handle that data for integration of that payment method

<MattS> +1 to AHB, perhaps standarise the field name as a string type?

AdrianHB: this is essentially an alternative channel for delivering the payment response data.

<AdrianHB> PROPOSAL: PaymentResponse (from PSP to Merchant callback instead of returned via API) contains: TX ID, payment method id, payment method specific stuff

MattS: We could define a "state" well-known field name, as an opaque string

Adrian: I think we should think of this is sending payment response data via HTTP with in addition a transaction ID.
... the response includes method identifier and response data (which is method specific but MAY BE DIFFERENT) than what was returned via PR API...and add TX ID
... We would not specify the data MUST BE THE SAME because that's payment method specific.

======================

* Problem: enable merchant to know authoritative info on transfer or pending transfer (in case of failure)

* Proposal:

- mediator generates a unique TX ID that is part of the payment request object

- merchants can specify callback URL for PSPs to send TX ID + payment method identifier + any payment method specific data.

IJ: Does this go in basic card or PR API?

(IJ thinks it's PR API given goal of cross-payment-method)

- the merchants would provide this optional callback URL in PR API data because the goal is for them to have a single endpoint cross payment methods.

MattS: One approach is:

- identify the pattern

- do it payment-method specific

- if it's used, elevate to PR API in next version

MattS: We want to determine whether it NEEDS to be in PR API (and thus has impact on API today)

AdrianHB: I think that the TX ID is important to have now...

IJ: I am hearing a split in urgency: TX ID in PR API; then payment method specific callback URLs

AdamR: Are we envisioning that in the future people will have to try both?

IJ: that sounds right
... is that a problem?

AdamR: If we can predict it will happen, I think I would tend to avoid it.

<MattS> +1 to AdamR

IJ: Questions (1) who will write up (2) should we start by having both in PR API as a proposal?

<scribe> ACTION: Roy to write this up and lead discussion at the 20 Oct call [recorded in http://www.w3.org/2016/10/18-wpwg-push-minutes.html#action01]

- DRAFT -

Push Payments and PR API

18 Oct 2016

Attendees

Contents

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output