Allow web-based payment handlers to report back internal error#429
Allow web-based payment handlers to report back internal error#429stephenmcgruer wants to merge 4 commits intogh-pagesfrom
Conversation
| </li> | ||
| <li>If <var>handlerResponse</var>.<a data-lt= | ||
| "PaymentHandlerResponse.details">details</a> is not present | ||
| or not <a>JSON-serializable</a>, run the <a>payment app |
There was a problem hiding this comment.
I noticed that the details validation step doesn't pass an OperationError DOMException to the payment app failure algorithm, while the other validation steps (e.g., methodName, shippingAddress, payerName, etc.) all do.
Was this intentional, or just accidentally missed? Let me know if there's a reason for treating it differently — I might be missing some context.
There was a problem hiding this comment.
Nope, oversight! Fixed.
| <ol class="algorithm"> | ||
| <li> | ||
| If |reason| is an {{"OperationError"}} {{DOMException}}, then run | ||
| the <a>Payment handler indicates an internal error algorithm</a> as |
There was a problem hiding this comment.
nit: Might need a data-cite import here? The link doesn't seem to resolve in the preview.
There was a problem hiding this comment.
Ah, its because they weren't exported in Payment Request. Fix is in w3c/payment-request#1061
| defined in [[!payment-request]]. | ||
| </li> | ||
| <li> | ||
| Otherwise, run the <a>user aborts the payment request algorithm</a> |
There was a problem hiding this comment.
Ah, its because they weren't exported in Payment Request. Fix is in w3c/payment-request#1061
3 participants
See #428 and w3c/payment-request#1040
closes #???
The following tasks have been completed:
Implementation commitment:
Preview | Diff