-
Notifications
You must be signed in to change notification settings - Fork 134
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Supporting push payment methods #224
Comments
@rvm4 thanks for kicking this off! In my experience the best way to guarantee that the sender (in this case the merchant) will have the same transaction reference as the receiver (in this case the payment app) in the case where no response is received and we don't know how far processing got is to send the transaction identifier in the original request. I'd propose that we have a field in payment request that allows a unique identifier (UUID makes the most sense I think) and that this is returned in the "payment processing" event. If you wait for the TX id to come from the app you risk comms going down before the app can provide this to the browser. |
A few comments:
|
Is that true? |
Well that is what I'm trying to propose, I will make that more clear in the PR. |
Any additional thought here? I think this topic needs just as much consideration as the security consideration we are giving the credit card flow. If we are concerned about specifying ways to avoid security flaws, certainly we want to specify ways to prevent expected failure scenarios. |
+1 - however I think rather than diving straight into a PR why don't we map out the expected flows for a push payment first and identify the failure scenarios we are trying to address |
We MUST already have such a flow. Matt Saxon? On Tue, Jul 12, 2016 at 5:43 PM, Adrian Hope-Bailie <
Shane McCarron |
Sounds great, can we add to our call agenda an item to establish a task force for solving this problem? |
I would request that we use the Push SEPA flow as documented in the specification as an example http://w3c.github.io/webpayments-methods-credit-transfer-direct-debit/ The document doesn’t look specifically as failure modes at the moment, but the data specification has a reference field on both request and response (payeePaymentIdentification & payerPaymentIdentificaiton) that is designed to address deduplication on any double submission due to failure. These fields are direct pass throughs from the SEPA specification. |
Some additional requirements for push payments:
It's useful to think of push payments in the context of the following roles:
It's quite likely that the same entity could fulfill many of these for example Alipay could be 3, 4, and 5. The challenge we must deal with is that in preparing the payment request it's not desirable for the merchant to need to call out to the processor (4) each time if it's possible that the user may use another payment method. (e.g. If the merchant must call out to the processor to sign the request each time) It's also challenging to deal with PKI (and especially verification of public keys and who they belong to) so offline validation is complex unless the scheme can support this. There will likely be schemes/methods that use PKI and those that don't to make the job of the merchant simpler PROPOSAL:
A UUID is probably a good option. It's simpler but quite inefficient for this to be done per payment method so it would make sense to make this a requirement for all Payment Requests and ignore it if it's not required. UAs could easily provide a function to generate these effectively (i.e. The browser could generate this when the PaymentRequest constructor is called and assign it to a read-only property of the new object). This Payment Request ID can be used by the merchant (and possibly the payment app?) for interactions between roles and phases where state has been lost or is not shared. For resilience it is best if this identifier is generated as early as possible by the first entity in the multi-party interaction. If it's generated by the payment app, for example, then if the communication breaks down between the website and the payment app then the website has no way to query the state of the request later.
This URL could either be hosted by the merchant (1) or their processor (4) and is a reliable means for the payment app and the merchant/processor to establish an interactive channel for processing the payment. This is similar to the proposal in #109 but probably has more general/generic use cases.
When the browser passes the flow control to the payment app it should notify the website which payment app was selected (and therefor which payment methods may be used to process the payment). This is required by the website to know how to track the payment as it progresses. An event similar to that proposed by @rvm4 is probably the best solution. These 3 changes, and some guidance on how these may be used to make push payments more resilient, is probably sufficient from a standardization perspective. |
Here are some comments on your three proposals.
Do you mean: For the purposes of payment app / browser communication I phrase it this way to see whether it makes sense as a requirement in scope for the payment app spec. I want to distinguish the purpose of these identifiers from other identifiers that might be circulating in the system (e.g., merchant generated identifiers that they use for their own internal
In spec terms, I hear: The payment request API specification should be modified to include
I don't understand this requirement. It seems to me that when the promise resolves, the merchant gets back data. It seems appropriate at that time to identify the payment method, so that the response data can be routed appropriately. But why does the merchant need to know which payment app was used? |
Related: |
@rvm4, @stan-stripe, @adamroach, and I discussed WPWG feedback
[1] https://w3c.github.io/webpayments/proposals/method-practice/ |
This text reflects some discussion [1] but not yet WG consensus. [1] w3c/payment-request#224
Discussed today with editors, concluded that this can be closed because we added id to PaymentRequest. |
I put out a PR that I expect to spur discussion, so let's use this issue to discuss: #223.
The text was updated successfully, but these errors were encountered: