15:02:47 RRSAgent has joined #wpwg-push 15:02:47 logging to http://www.w3.org/2016/10/18-wpwg-push-irc 15:02:56 Zakim has joined #wpwg-push 15:03:05 AdrianHB has joined #wpwg-push 15:03:14 adamR has joined #wpwg-push 15:04:49 Roy has joined #wpwg-push 15:04:51 https://github.com/w3c/browser-payment-api/issues/287 15:04:54 https://github.com/w3c/browser-payment-api/issues/224 15:06:11 scribe: Ian 15:06:16 Meeting: Push Payments and PR API 15:06:44 Roy: One question is whether this is for payment apps to support or mediator 15:06:53 ...another proposal has been a callback URL 15:07:12 ...indeed one for the payment app to call the merchant AND a callback for the merchant to pull the payment app 15:08:04 IJ: Can we generalize to talk about the merchant pinging the payment method provider (might be app, might be a server) 15:08:59 ...the callback URL is to some entity with the authoritative state (which might be the payment app or a server) 15:09:38 q+ 15:10:09 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 15:10:31 ...if you expect the callback Url to reference the browser-provided ID, then you are expecting something meaningful...@@ 15:11:13 Roy: 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 15:11:31 ...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 15:11:49 ...the thread calls out some issue like SEPA (can't have other parties generating the IDs) 15:11:57 ack me 15:12:51 IJ: Are both push and pull callback URLs necessary and what is used in the real world? 15:13:06 MattS has joined #wpwg-push 15:13:08 AdamR: We have been talking about returning a URL to the merchant to poll...that can be provided per payment-method 15:13:25 ...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. 15:13:58 IJ: When does the handoff happen? 15:14:03 AdamR: Leave that aside for a moment. 15:14:28 AdamR: The other way that could be possible (and could be generalizable and would make use of mediator-generated ID) 15:14:53 ....app would be able to query the URL with standardized data 15:15:02 ...the URL itself becomes an internal matter of the payment app 15:15:07 ...I think this approach is cleaner 15:15:38 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 15:16:58 IJ: I want to frame this as a question of "poll authoritative info" 15:17:10 MattS: So that sounds like the intent is a long-term URL 15:18:56 PROPOSAL #1 15:19:29 - URL for a merchant-callable service for authoritative payment information that is returned in payment response data with a standardized name. 15:19:39 AdamR: I think that's low value. That's a very small part of what needs to happen. 15:19:50 ...for any given payment method you need to know how you use the URL and what the response looks like. 15:20:24 IJ: This could vary by service, not even just payment method 15:21:22 AdamR: I am correlating status information with payment method 15:21:31 ack me 15:21:55 Roy: I think that for proprietary it may be too much to consolidate responses with status info into something standard. 15:23:07 Roy: A good way to back up here is for us to reach consensus on the first goal 15:23:30 E.g.: Have infrastructure in place to enable someone to get status information (whether easy or hard) 15:23:42 ...another goal is "standardization to enable push payment methods" 15:24:09 ...for me personally it would be valuable to have facilities in place for someone to figure out "what happened to my payment" 15:24:55 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. 15:25:04 PROPOSAL #2 15:25:23 - URL for a payment service to call a merchant to send status information 15:25:36 AHB: ..but I think that without a standard format that won't be very useful 15:25:57 AHB: Are we thinking of creating a "Basic Push" spec that includes a few terms? 15:26:27 Roy: I propose that we punt on the "Push Payment" part and handle just the error-handling 15:27:34 q+ 15:27:45 Roy: I think transaction ID is not contentious but you need to be able to do something with it. 15:28:30 AdrianHB: In card world, if you don't get a response you fail 15:30:57 IJ: I want to posit "We just need one callback URL" since one entity can say "Call me back here" 15:31:25 Pascal: For scalability it matters who starts the communication 15:31:49 AdrianHB: If you are just synchronizing on state, it's a simple matter of chatting back and forth 15:32:35 ...an alternative to staying synchronized on state of transaction is for orgs to be able to send reversal requests 15:33:04 MattS: Scope question - synchronization of state has multiple use cases. Is our focus just failure? 15:33:25 ..I think we have three use cases we are potentially conflating. Let's nail down the use cases 15:33:39 ...I hear thre 15:33:55 1) I want to recover from a failure 15:34:03 2) I want to stay up to speed with an async transaction 15:34:14 (pull) 15:34:25 3) I want to stay up to speed with an async push transaction 15:34:38 Proposal: scope ourselves to providing minimal infrastructure to recover from failure at the spec level, iterate on it later 15:34:41 AdrianHB: I think we are just focused on push 15:35:12 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 15:35:18 ...so I conclude that our focus should be PUSH 15:36:10 MattS: 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. 15:36:32 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. 15:37:10 MattS: When authorization is async and outside of browser view, it would be useful for the merchant to know some intermediate states 15:37:45 PROBLEM: merchant needs authoritative information about whether a payment was processed. 15:38:27 MattS: Often there's three answers: success/failure/pending 15:38:53 MattS: 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 15:39:07 ...the reason it's still worth considering is that CHARGES CAN ACCRUE when funds are put on hold 15:39:46 yes 15:39:58 PROPOSAL: Provide infrastructure to enable a payee to determine authoritatively whether there was or will be a transfer of funds 15:40:21 MattS: BACS transfer can take 5 days...during 5 days you might poll PSP and the answer is still pending 15:40:42 MattS: +1 15:40:44 Roy: +1 15:41:12 Roy: I think to get this we want (1) transaction ID and (2) reference to a service that uses it 15:41:32 ...I think the transaction ID needs to be routed to the mediator to the payment app 15:41:53 pascal_bazin_ has joined #wpwg-push 15:42:55 IJ: When is transaction ID handed to merchant? EG when control handed to payment app 15:43:11 Roy: Yes, but I think the merchant should get back the ID when they release payment request data to to the browser. 15:43:45 AdamR: The way the current proposal happens - you get the transaction ID at the creation of the payment object 15:43:59 ...we can specify that it's meaningless until you call call() or whatever 15:44:07 +1 for having an ID as early as possible 15:44:27 PROPOSAL: Transaction ID generated by the mediator returned at construction time 15:45:21 COUNTER-PROPOSAL: Transaction ID generated by the mediator and available via a property of the PaymentRequest object at construction time. 15:46:56 IJ: Question is who should provide the URL: payee or PSP? 15:47:09 Payee 15:47:10 Roy: Large PSPs want to push notifications to avoid being pinged a lot 15:47:43 AdamR: I think response data will be payment-method specific 15:47:45 q+ 15:48:13 AdrianHB: If there were a single callback URL where the payload is standardized across payment methods that would provide value. 15:48:29 ...you don't have to expose new endpoints for new payment methods 15:48:31 ack me 15:48:36 AdamR: Sounds reasonable 15:49:18 IJ: So to the data could be something like: 15:49:20 * transaction ID 15:49:21 * Origin 15:49:27 * State (one of success/fail/pending) 15:50:34 (strike Origin) 15:50:53 IJ: Is that useful enough as a starting point? 15:51:18 IJ: I want to answer the question - were funds transferred? 15:51:42 AdrianHB: I think that as a merchant I will be able to determine that based on the payment method. 15:51:46 IJ: But you didn't say anything yet. 15:52:00 AdrianHB: I think the state is payment method specific, and that would be private data 15:52:09 ...e.g., paypal might say "we're checking for fraud" 15:53:06 ...merchants need to know how to handle that data for integration of that payment method 15:53:06 +1 to AHB, perhaps standarise the field name as a string type? 15:53:16 ...this is essentially an alternative channel for delivering the payment response data. 15:53:40 PROPOSAL: PaymentResponse (from PSP to Merchant callback instead of returned via API) contains: TX ID, payment method id, payment method specific stuff 15:53:44 MattS: We could define a "state" well-known field name, as an opaque string 15:54:24 Adrian: I think we should think of this is sending payment response data via HTTP with in addition a transaction ID. 15:55:41 ...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 15:56:40 Adrian: We would not specify the data MUST BE THE SAME because that's payment method specific. 15:57:00 ====================== 15:57:25 * Problem: enable merchant to know authoritative info on transfer or pending transfer (in case of failure) 15:57:28 * Proposal: 15:57:44 - mediator generates a unique TX ID that is part of the payment request object 15:58:15 - merchants can specify callback URL for PSPs to send TX ID + payment method identifier + any payment method specific data. 15:58:31 IJ: Does this go in basic card or PR API? 15:58:55 (IJ thinks it's PR API given goal of cross-payment-method) 16:00:16 - 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. 16:01:17 MattS: One approach is: 16:01:20 - identify the pattern 16:01:26 - do it payment-method specific 16:01:33 - if it's used, elevate to PR API in next version 16:02:06 MattS: We want to determine whether it NEEDS to be in PR API (and thus has impact on API today) 16:02:29 AdrianHB: I think that the TX ID is important to have now... 16:03:39 IJ: I am hearing a split in urgency: TX ID in PR API; then payment method specific callback URLs 16:04:40 AdamR: Are we envisioning that in the future people will have to try both? 16:04:42 IJ: that sounds right 16:04:49 ..is that a problem? 16:05:00 AdamR: If we can predict it will happen, I think I would tend to avoid it. 16:05:20 +1 to AdamR 16:06:06 IJ: Questions (1) who will write up (2) should we start by having both in PR API as a proposal? 16:07:08 ACTION: Roy to write this up and lead discussion at the 20 Oct call 16:07:11 I have made the request to generate http://www.w3.org/2016/10/18-wpwg-push-minutes.html Ian 16:08:24 q? 18:14:21 Ian has left #wpwg-push 18:29:46 Zakim has left #wpwg-push