← back to v154 · secure-payment-confirmation-locale-validation
conformance · v154
v154 · secure-payment-confirmation-locale-validation — conformance probe
7 assertions drawn from the spec. Each is a single contract the spec text makes. Pass/fail reflects what this browser executed; blocked means the contract was not run because it needs user mediation, hardware, or another unavailable precondition. Open the page in Chrome stable / canary / Firefox / Safari to compare.
0
pass
0
fail
0
blocked
7
total
| id | contract | kind | verdict | detail |
|---|---|---|---|---|
payment-request-available |
The API Secure Payment Confirmation is delivered through. spec ↗ | typeof | … | |
secure-payment-confirmation-constructs |
A request naming the secure-payment-confirmation method with a complete data object must construct. Everything the demos do rests on this. spec ↗ | script | … | |
the-locale-is-not-validated-at-construction |
A nonsense locale list and an empty one must both construct, because the field is checked when the dialog opens rather than when the request is built. This is the whole reason a caller needs a pre-flight of its own — and if it ever became a construction-time check, the demos' framing would be wrong. spec ↗ | script | … | |
method-data-is-json-serialised |
The method data is serialised before any payment-specific validation, so a property whose getter throws fails with a message about JSON rather than about the field. A getter that merely returns a value is fine — the distinction is not obvious and the error does not help. spec ↗ | script | … | |
canmakepayment-answers-without-a-gesture |
canMakePayment resolves without user activation, which is what lets a checkout decide its path before showing anything. A version that required a gesture would make the pre-flight impossible. spec ↗ | script | … | |
intl-can-answer-the-matching-question |
The locale demos rest on Intl having the same locale data the question is about: canonicalisation that throws on a malformed tag, a supported-locales query, and a best-fit resolution over a list. Without all three the matching page would be guessing. spec ↗ | script | … | |
the-user-languages-are-readable |
The dialog is in the user's language, so a caller comparing its own locale list against navigator.languages is asking the right question. If that list were unavailable the pre-flight could not be written at all. spec ↗ | script | … |