- From: mattsaxon <notifications@github.com>
- Date: Wed, 04 May 2016 07:04:48 -0700
- To: w3c/browser-payment-api <browser-payment-api@noreply.github.com>
- Cc:
- Message-ID: <w3c/browser-payment-api/pull/153/c216875338@github.com>
@nickjshearer > This is going to significantly degrade the experience for some payment instruments. I actually think some payment apps need to have the completion value passed back to it. I agree with you, though I though the group consensus (which I disagree with) was that this sort of interaction would be done out of band. > An example is UnionPay, where transactions may require a PIN. This PIN (in encrypted form) is passed from the payment app via the user agent and payment processor to the issuing bank, where it's validated. If it's incorrect, the payment processor is instead of providing a "Success" or "Failure" going to return an "Incorrect PIN" status. In the agreed model, the PIN validation would occur out of band from within the PaymentApp with the success of the authorisation being passed back in the PaymentResponse. Any retries would be done in the app. We do need a method to passback failure though. Note: I dislike this model and would prefer a conversational approach to the API as you describe. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/browser-payment-api/pull/153#issuecomment-216875338
Received on Wednesday, 4 May 2016 14:05:22 UTC