@agent-cards/sdk 0.22.0 → 0.23.1

package/CHANGELOG.md

@@ -2,6 +2,40 @@
 
 ## Unreleased
 
+- Stop the card fields adyen-web 5 encrypts at a reviewed Adyen merchant profile. adyen-web 5 seals each field as an RSA-OAEP / A256CBC-HS512 JWE, where adyen-web 6 writes RSA-OAEP-256 / A256GCM, and the SDK read only adyen-web 6's form. So the card requests of Cathay Pacific's payment page and Dunelm's legacy checkout, and Cathay's charge request after its signing step, reached the merchant with the agent's dummy card. The adapters now read both forms as a card. Both profiles ship in `observe`, so the adapters abort each of these requests before it leaves the browser and report it as `merchant_profile_observed`. The Vault writes only adyen-web 6's form, so the API refuses a create for a card request in adyen-web 5's form with `cse_template_unsupported`, and nothing is charged.
+
+- Abort the requests in which IHG's pay page sends the typed card outside its reviewed card request, in every status, as `card_endpoint_refused` with reason `card_resend`. The page posts the same booking to IHG's enrollment service while its pre-ticked "Enroll for free" box stays ticked, posts it on other paths for more than one room, a travel agent or Business Rewards, and at a hotel that asks for 3-D Secure first posts the number to two 3-D Secure calls. The SDK let each of these reach IHG with the agent's dummy card. A booking with the box unticked reaches IHG's reviewed card request, which the adapters refuse as before while IHG is in `observe`.
+
+## 0.23.0
+
+### Upgrading from 0.22.0
+
+- An SDK attached at Delta, Hilton, IHG, American Airlines, EconomyBookings, The Verb Hotel, RunSignUp, Mindbody, LookFantastic, Hyatt, LifeMiles, Southwest Airlines, United Airlines, Athens-Clarke County's MyRec page, Los Angeles or San Francisco on Conduent eTIMS, the D-EDGE card frame, NIC Common Checkout or Lexicon's FastSpring popup now stops the request that carries the card before it reaches the merchant. 0.22.0 let that request through with whatever card the agent typed. Every one of these profiles is in observe, so the request is refused as `unsupported_checkout` and the controller reads `unsupported`. A card form the page submits as a page load gets the SDK's stopped page instead of an aborted load.
+
+- On every reviewed card endpoint, the five from 0.22.0 included, a POST to the card request URL that carries no card now continues untouched (0.22.0 refused every POST there). A card in a body other than the one the profile reviewed now reads reason `unrecognized_payment_endpoint`, and its event names only the endpoint origin; only the reviewed body reads `merchant_card_endpoint_not_enabled`.
+
+- TypeScript: `CardEndpointRefusal` gains `facts_unavailable` and `facts_refused`, `CardEndpointReplay`'s `withheld` gains `refused_step_in_response`, and the controller's `unsupported()` reasons gain `processor_card_page` and `merchant_card_endpoint_resend_refused`. Code that switches exhaustively over one of them needs the new cases. `PaymentOutcomeUnknownError` gains `processorRequestStarted`, `PrepareCheckoutOptions` gains `tokenizeBeforePay`, `PreparedCheckout` gains `cybersourceFlex`, and `PausedRequest`'s `merchant_card_endpoint` gains `facts`.
+
+- NMI and CyberSource Flex tokenize-before-pay are served only to a company Agentcard enabled for them, so nothing changes there for any other company.
+
+### New
+
+- Recognize nine more reviewed merchants that post the card from their own checkout page to their own server: Delta, Hilton, IHG, American Airlines, EconomyBookings, The Verb Hotel, RunSignUp, Mindbody and LookFantastic (mode `card_endpoint`). Every profile ships in observe, so the adapters pause each merchant's exact card request and refuse it as `unsupported_checkout` before any authorization. On every reviewed card endpoint, the first five included, only a request that carries a card pauses (anything at the profile's card number field, or a Luhn-valid number of 12 to 19 digits anywhere in the body; a body the adapter cannot read counts as one). A request to the same URL with no card in it, such as an IHG stay paid with points, a LookFantastic order whose card BR-DGE or Adyen tokenized, a saved card, or a room another SynXis hotel guarantees with a token, continues untouched. The refusal names the profile, with reason `merchant_card_endpoint_not_enabled`, only when the body is the request the profile reviewed; a card in any other body reads reason `unrecognized_payment_endpoint`, and its event names only the endpoint origin. EconomyBookings sends its card request from its own card vault frame inside the checkout page: the adapters keep a `Referer` on that frame and drop one on the page around it, and the page the request was paused on stays the checkout page. Delta and IHG call an API host of the checkout page's own site, so the endpoint's cookie jar travels as it does for a same-origin profile. `CardEndpointProfile` gains `frame`, and its `encoding` may be `json_api`.
+
+- Recognize four more reviewed merchants whose own checkout page encrypts the card under a key the merchant publishes before it posts the card to the merchant's server: Hyatt (its card token and security code token requests), LifeMiles, Southwest Airlines and United Airlines (mode `card_endpoint`). Their paused requests carry only the dummy card as the page encrypted it, and the adapters handle them exactly as the other fourteen: every profile ships in observe, so each merchant's exact card request is refused as `unsupported_checkout` before any authorization and the dummy card never reaches the merchant. When one of them takes payments, the cardholder's device writes the real card encrypted under the merchant's key Agentcard pinned, so only that merchant can read it.
+
+- Recognize reviewed card forms the merchant's page submits as a page load (a card endpoint profile with `navigation` `top` or `frame`): Athens-Clarke County's MyRec page, Los Angeles and San Francisco on Conduent eTIMS, the D-EDGE card frame and NIC Common Checkout (NJMCdirect and other state agencies), every one in observe. A post with no card on the same URL continues untouched; a card post a script sends is aborted; the reviewed page load pauses, carries only the profile's listed cookies, and is answered with the merchant's page or a 301, 302 or 303 the browser follows in its own session. A 307 or 308 is refused. Every stopped page load gets a small HTML page (`agentcard-checkout` `stopped_before_send`, `sent_answer_not_shown` or `payment_in_progress`) instead of an aborted load; it never says nothing was sent while a payment for the checkout is waiting or may have reached the merchant. `PaymentOutcomeUnknownError` gains `processorRequestStarted`, false once the API confirmed it retired the authorization before any processor request. `CardEndpointSession` gains `navigation` (`top` or `frame`). Once Agentcard enables such a profile, the API takes one payment per merchant checkout and refuses another create for it with `409 merchant_checkout_in_use`, and the page then reads `payment_in_progress`. Matching API and Vault releases are required.
+
+- Recognize Lexicon's FastSpring popup checkout as a reviewed card endpoint, in observe like every other reviewed card endpoint. The adapters read the page a card request pauses on from the popup frame the request came from, let a PayPal or wallet payment on the same URL that carries no card through untouched (`card_endpoint_passed`), and abort FastSpring's EBANX resend of the typed card in every status (`card_endpoint_refused`, reason `card_resend`; the controller reads `unsupported` with reason `merchant_card_endpoint_resend_refused`). They record FastSpring's own record of the order, read-only, and send it with the create cut to its total, currency, test mode and renewal marks; a total or currency other than your integer `amount` throws `AmountMismatchError` with `amountSource: 'merchant_total'`, and a renewing order or a test checkout throws `CardEndpointRefusedError` with the new reason `facts_refused` (`facts_unavailable` when no record was read, when the popup sent a request the SDK does not read the order from after the newest record, or when the checkout sent more requests than the SDK keeps and one it let go could still change the order). A card endpoint answer the device withheld as a step the review refuses (`withheld: 'refused_step_in_response'`) reaches the page as a `502` with code `agentcard_step_refused`. Matching API and Vault releases are required.
+
+- Pay a CyberSource Flex page that gives createToken only seconds (Alaska Airlines' flight checkout gives it three). `prepare({ psp: 'cybersource_flex', environment, tokenizeBeforePay: true })`, called once the card fields show, sends the capture context and fields of the page's one card Microform with the preparation (`PreparedCheckout.cybersourceFlex`), so the cardholder's device tokenizes the card when it approves. At Pay only a field request under that same context and those fields binds (`checkout_changed` otherwise), and the SDK reads the bound authorization every 100 ms for 10 seconds. Refusals before any preparation exists: `microform_not_loaded`, `microform_ambiguous`, `microform_unsupported`, `capture_context_invalid`, `cybersource_environment_mismatch`, and the API's `processor_unavailable`, `sandbox_host_on_live_row` and `live_host_on_sandbox_row`. The matching API and Vault releases are required.
+
+- Pause NMI's hosted payment page (formerly eKashu) for the cardholder's device. The sync now also asks for `capabilities=ekashu_hosted_payment_page`, and the API serves NMI's recognizer only for a company Agentcard turned NMI on for. The SDK pauses the merchant's entry form to `live.ekashu.com` (or `test.ekashu.com`), which carries no card, as a `hosted_form` authorization, and answers the paused navigation with the `submitted_on_device` page once the cardholder's device has paid it. Every other post your browser makes to NMI, its card page's own post and its 3-D Secure calls, carries the card your agent typed: the SDK fails it and reads `unsupported` with reason `processor_card_page`. Matching API and Vault releases are required.
+
+- The preflight catalog identifies NMI's hosted payment page (`ekashu`): a form that posts to `live.ekashu.com` or `test.ekashu.com`, or NMI's card page itself. Agentcard keeps NMI off until it turns it on for a company, so the bundled profile declares no NMI support and the result stays `unknown`. The catalog's `catalog_sha256` changes; `catalog_version` stays `2026-09-15.1`.
+
+## 0.22.0
+
 - A refused amount names what you passed and each amount it can mean, in the forms the API accepts, so an agent can correct its next call. `authorize()` given the string `"2667"` with `usd` throws `amount is an integer in the currency's smallest unit (2306 for $23.06), or a decimal string in normal units ("23.06"). You passed the string "2667". For 26.67 USD, send the number 2667 or the string "26.67". For 2667.00 USD, send the number 266700 or the string "2667.00".` `prepare()` and `prepareCheckout()` add the same sentences to their `amount_required` message. The first sentence is unchanged, so code that matches on it keeps working. The offers use the decimal places the API reads for each currency: none for JPY and MGA, three for KWD, whose amounts end in 0. A value below zero is never offered back as a positive amount, and a value with more digits than any amount is described and never repeated, so a card number typed into the wrong field stays out of your logs.
 
 - **The phone's attestation rides on the key itself** (WP199, 1.3.4). `voice.appKeys.register(key, { user_id })` reads the block from `key.hardware`, where `@agent-cards/voice` 1.9.8's `VoiceHost` puts it, and sends it on as `hardware`; a server that forwards the key description as it came from the phone needs no change. `opts.hardware` still takes a block and wins when both are given. `HardwareAttestation` gains `app_id` (optional), the `<team id>.<bundle id>` an iOS phone names so Agentcard checks the attestation's `rpIdHash` against it; an Android block carries none.
@@ -34,14 +68,6 @@
 
 - Pay a Juspay Express Checkout card payment (Swiggy's website) behind a dark launch. `syncRegistry()` now also declares `juspay_txns.v1`, so the API serves the Juspay recognizer to an org Agentcard has enabled. Both adapters answer the page's `/card/tokenize` locally with a stand-in token and refuse its placeholder `/v2/card/fingerprint` lookup, so the placeholder never reaches Juspay and the page never holds a real card token. The `/txns` that carries the stand-in token pauses, the cardholder's device sends both real requests, and the page receives only Juspay's order id, transaction id, status and bank redirect. Saving the card, EMI, a card number in `/txns` and card requests to `api.juspay.io` or `api-ns1.juspay.in` are aborted as `unsupported_checkout` before an authorization exists, and the controller reads `unsupported` with reason `juspay_request_unsupported`. An approval never answers a `/txns` for another order. Until Agentcard enables Juspay for your org, the SDK does not take over Juspay's requests, and a create for one answers `processor_unavailable`. The matching API and Vault releases are required.
 
-- Pay a CyberSource Flex Microform checkout (Amtrak, Sonos, Learning Without Tears) behind a dark launch. `syncRegistry()` now declares the `capture_context` capability (`SUPPORTED_CAPABILITIES`), and the API serves the Flex recognizer only to an org Agentcard has enabled for it, so every other org's Microform requests go through untouched, as before. Both adapters read the capture context from the card field iframe's URL, verify it offline against CyberSource's pinned signing keys, and send it with the Microform fields on the create; the cardholder's device seals the real card for CyberSource and the field's paused request is answered with the transient token. Only Microform 2.12.1 card fields pause, and a field counts only once its document has loaded: a check Microform continues, any other request on the tokens URL is aborted as `unsupported_checkout` before an authorization exists, and a field the SDK could not read is refused for that request alone. A retry from either field after the field's 30-second timeout is answered from the same approval, and `prepare({ psp: 'cybersource_flex', environment: 'production' | 'sandbox' })` binds one field request. `vault.placeholderCard({ user, cardId })` returns the test number, security code and real expiry to type so the page's own card facts match the stored card; pin its `cardId` on the attachment so the approval page preselects that card. New exports: `SUPPORTED_CAPABILITIES`, `UnsupportedCapabilityError`, `PlaceholderCardError`, and the types `PlaceholderCard`, `MicroformSidecar` and `MicroformField`. The matching API and Vault releases are required.
-
-- Recognize Gravy (Gr4vy) Secure Fields. The registry and the coverage catalog now name the new-card request that updates a checkout session at `/checkout/sessions/<session id>/fields` on the merchant's own `api.<merchant>.gr4vy.app` host, in sandbox and production, with `payment_method.number`, `payment_method.expiration_date` as one `MM/YY` value and `payment_method.security_code`. Gravy publishes this request as an HTTP PUT and the SDK pauses and replays POST requests only, so the recognizer identifies the destination and fills the body but intercepts nothing yet; a PUT on that host continues to Gravy untouched, and the preflight reports Gravy `unsupported` with `request_method_not_supported` in every card scenario until the SDK can intercept that method. The shape follows Gravy's published contract and is not confirmed by a live capture. Updating the session stores the card with Gravy; the merchant creates the transaction on its own server, so a completed request is not a payment. Gravy Embed on `embed.<merchant>.gr4vy.app` is not covered.
-
-- Attach in a browser whose default context runs extensions. A browser extension's service worker or background page, at a `chrome-extension://` URL, no longer counts as a site's worker: `attachToPlaywright` and `attachToCdp` attach beside it, and one that starts later leaves the checkout armed, because an extension's worker never serves the merchant's requests. Cloud browsers such as Anchor run their agent, ad blocker and popup blocker as extensions in the default context, and stock Chrome runs its component extensions there, so that context used to be refused with `Service workers are active` or `checkout_attachment_failed`. A site's own service worker, a shared worker, or a worker with no URL still refuses the context.
-
-- Pay a GMO Payment Gateway checkout (teamLab's ticket sites) behind a dark launch. `syncRegistry()` now declares the `gmo_shared_pk` capability (`SUPPORTED_CAPABILITIES`, now exported), and the API serves the GMO recognizer only to an org Agentcard has enabled for GMO, so no other org's GMO requests are paused or refused. For an enabled org, both adapters pause `mp-token.js`'s `getToken` for one token on `token.mul-pay.jp` or `stg.token.mul-pay.jp`: the cardholder's device sends the card to GMO, and the page receives only GMO's single-use token, reduced to the fields `mp-token.js` reads; any other answer throws `PaymentOutcomeUnknownError` with reason `gmo_token_unconfirmed`. Any other request to that URL (a merchant-registered key, GMO Elements, several tokens, a shop id that does not match the host) and GMO token v1's script request are aborted before anything is created: the attachment reads `unsupported` with reason `unsupported_gmo_request` or `unsupported_gmo_token_v1`, which the `unsupported_checkout` event also carries. A body the SDK cannot read is aborted alone (`blocked`, `unreadable_gmo_request`). The request names no amount, so pass `amount` and `currency`; without them it throws the new `AmountRequiredError` before anything is created. A retry the page sends after losing its request takes the pending approval only when it names the same shop. The matching API release is required; the Vault's GMO path ships separately.
-
 - Pause Elavon Converge's Hosted Payment Page for an org Agentcard enabled for it. NY DMV's payment apps redirect to Converge's own page on `api.convergepay.com` (`api.demo.convergepay.com` for Converge's demo environment), which posts the card as one same-origin JSON request to `/hosted-payments/service/payment/hpp/process`. `syncRegistry()` now declares the `converge_hpp_process` capability, and the API serves the dark recognizer only to an org Agentcard enabled for Converge; every other org's Converge requests continue untouched, as before. A first credit card sale pauses in `token` mode for the cardholder's approval of its own `ssl_amount`, so no `amount` is needed; the cardholder's device sends the real card and the paused request is answered with Converge's approval, rebuilt without the card's expiry, the cardholder's names or any card token. Electronic check and financing payments on the same URL continue untouched. Every other shape is refused in the browser before any create or prompt, with payment-core's own code on the `blocked` event (`ConvergeRefusalReason`): a wallet, the debit, gift card and push-to-card tabs, a follow-up after a 3-D Secure, Pay Defense or surcharge step, a CAPTCHA, a public-sector service fee, recurring or installment fields, card saving (`ssl_get_token`, `ssl_add_token`), a tip or cash back, another currency, and anything that is not the page's own request. A refusal does not hold the attachment, so the page's next payment is judged afresh. Autopilot never pays a Converge payment: it always waits for the cardholder's own approval.
 
 - Worldpay eProtect card registration, behind a dark launch, through a prepared checkout only. A registration is not a payment. The matching API, Vault and relay releases are required.
@@ -57,6 +83,22 @@
 
 - Pay an Amadeus Checkout card step through a prepared checkout, for an org Agentcard enabled for it. Air France and KLM take cards through Amadeus's Checkout Web SDK, whose tunnel iframe posts every action to `paypages.payment.amadeus.com/1ASIATP/ARIAPP/pay`: `load` as the payment step opens, the BIN lookup, and the card `add`. `syncRegistry()` now declares the `amadeus_checkout_actions.v1` capability, and the API serves the dark recognizer only to an enabled org; every other org's Amadeus requests continue untouched, as before. With `prepare({ psp: 'amadeus_checkout', environment: 'production' | 'sandbox' })`, only the add pauses, bound to the prepared page by its `Amadeus-Checkout-Sdk-Host` header. A request the catalog marks as routine without a card now continues before the preparation claim, in both adapters and for every processor, so the page's own `load` no longer spends or blocks a preparation, and Air France's Nuvei payment with a `ccTempToken` after a prepared add continues instead of failing. The tunnel gives up on the add after 30 seconds, so 20 seconds after the pause (`AMADEUS_SEND_WINDOW_MS`) the SDK asks the API to retire the authorization, or, while its create has not answered, the preparation and any request already bound to it (`VaultClient.retirePreparation`). Once the API confirms the card never left the device, the SDK fails the page's request with the controller at `failed` and reason `amadeus_send_window_closed`; when it cannot confirm, the SDK waits for the device's answer. A refused Amadeus request fails as a network error, which the tunnel reports at once, rather than as a cancellation, which it ignores. Air France's and KLM's add is refused before any create or prompt as `amadeus_merchant_held_expiry`, because their own form keeps the expiry, a Data Collection Page store as `amadeus_dcp_field_config_unreviewed`, and an add naming another page as `amadeus_header_binding`, each on the controller's `failed` state. Autopilot never pays an Amadeus payment.
 
+- Pause three more Adyen merchants that take adyen-web's encrypted card on their own server, through merchant profiles in observe: Super Payments (WePrescribe's checkout), CorePower Yoga on Zenoti, and Cathay Pacific. The adapters pause each one's card request, report its shape (a hash of its key paths, never a value) as `merchant_profile_observed` and abort it, so the agent's placeholder card never reaches the merchant. A card sent to Super's save-card request, or to the charge request Cathay posts after signing the card body, is aborted too.
+
+## 0.21.0
+
+- Pay a CyberSource Flex Microform checkout (Amtrak, Sonos, Learning Without Tears) behind a dark launch. `syncRegistry()` now declares the `capture_context` capability (`SUPPORTED_CAPABILITIES`), and the API serves the Flex recognizer only to an org Agentcard has enabled for it, so every other org's Microform requests go through untouched, as before. Both adapters read the capture context from the card field iframe's URL, verify it offline against CyberSource's pinned signing keys, and send it with the Microform fields on the create; the cardholder's device seals the real card for CyberSource and the field's paused request is answered with the transient token. Only Microform 2.12.1 card fields pause, and a field counts only once its document has loaded: a check Microform continues, any other request on the tokens URL is aborted as `unsupported_checkout` before an authorization exists, and a field the SDK could not read is refused for that request alone. A retry from either field after the field's 30-second timeout is answered from the same approval, and `prepare({ psp: 'cybersource_flex', environment: 'production' | 'sandbox' })` binds one field request. `vault.placeholderCard({ user, cardId })` returns the test number, security code and real expiry to type so the page's own card facts match the stored card; pin its `cardId` on the attachment so the approval page preselects that card. New exports: `SUPPORTED_CAPABILITIES`, `UnsupportedCapabilityError`, `PlaceholderCardError`, and the types `PlaceholderCard`, `MicroformSidecar` and `MicroformField`. The matching API and Vault releases are required.
+
+- Pay a GMO Payment Gateway checkout (teamLab's ticket sites) behind a dark launch. `syncRegistry()` now declares the `gmo_shared_pk` capability (`SUPPORTED_CAPABILITIES`, now exported), and the API serves the GMO recognizer only to an org Agentcard has enabled for GMO, so no other org's GMO requests are paused or refused. For an enabled org, both adapters pause `mp-token.js`'s `getToken` for one token on `token.mul-pay.jp` or `stg.token.mul-pay.jp`: the cardholder's device sends the card to GMO, and the page receives only GMO's single-use token, reduced to the fields `mp-token.js` reads; any other answer throws `PaymentOutcomeUnknownError` with reason `gmo_token_unconfirmed`. Any other request to that URL (a merchant-registered key, GMO Elements, several tokens, a shop id that does not match the host) and GMO token v1's script request are aborted before anything is created: the attachment reads `unsupported` with reason `unsupported_gmo_request` or `unsupported_gmo_token_v1`, which the `unsupported_checkout` event also carries. A body the SDK cannot read is aborted alone (`blocked`, `unreadable_gmo_request`). The request names no amount, so pass `amount` and `currency`; without them it throws the new `AmountRequiredError` before anything is created. A retry the page sends after losing its request takes the pending approval only when it names the same shop. The matching API release is required; the Vault's GMO path ships separately.
+
+## 0.20.0
+
+The first release named `@agent-cards/sdk`. `@agent-cards/checkout` has no 0.20.0; from 0.21.0 it re-exports this package. 0.20.0 also carried the 1.0.0 to 1.3.2 sections below, internal build numbers that never reached npm.
+
+- Recognize Gravy (Gr4vy) Secure Fields. The registry and the coverage catalog now name the new-card request that updates a checkout session at `/checkout/sessions/<session id>/fields` on the merchant's own `api.<merchant>.gr4vy.app` host, in sandbox and production, with `payment_method.number`, `payment_method.expiration_date` as one `MM/YY` value and `payment_method.security_code`. Gravy publishes this request as an HTTP PUT and the SDK pauses and replays POST requests only, so the recognizer identifies the destination and fills the body but intercepts nothing yet; a PUT on that host continues to Gravy untouched, and the preflight reports Gravy `unsupported` with `request_method_not_supported` in every card scenario until the SDK can intercept that method. The shape follows Gravy's published contract and is not confirmed by a live capture. Updating the session stores the card with Gravy; the merchant creates the transaction on its own server, so a completed request is not a payment. Gravy Embed on `embed.<merchant>.gr4vy.app` is not covered.
+
+- Attach in a browser whose default context runs extensions. A browser extension's service worker or background page, at a `chrome-extension://` URL, no longer counts as a site's worker: `attachToPlaywright` and `attachToCdp` attach beside it, and one that starts later leaves the checkout armed, because an extension's worker never serves the merchant's requests. Cloud browsers such as Anchor run their agent, ad blocker and popup blocker as extensions in the default context, and stock Chrome runs its component extensions there, so that context used to be refused with `Service workers are active` or `checkout_attachment_failed`. A site's own service worker, a shared worker, or a worker with no URL still refuses the context.
+
 ## 1.3.2
 
 - **`AppVoiceKeyDescription` names no `agreement_public_key`** (WP115, the audit's fourth lane). The key the app copy is sealed for is never a business's to name: the frame mints it and the person's vault proves it at the set-up inside the app. `voice.appKeys.register` sends the signing half alone; the API answers `agreement_key_not_accepted` to a body that still carries one, and `GET /vault/voice/app_copy/:lang` answers `agreement_key_required` until the vault has vouched for the key.

package/PREFLIGHT.md

@@ -179,6 +179,8 @@ The catalog includes reviewed discovery rules and direct SDK implementation capa
 
 Fiserv Commerce Hub is not in the table. Agentcard keeps Fiserv off until it turns it on for a company, so the bundled profile declares no Fiserv support. Fiserv's assets still identify `fiserv`: `payment-fields.js` and `checkout.js` on `commercehub-checkout.fiservapps.com` and the card frame on `commercehub-secure-data-capture.fiservapps.com`, with their `-cert` hosts. The result stays `unknown`, and a page that loads a Fiserv asset beside another processor's reads as `ambiguous`. A company that Agentcard turned Fiserv on for pays it through `prepare()`, as the [README](./README.md) describes.
 
+NMI's hosted payment page (formerly eKashu) is not in the table either. Agentcard keeps NMI off until it turns it on for a company, so the bundled profile declares no NMI support. A merchant form that posts to `live.ekashu.com` or `test.ekashu.com`, or NMI's card page itself, still identifies `ekashu`, and the result stays `unknown`.
+
 Verifone eCommerce is not in the table either, for the same reason. Its `verifone.js` on `us.jsclient.verifone.cloud`, `emea.jsclient.verifone.cloud` and the two sandbox hosts `uscst.jsclient.vficloud.net` and `cst.jsclient.vficloud.net` identifies `verifone`, and the result stays `unknown`. A Verifone page encrypts the card itself and sends it to the merchant's own server, so Agentcard pays it only at a merchant it reviewed.
 
 GMO Payment Gateway (`gmo_pg`) is identified from its token v2 script `mp-token.js` on `static.mul-pay.jp` and `stg.static.mul-pay.jp`, but it is not in this table. It launches dark: the direct SDK pays it only after `syncRegistry()` and only for an org Agentcard has enabled, so the bundled catalog leaves it out and a GMO checkout stays `unknown`, even when your SDK build can pay it. GMO token v1 (`ext/js/token.js`), GMO Elements card frames and Link-type payment pages name their processor and return `unknown` with `processor_variant_unverified`. Read the [GMO section of the README](./README.md#pay-a-gmo-payment-gateway-checkout) for what the SDK covers.
@@ -227,7 +229,7 @@ Amadeus Checkout (`amadeus_checkout`), which Air France and KLM run, ships dark
 | A single processor script during an incomplete scan | `unknown`; `psp` stays `null` and the script remains in `candidates` as `undetermined` until a complete scan confirms it. |
 | Visible card controls in a nested frame on a site no evidenced processor owns | `unknown` with `card_entry_unrecognized`; a co-loaded SDK script is listed as a candidate, not as the processor. |
 
-Reviewed merchant card endpoints are not processors. AT&T, Italo, Universal Orlando, Target Optical and Opus Virtual Offices post the card from their own checkout page to their own server, and the catalog carries no discovery rule for them, so an inspection of their checkout pages preserves `unknown`. The payment adapters recognize each merchant's exact card request (mode `card_endpoint`) and, while its profile is in observe, refuse it as `unsupported_checkout` before any authorization. All five are in observe; an `unknown` result there is not a path to payment.
+Reviewed merchant card endpoints are not processors. AT&T, Italo, Universal Orlando, Target Optical, Opus Virtual Offices, Delta, Hilton, IHG, American Airlines, EconomyBookings, The Verb Hotel, RunSignUp, Mindbody and LookFantastic post the card from their own checkout page to their own server, Hyatt, LifeMiles, Southwest Airlines and United Airlines do the same after their page encrypts it under the merchant's own key, and Lexicon's FastSpring popup posts it to FastSpring's own session URL; the catalog carries no discovery rule for them, so an inspection of their checkout pages preserves `unknown`. The payment adapters recognize each merchant's exact card request (mode `card_endpoint`) and, while its profile is in observe, refuse it as `unsupported_checkout` before any authorization. So are the card forms Athens-Clarke County's MyRec page, Conduent eTIMS, the D-EDGE card frame and NIC Common Checkout submit as a page load. All of them are in observe; an `unknown` result there is not a path to payment.
 
 Processor support does not establish which payment method the merchant selected. Many SDKs also load wallets or fraud checks before a card form appears. Read `checkout_flow_status` and the returned limitations alongside `status`; never present `supported` alone as a promise that a merchant purchase will succeed.
 

package/README.md

@@ -264,7 +264,7 @@ Coverage is specific to the processor request format, merchant setup, browser tr
 | GMO Payment Gateway | dark launch (mode `token`): only for an org Agentcard has enabled; see [Pay a GMO Payment Gateway checkout](#pay-a-gmo-payment-gateway-checkout) |
 | CyberSource Flex Microform | dark launch: Microform 2.12.1 card fields only, after `vault.syncRegistry()`, and only for an org Agentcard has enabled. For any other org the API does not serve the recognizer, so nothing pauses there. The cardholder's device seals the card for CyberSource and the card field receives the transient token. Validated in local Chromium; no live merchant purchase yet. See [Pay a CyberSource Flex Microform checkout](#pay-a-cybersource-flex-microform-checkout) |
 | Juspay Express Checkout | dark launch: the new-card flow Swiggy's website sends from its own page, for an org Agentcard has enabled, after `vault.syncRegistry()`. Validated in local Chromium with no live merchant purchase yet; see [Pay a Juspay checkout](#pay-a-juspay-checkout) |
-| Reviewed merchant card endpoints: AT&T, Italo, Universal Orlando, Target Optical, Opus Virtual Offices | recognized in mode `card_endpoint`, every one in observe: the adapters pause each merchant's own card request and refuse it as `unsupported_checkout` before any authorization, so the dummy card never reaches the merchant. A profile takes payments only after a reviewed partner HAR, a reviewed release of this SDK and the API, and per-org enablement |
+| Reviewed merchant card endpoints: AT&T, Italo, Universal Orlando, Target Optical, Opus Virtual Offices, Delta, Hilton, IHG, American Airlines, EconomyBookings, The Verb Hotel, RunSignUp, Mindbody, LookFantastic, Lexicon (FastSpring's popup checkout), and Hyatt, LifeMiles, Southwest Airlines and United Airlines, whose page encrypts the card under the merchant's own key, and the card forms Athens-Clarke County's MyRec page, Los Angeles and San Francisco on Conduent eTIMS, the D-EDGE card frame and NIC Common Checkout (NJMCdirect and other state agencies) submit as a page load | recognized in mode `card_endpoint`, every one in observe: the adapters pause each merchant's own card request and refuse it as `unsupported_checkout` before any authorization, so the dummy card never reaches the merchant, and a request to the same URL with no card in it continues untouched. A profile takes payments only after a reviewed partner HAR, a reviewed release of this SDK and the API, and per-org enablement |
 | Datatrans Secure Fields (PCI Proxy; British Airways) | dark launch: the card-number iframe's TOKENIZE card post only, after `vault.syncRegistry()`, and only for an org Agentcard has enabled (see [Pay a Datatrans Secure Fields checkout](#pay-a-datatrans-secure-fields-checkout)). The cardholder's device sends the card to Datatrans and the iframe receives the token and its `cardInfo`. A post that asks PCI Proxy to keep the card on file, which British Airways's Nexus checkout sends for every new card, is refused before any prompt while Agentcard's card-on-file policy refuses it, so a Nexus checkout does not complete yet |
 | Authorize.Net Direct Post Method and SIM | dark launch (mode `hosted_form`, capability `authorize_net_dpm_form`): served only to an org Agentcard enabled for it. The card form posts one form navigation to `transact.dll` on `secure2`, `secure` or `test.authorize.net`; the cardholder's device submits it, and you poll the merchant's order state. Not eligible for auto-approval |
 | Pelecard (Iframe/Redirect 2.0) | dark: paused only for an org Agentcard enables for Pelecard, in test mode only. One-time card payments on `gateway21` and `gateway20.pelecard.biz`; pass `amount`, `currency` and the page's total as `pageAmount`. See [Pay a Pelecard checkout](#pay-a-pelecard-checkout) |
@@ -282,7 +282,7 @@ so new processors work without you shipping a release. `attachToCdp` derives the
 `Fetch.enable` url patterns from that same list rather than a constant, which is
 why the sync call belongs before the attach. `agentcard.checkout.cardUrlPatterns()` returns
 those patterns if you arm a CDP connection yourself. Call
-`GET /v2/checkout/recognizers?modes=token,cse,hosted_form,device_encrypt&capabilities=fiserv_card_capture,gmo_shared_pk,capture_context,juspay_txns.v1,datatrans_secure_fields_tokenize,authorize_net_dpm_form,pelecard_transaction,aci_split_card.v1,creditguard_pps_process,primer_payment_instruments,payrails_device_encrypt,converge_hpp_process,worldpay_eprotect_jsonp,wspay_confirm,shiji_sts_pinned_key,amadeus_checkout_actions.v1,worldline_mycheckout_form,verifone_card_capture`
+`GET /v2/checkout/recognizers?modes=token,cse,hosted_form,device_encrypt&capabilities=fiserv_card_capture,gmo_shared_pk,capture_context,juspay_txns.v1,datatrans_secure_fields_tokenize,authorize_net_dpm_form,pelecard_transaction,aci_split_card.v1,creditguard_pps_process,primer_payment_instruments,payrails_device_encrypt,converge_hpp_process,worldpay_eprotect_jsonp,wspay_confirm,shiji_sts_pinned_key,amadeus_checkout_actions.v1,worldline_mycheckout_form,verifone_card_capture,ekashu_hosted_payment_page`
 for the list this build syncs. The API serves Fiserv's card capture only to a
 build that lists `fiserv_card_capture`, and only for a company Agentcard turned
 Fiserv on for. An older SDK never pauses a Fiserv request it could not finish,
@@ -298,7 +298,11 @@ confirm behind `wspay_confirm`, Shiji STS's card leg behind
 `amadeus_checkout_actions.v1`, Worldline MyCheckout's card form behind
 `worldline_mycheckout_form`, and Payrails' card save behind
 `payrails_device_encrypt` to a build that also asks for `device_encrypt`. The
-same holds for the Verifone profiles and `verifone_card_capture`.
+same holds for the Verifone profiles and `verifone_card_capture`. NMI's hosted
+payment page (`ekashu_hosted_payment_page`) is served on the same terms: this
+build pauses the merchant's entry form to `live.ekashu.com` for the
+cardholder's device and fails every other post your browser makes to NMI, so
+NMI never sees the card your agent typed.
 
 ## Modes
 
@@ -420,17 +424,28 @@ mode; the difference matters if you drive `authorize()` yourself.
   page's origin, the exact origin, path and query of the card request, the
   session headers and cookies it needs, and the answer headers that may come
   back. The adapters arm every profile's endpoint (`cardEndpointPatterns()`
-  lists the `Fetch.enable` patterns) and pause a POST that is exactly a
-  profile's card request; a GET, a CORS preflight or a look-alike URL
-  continues untouched. While this build's copy of a profile does not take
-  payments (all five are in observe today) the request is refused as
-  `unsupported_checkout` and the controller reads `unsupported` with reason
-  `merchant_card_endpoint_not_enabled`, before any authorization exists. For a
+  lists the `Fetch.enable` patterns) and pause a POST to exactly a profile's
+  card request URL when it carries a card: anything at the profile's card
+  number field, or a Luhn-valid number of 12 to 19 digits anywhere in the
+  body, however it is written. A body the adapter cannot read counts as
+  carrying one. A GET, a CORS preflight, a look-alike URL, or a POST to the
+  same URL with no card in it (an IHG stay paid with points, a LookFantastic
+  order whose card a processor's own fields tokenized, a saved card, a room
+  another SynXis hotel guarantees with a token) continues untouched. While this
+  build's copy of a profile does not take payments (every profile is in
+  observe today) a card request is refused as `unsupported_checkout` before
+  any authorization exists. When the body is the request the profile
+  reviewed, the controller reads `unsupported` with reason
+  `merchant_card_endpoint_not_enabled` and the event names the profile; a
+  card in any other body reads reason `unrecognized_payment_endpoint`, and
+  the event names only the endpoint origin. For a
   profile that takes payments, the adapter captures the request's session:
   the profile's own header names from the paused request, the endpoint's
   cookie jar for a cookie profile (`Network.getCookies` or
   `context.cookies()`, since the paused headers never carry it), and a
-  `Referer` only when it is a page on the checkout origin. It sends them with
+  `Referer` only when it is a page on the origin the request is sent from: the
+  merchant's own card vault frame when the profile names one (EconomyBookings),
+  else the checkout page. It sends them with
   the paused body, which holds only the dummy card, in the create's
   `merchant_card_endpoint` member, never in `request`, and checks them first
   with the same rules the API and the device run. The cardholder's device
@@ -456,10 +471,71 @@ mode; the difference matters if you drive `authorize()` yourself.
   approval never outlives its request: a card request the page gives up on
   retires the authorization. After the hand-off the attachment holds, so the
   page's retry of the card request, or a step-up that sends the card again,
-  is refused until you reconcile the order. Card endpoint events name the
+  is refused until you reconcile the order.
+
+  Lexicon sells through FastSpring's popup checkout, which needs four more
+  rules. The card is typed into FastSpring's frame on the store's own host
+  inside Lexicon's page, so the page a card request pauses on is that frame's
+  document (the frame tree in CDP, `request.frame()` in Playwright). FastSpring
+  posts PayPal and wallet payments to the same URL: a body whose `paymentType`
+  names another method and that carries no card continues untouched, and the
+  adapters emit `card_endpoint_passed`; one that names another method but
+  carries a card is held like any card request. FastSpring's EBANX step,
+  which reads the typed card back and posts it to `/3ds/return-ebanx`, is
+  aborted in every status
+  (`card_endpoint_refused` with reason `card_resend`, the controller reads
+  `unsupported` with reason `merchant_card_endpoint_resend_refused`); the
+  device withholds the answer that would start it, which the paused request
+  receives as a fixed `502` with code `agentcard_step_refused`. And the SDK
+  records FastSpring's own record of the order, read-only, from the popup
+  document and each JSON answer its page reads the order from, a quantity or
+  add-on change included. When the card request pauses it sends the newest one
+  with the create, cut to the total with tax, the currency, test mode and the
+  renewal marks; a total or currency other than your integer `amount` is an
+  `AmountMismatchError` against the merchant's total, and a renewing order or
+  a checkout in FastSpring's test mode is refused as `facts_refused`, both
+  before any authorization. A request the popup sends on the same checkout
+  after that record, other than one the SDK reads the order from or
+  FastSpring's customer recognition, leaves the order unknown: the payment is
+  refused as `facts_unavailable`, and a reload of the popup reads it again. The
+  SDK keeps 32 of these requests. A checkout that sends more is refused the
+  same way when one the SDK let go could be newer than the record it read, and
+  for the rest of that checkout session once one went while still loading. Card
+  endpoint events name the
   `profile` and the `endpoint` origin, never the request's URL, body or
   session: the URL carries the merchant's cart and booking ids.
 
+  Some of these merchants' pages submit the card form as a page load rather
+  than a fetch: the profile's `navigation` is `top`, or `frame` for a form
+  inside an iframe, which is then judged by the iframe's own document. The
+  same URL takes the page's other posts, so a post whose card fields are
+  empty and that holds no card number (a Cancel button, another payment
+  method) continues untouched in any status, and a card post a script sends
+  is aborted, since no page waits on it. The reviewed page load pauses, its
+  session carries only the cookie names the profile lists, and the
+  merchant's answer comes back as a page load: its page, or a 301, 302 or
+  303 your browser follows in its own session with the merchant's cookies
+  written first. A 307 or 308 would make the browser post the typed form
+  again, so it is refused. Every stopped page load (a profile in observe, a
+  post that is not the reviewed form, a declined approval, an approval
+  already outstanding, a refused redirect, a withheld answer) is answered
+  with a small HTML page instead of an aborted load. Its
+  `<meta name="agentcard-checkout">`, its `x-agentcard-checkout` header and
+  its JSON block (`#agentcard-checkout`) say one of three outcomes.
+  `stopped_before_send`: nothing reached the merchant, and no other payment
+  for this checkout is waiting. `sent_answer_not_shown`: the card reached the
+  merchant, so check the payment with the merchant before paying again.
+  `payment_in_progress`: a payment for this checkout is waiting for approval
+  or may have reached the merchant, so check that payment and never send the
+  form again. The page reads `payment_in_progress` while an approval is
+  outstanding (the cardholder's device sends the card before it approves),
+  after a payment this attachment handed over or cannot account for, and when
+  the API refuses the create with `409 merchant_checkout_in_use`, as it does
+  on every later post of that attachment. A local deadline whose
+  authorization the API confirms it retired before any processor request
+  reads `stopped_before_send`: the `PaymentOutcomeUnknownError` then carries
+  `processorRequestStarted: false`.
+
 `syncRegistry()` asks the API for `SUPPORTED_MODES` only
 (`token,cse,hosted_form,device_encrypt`), so a processor whose flow this build
 cannot finish is never paused; the API serves `hosted_form` and `device_encrypt`
@@ -764,8 +840,11 @@ is gone resolves as `PaymentOutcomeUnknownError` with reason
   `amount_required`, `approval_required` (the attachment asks for
   Autopilot), `preparation_unsupported`, or `request_unsupported` (the
   paused request is not the card request Agentcard reviewed; `detail` names
-  fields, never values). Every reason but `request_unsupported` holds the
-  attachment. The adapters also emit `card_endpoint_refused` with the
+  fields, never values), `facts_unavailable` (the merchant keeps its own
+  record of the order and this runtime read none for this checkout) or
+  `facts_refused` (that record says the order renews, or that the checkout is
+  in test mode). Every reason but `request_unsupported`, `facts_unavailable`
+  and `facts_refused` holds the attachment. The adapters also emit `card_endpoint_refused` with the
   profile, the endpoint origin and the reason.
 - `PageAmountRequiredError` (`code: 'page_amount_required'`, `psp`): the paused
   request names no amount and no page total reached the SDK. For Pelecard the
@@ -1246,8 +1325,8 @@ event, `unreadable_gmo_request`, and the next one is judged again.
 
 ### Pay a CyberSource Flex Microform checkout
 
-Amtrak, Sonos and Learning Without Tears take cards in CyberSource Flex
-Microform. Each card field is CyberSource's own iframe, and on createToken the
+Amtrak, Sonos, Learning Without Tears and Alaska Airlines take cards in
+CyberSource Flex Microform. Each card field is CyberSource's own iframe, and on createToken the
 field seals what the agent typed into a JWE under a capture context the merchant
 minted for this checkout. Nothing in that body can be swapped, so the
 cardholder's device seals the real card under the same context and sends it to
@@ -1318,6 +1397,32 @@ const checkout = await attachToPlaywright(page, {
   agent types the last card field; `sandbox` is `testflex.cybersource.com` with
   CyberSource's test keys, and a test capture context pays only from a test
   client.
+- **Seconds, not thirty.** Some pages race createToken against a timer of
+  their own: Alaska Airlines' flight checkout gives it three seconds, then
+  shows "Token creation timed out". After Pay, the cardholder's device would
+  still have to seal the card and reach CyberSource, and the SDK's first read
+  comes two seconds after the create. For such a page, prepare once the card
+  fields show, with `tokenizeBeforePay`:
+
+  ```ts
+  // The agent has typed the placeholder card and the expiry; the fields are loaded.
+  const prepared = await checkout.prepare({ psp: 'cybersource_flex', environment: 'production', tokenizeBeforePay: true });
+  await page.getByRole('button', { name: 'Pay', exact: true }).click();
+  ```
+
+  The attachment reads the capture context and the fields of the one card
+  Microform on the page and sends them with the preparation. When the
+  cardholder approves, their device seals the card under that context, gets
+  CyberSource's transient token and keeps it; at Pay the SDK binds the field's
+  request, reads every 100 ms for 10 seconds, and answers the page as soon as
+  the device hands the token over. Only a request from the same fields, under
+  the same capture context, binds: a page that loads its fields again (Alaska
+  refreshes its context every 15 minutes) fails with `checkout_changed`, so
+  prepare again. `prepare()` is refused before any preparation exists with
+  `microform_not_loaded` (no card field yet), `microform_ambiguous` (two card
+  Microforms), `microform_unsupported`, `capture_context_invalid` or
+  `cybersource_environment_mismatch`. The token the device holds authorizes
+  nothing on its own: if the agent never clicks Pay, it expires unused.
 - **One createToken per purchase.** A prepared approval binds one request. On
   Amtrak, leave "add to profile" unticked or check out as a guest: that box
   calls createToken a second time before Pay.

package/dist/adyen-merchant-hosted.generated.d.ts

@@ -1,6 +1,7 @@
 declare var MERCHANT_EXCHANGES_MAX: number;
 declare var MERCHANT_PROFILE_RECOGNIZERS: any;
 declare function declaredEndpointRefusal(endpoint: any): string | null;
+declare function isAdyenWebJweCompact(s: any): boolean;
 declare function sha256Hex(input: any): string;
 declare function merchantAmountFromResponses(profile: any, input: any): {
     ok: boolean;
@@ -274,4 +275,4 @@ declare function declaredUrlGlobs(endpoint: any): string[];
 declare function merchantProfileRulesMatch(profileId: any, served: any): boolean;
 declare function merchantProfileEnvironment(profileId: any): "production" | "sandbox";
 declare function merchantProfileEndpointFor(profileId: any, checkoutOrigin: any): string | null;
-export { MERCHANT_EXCHANGES_MAX, MERCHANT_PROFILE_RECOGNIZERS, carriesAdyenCardCiphertext, classifyDeclaredMerchantRequest, classifyMerchantBody, classifyMerchantRequest, declaredEndpointRefusal, declaredTemplatedUrl, declaredUrlGlobs, declaredUrlRelation, merchantAmountExchanges, merchantAmountFromResponses, merchantAmountPending, merchantAmountStagesOf, merchantBodyKeyPathSha256, merchantChargedFromResponses, merchantProfileEndpointFor, merchantProfileEnvironment, merchantProfileRulesMatch, merchantProfileTemplatedUrl, merchantProfileUrlGlobs, merchantProfileUrlRelation, merchantTotalFromResponses, sha256Hex };
+export { MERCHANT_EXCHANGES_MAX, MERCHANT_PROFILE_RECOGNIZERS, carriesAdyenCardCiphertext, classifyDeclaredMerchantRequest, classifyMerchantBody, classifyMerchantRequest, declaredEndpointRefusal, declaredTemplatedUrl, declaredUrlGlobs, declaredUrlRelation, isAdyenWebJweCompact, merchantAmountExchanges, merchantAmountFromResponses, merchantAmountPending, merchantAmountStagesOf, merchantBodyKeyPathSha256, merchantChargedFromResponses, merchantProfileEndpointFor, merchantProfileEnvironment, merchantProfileRulesMatch, merchantProfileTemplatedUrl, merchantProfileUrlGlobs, merchantProfileUrlRelation, merchantTotalFromResponses, sha256Hex };

package/dist/adyen-merchant-hosted.generated.js

@@ -1,6 +1,6 @@
 // @ts-nocheck
 // Generated from @agent-cards/payment-core. Do not edit.
-// artifact-sha256: 83b01fa41dce013a97e4daf34de13d53978f6ef972e0328c67b3380f057b4e17
+// artifact-sha256: c979802cf1a5aa95eedd5dd00949cd56c5c478ca3c637b3232b69597cc62d4a4
 // src/deep-freeze.js
 function deepFreeze(value) {
     if (value && typeof value === "object" && !Object.isFrozen(value)) {
@@ -79,9 +79,14 @@ var PLACEHOLDER_NAME = /^[A-Za-z][A-Za-z0-9_]{0,31}$/;
 var LITERAL_SEGMENT = /^[A-Za-z0-9._~@+-]{1,256}$/;
 var QUERY_KEY = /^[A-Za-z0-9._~-]{1,64}$/;
 var QUERY_LITERAL = /^[A-Za-z0-9._~,-]{0,256}$/;
+var QUERY_PREFIX = /^(?:[A-Za-z0-9._~,-]|%[0-9A-F]{2}){1,64}$/;
 var MAX_QUERIES = 8;
 var MAX_PAIRS = 16;
 var placeholderValue = (value) => PLACEHOLDER_VALUE.test(value) && value !== "." && !value.includes("..");
+function queryPlaceholder(value) {
+    const mark = value.lastIndexOf(":");
+    return mark === -1 ? null : { prefix: value.slice(0, mark), name: value.slice(mark + 1) };
+}
 function pathPlaceholders(template, pathname) {
     if (typeof template !== "string" || typeof pathname !== "string")
         return null;
@@ -126,10 +131,14 @@ function queryPlaceholders(query, text) {
         const written = got[i].slice(mark + 1);
         if (typeof value !== "string")
             return null;
-        if (value.startsWith(":")) {
-            if (!placeholderValue(written))
+        const placeholder = queryPlaceholder(value);
+        if (placeholder) {
+            if (!written.startsWith(placeholder.prefix))
+                return null;
+            const rest = written.slice(placeholder.prefix.length);
+            if (!placeholderValue(rest))
                 return null;
-            values[value.slice(1)] = written;
+            values[placeholder.name] = rest;
         }
         else if (written !== value) {
             return null;
@@ -178,9 +187,11 @@ function templatePlaceholders(template) {
     const queries = Array.isArray(template?.queries) ? template.queries : [template?.query];
     for (const query of queries) {
         if (query && typeof query === "object") {
-            for (const value of Object.values(query))
-                if (typeof value === "string" && value.startsWith(":"))
-                    names.push(value.slice(1));
+            for (const value of Object.values(query)) {
+                const placeholder = typeof value === "string" ? queryPlaceholder(value) : null;
+                if (placeholder)
+                    names.push(placeholder.name);
+            }
         }
     }
     return names;
@@ -215,7 +226,8 @@ function queryTemplateRefusal(query) {
             return `the query key "${key}" is not unreserved characters`;
         if (typeof value !== "string")
             return `the query value of ${key} is not text`;
-        if (value.startsWith(":") ? !PLACEHOLDER_NAME.test(value.slice(1)) : !QUERY_LITERAL.test(value)) {
+        const placeholder = queryPlaceholder(value);
+        if (placeholder ? !PLACEHOLDER_NAME.test(placeholder.name) || placeholder.prefix !== "" && !QUERY_PREFIX.test(placeholder.prefix) : !QUERY_LITERAL.test(value)) {
             return `the query value of ${key} is neither a literal nor a :name placeholder`;
         }
     }
@@ -1628,40 +1640,38 @@ function merchantBodyRefusal(profile, body) {
     return null;
 }
 // src/adyen-jwe.js
-var ADYEN_JWE_HEADER = { alg: "RSA-OAEP-256", enc: "A256GCM", version: "1" };
 var BASE64URL = /^[A-Za-z0-9_-]+$/;
-function isAdyenJweCompact(s) {
-    if (typeof s !== "string" || s.length > 2048)
-        return false;
-    const parts = s.split(".");
-    if (parts.length !== 5)
-        return false;
-    const [header, encryptedKey, iv, ciphertext, tag] = parts;
-    if (!parts.every((p) => p.length > 0 && BASE64URL.test(p)))
-        return false;
-    if (encryptedKey.length !== 342 || iv.length !== 16 || tag.length !== 22)
-        return false;
-    if (ciphertext.length > 1024)
-        return false;
-    return isAdyenJweHeader(header);
-}
-function isAdyenJweHeader(segment) {
-    if (!BASE64URL.test(segment) || segment.length > 128)
-        return false;
+var ADYEN_WEB_JWE_FORMATS = /* @__PURE__ */ Object.freeze([
+    /* @__PURE__ */ Object.freeze({ alg: "RSA-OAEP-256", enc: "A256GCM", iv: 16, tag: 22 }),
+    /* @__PURE__ */ Object.freeze({ alg: "RSA-OAEP", enc: "A256CBC-HS512", iv: 22, tag: 43 })
+]);
+var ADYEN_WEB_CIPHERTEXT_MAX = 8192;
+var ADYEN_WEB_HEADER_MAX = 128;
+function adyenWebJweHeader(segment) {
+    if (!BASE64URL.test(segment) || segment.length > ADYEN_WEB_HEADER_MAX)
+        return null;
     let parsed;
     try {
         parsed = JSON.parse(new TextDecoder().decode(Uint8Array.from(atob(segment.replace(/-/g, "+").replace(/_/g, "/")), (c) => c.charCodeAt(0))));
     }
     catch {
-        return false;
+        return null;
     }
     if (!parsed || typeof parsed !== "object" || Array.isArray(parsed))
+        return null;
+    return Object.keys(parsed).sort().join(",") === "alg,enc,version" && parsed.version === "1" ? parsed : null;
+}
+function isAdyenWebJweCompact(s) {
+    if (typeof s !== "string" || s.length > ADYEN_WEB_HEADER_MAX + 342 + 22 + ADYEN_WEB_CIPHERTEXT_MAX + 43 + 4)
         return false;
-    const obj = parsed;
-    const keys = Object.keys(obj).sort();
-    if (keys.join(",") !== "alg,enc,version")
+    const parts = s.split(".");
+    if (parts.length !== 5 || !parts.every((p) => p.length > 0 && BASE64URL.test(p)))
+        return false;
+    const [header, encryptedKey, iv, ciphertext, tag] = parts;
+    if (encryptedKey.length !== 342 || ciphertext.length > ADYEN_WEB_CIPHERTEXT_MAX)
         return false;
-    return obj.alg === ADYEN_JWE_HEADER.alg && obj.enc === ADYEN_JWE_HEADER.enc && obj.version === ADYEN_JWE_HEADER.version;
+    const parsed = adyenWebJweHeader(header);
+    return parsed !== null && ADYEN_WEB_JWE_FORMATS.some((form) => parsed.alg === form.alg && parsed.enc === form.enc && iv.length === form.iv && tag.length === form.tag);
 }
 // src/sha256.js
 var K = /* @__PURE__ */ new Uint32Array([
@@ -1861,16 +1871,18 @@ function merchantProfileUrlRelation(profileId, rawUrl) {
         return "then";
     return otherCardRequestOf(profile, url) ? "other" : null;
 }
-var JWE_AT = /ey[A-Za-z0-9_-]{1,126}\.[A-Za-z0-9_-]{342}\.[A-Za-z0-9_-]{16}\.[A-Za-z0-9_-]{1,1024}\.[A-Za-z0-9_-]{22}/y;
+var JWE_AT = /* @__PURE__ */ ADYEN_WEB_JWE_FORMATS.map(({ iv, tag }) => new RegExp(`ey[A-Za-z0-9_-]{1,126}\\.[A-Za-z0-9_-]{342}\\.[A-Za-z0-9_-]{${iv}}\\.[A-Za-z0-9_-]{1,${ADYEN_WEB_CIPHERTEXT_MAX}}\\.[A-Za-z0-9_-]{${tag}}`, "y"));
 var LEGACY_BLOB = /adyenjs_0_1_\d{1,4}(?:\$|%24)/i;
 function textCarriesCiphertext(text) {
     if (LEGACY_BLOB.test(text))
         return true;
     for (let at = text.indexOf("ey"); at !== -1; at = text.indexOf("ey", at + 1)) {
-        JWE_AT.lastIndex = at;
-        const match = JWE_AT.exec(text);
-        if (match && isAdyenJweCompact(match[0]))
-            return true;
+        for (const pattern of JWE_AT) {
+            pattern.lastIndex = at;
+            const match = pattern.exec(text);
+            if (match && isAdyenWebJweCompact(match[0]))
+                return true;
+        }
     }
     return false;
 }
@@ -1935,7 +1947,7 @@ function holderRefusal(profile, parsed) {
         return `the paused body carries no card object where ${profile.merchant}'s card request holds it`;
     }
     const values = Object.values(profile.fields).map((name) => Object.prototype.hasOwnProperty.call(holder.value, name) ? holder.value[name] : void 0);
-    if (!values.every((value) => typeof value === "string" && isAdyenJweCompact(value))) {
+    if (!values.every((value) => typeof value === "string" && isAdyenWebJweCompact(value))) {
         return `the paused body does not carry the four encrypted card fields ${profile.merchant}'s card request holds a new card in`;
     }
     if (new Set(values).size !== values.length)
@@ -2133,4 +2145,4 @@ function merchantProfileEndpointFor(profileId, checkoutOrigin) {
     const query = Object.entries(profile.query).map(([key, value]) => `${key}=${value}`).join("&");
     return `${pair.endpoint}${profile.path}${query ? `?${query}` : ""}`;
 }
-export { MERCHANT_EXCHANGES_MAX, MERCHANT_PROFILE_RECOGNIZERS, carriesAdyenCardCiphertext, classifyDeclaredMerchantRequest, classifyMerchantBody, classifyMerchantRequest, declaredEndpointRefusal, declaredTemplatedUrl, declaredUrlGlobs, declaredUrlRelation, merchantAmountExchanges, merchantAmountFromResponses, merchantAmountPending, merchantAmountStagesOf, merchantBodyKeyPathSha256, merchantChargedFromResponses, merchantProfileEndpointFor, merchantProfileEnvironment, merchantProfileRulesMatch, merchantProfileTemplatedUrl, merchantProfileUrlGlobs, merchantProfileUrlRelation, merchantTotalFromResponses, sha256Hex };
+export { MERCHANT_EXCHANGES_MAX, MERCHANT_PROFILE_RECOGNIZERS, carriesAdyenCardCiphertext, classifyDeclaredMerchantRequest, classifyMerchantBody, classifyMerchantRequest, declaredEndpointRefusal, declaredTemplatedUrl, declaredUrlGlobs, declaredUrlRelation, isAdyenWebJweCompact, merchantAmountExchanges, merchantAmountFromResponses, merchantAmountPending, merchantAmountStagesOf, merchantBodyKeyPathSha256, merchantChargedFromResponses, merchantProfileEndpointFor, merchantProfileEnvironment, merchantProfileRulesMatch, merchantProfileTemplatedUrl, merchantProfileUrlGlobs, merchantProfileUrlRelation, merchantTotalFromResponses, sha256Hex };