Re: [w3c/payment-request] Retrying a payment (#705)

> Maybe if retry() returned a promise that resolved next time the "Pay" button was pressed?

Ah, great point. 

> In particular, I'm concerned about the complexity of your sample code for a merchant that just wants to do validation all at once, without dealing with the *change events. They just want to wait for the pay button to be clicked, check the fields, and ask for a retry if the fields are wrong. Then repeat until the fields are right.

Right, so:

```JS
// Recursive validation, no events.
async function validateResponse(r){
  const errors = validate(r);
  if (errors) {
     await r.retry(errors);
     await validateResponse(r);
  }
}
```

We could, in theory, support both models: The nice thing about the events is that it allows more immidiate feedback between the user and merchant... like: user changes their email, merchant checks it right after it changes. Merchant calls `.updateWith()` saying it's still bad... repeat until it's good. 

Thus, the problem with just `retry()` is that the user is put into a situation where "Pay" means "validate"... I guess it already kinda means that, but without the events, that becomes a bit more extreme.


-- 
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/payment-request/issues/705#issuecomment-386152275