@agent-cards/sdk 0.23.20 → 0.23.22

package/dist/pre-claim.js

@@ -7,7 +7,8 @@
 // the vault can never pay, CyberSource Flex Microform's field iframes (whose
 // capture context rides into the pause), Datatrans Secure Fields, whose
 // card URL also carries card posts the device could never fill and card posts
-// it already answered, and Pelecard's card submission URL, which also carries
+// it already answered, the TokenEx hosted iframe v3, whose card path carries the
+// same two, and Pelecard's card submission URL, which also carries
 // saved-token, wallet and keep-on-file bodies, Primer's
 // /payment-instruments, which also carries requests the vault can never pay,
 // Payrails, whose save needs the session key the page captured and whose
@@ -63,6 +64,7 @@ import { gmoRequestRefusal, isGmoTokenHost, isGmoTokenV1Request, recognizesGmo }
 import { JUSPAY_PSP } from './juspay-gate.js';
 import { datatransPauseDecision, isDatatransHost } from './datatrans.js';
 import { DATATRANS_INVALID_REQUEST } from './datatrans.generated.js';
+import { INVALID_TOKENEX_IFRAME_REQUEST, TOKENEX_IFRAME_PSP, isTokenexIframePath, servesTokenexIframe, tokenexIframePauseDecision, } from './tokenex-iframe.js';
 import { isPelecardHost, pelecardRefusal } from './pelecard.js';
 import { ACI_CHECKOUT_REUSED } from './aci.js';
 import { ACI_EXPIRY_UNSTRIPPABLE } from './aci.generated.js';
@@ -79,8 +81,12 @@ import { cardEndpointStoppedPage, refusedNavigationOutcome } from './card-endpoi
 import { PAYRAILS_HOLDING_REASONS, PAYRAILS_SESSION_MESSAGE, isPayrailsHost, isPayrailsPaymentUrl, isPayrailsStaticHost, payrailsKeyRefusal, payrailsPaymentRefusal, payrailsRequestKind, payrailsSaveRefusal, } from './payrails.js';
 import { classifyVerifoneProfileRequest, verifoneTemplatedUrl } from './verifone.js';
 import { ekashuEntryUrl, isEkashuEntry, isEkashuHost } from './ekashu.js';
+import { isArmedTransbankUrl } from './transbank.js';
 import { isRedsysEntry, isRedsysHost, redsysEntryUrl } from './redsys.js';
+import { isArmedPrzelewy24Url, isPrzelewy24PayStep } from './przelewy24.js';
 import { isQuickpayCardLookup, isQuickpayEntry, quickpayEntryUrl } from './quickpay.js';
+import { isArmedComgateUrl } from './comgate.js';
+import { isArmedEximbayUrl, isEximbayEntry } from './eximbay.js';
 import { PAYPAL_HOSTED_FIELDS_REASON, isPaypalHostedFieldsConfirm, paypalHostedFieldsBody } from './paypal-hosted-fields.js';
 import { PAYPAL_CARD_FIELDS_REASON, PAYPAL_GUEST_CHECKOUT_REASON, isPaypalCardFieldsConfirm, isPaypalGraphql, paypalCardFieldsBody, paypalGraphqlCard, paypalGraphqlNamesCardOperation, } from './paypal-card-forms.js';
 import { CYBERSOURCE_SECURE_ACCEPTANCE_REASON, CYBERSOURCE_SECURE_ACCEPTANCE_RECIPIENT, cybersourceSecureAcceptanceRequest, isCybersourceSecureAcceptanceUrl, isSecureAcceptanceFramePost, } from './cybersource-secure-acceptance.js';
@@ -88,6 +94,7 @@ import { isWorldlineMyCheckoutEndpoint } from './worldline-mycheckout.js';
 import { paddleVgsPayEventUrl } from './paddle-vgs-pay.js';
 import { HIPAY_PSP, HIPAY_TOKEN_URLS, HIPAY_UPDATE_PATH, HIPAY_VAULT_HOSTS, hipayNumberOnlyRequest } from './hipay.generated.js';
 import { EBANX_RESEND_REASON, EbanxFollowUpError, ebanxResendRefusalOf, isEbanxResendUrl, } from './ebanx.js';
+import { PAYREXX_RESEND_REASON, PayrexxFollowUpError, isPayrexxResend, } from './payrexx.js';
 /**
  * The URL an event may name for a request. For an armed merchant profile's
  * endpoint or a sibling of it: the endpoint origin, the path TEMPLATE and the
@@ -817,10 +824,10 @@ async function juspayUnsupported(ctx, reason) {
 // card-on-file policy the API served with the recognizer (VaultClient.cardOnFilePolicy):
 //   - a sound TOKENIZE card post defers, and the arbiter pauses it for approval, unless the same
 //     frame's same form was already answered with an approved token (the repeat rule) and that
-//     approval is still the one being handed off (datatransRepeatApproval): then that stored answer
+//     approval is still the one being handed off (handoffRepeatApproval): then that stored answer
 //     is fulfilled here, with no claim, create or prompt. Once the answer reached the page, the
 //     application's merchant resolver must first report the order still pending
-//     (datatransRepeatAfterHandoff);
+//     (repeatAfterHandoff);
 //   - a card post the API would refuse at create aborts with a `blocked` event that names the
 //     API's own code, `invalid_datatrans_request` or `datatrans_card_on_file_refused` (the latter
 //     only while the served policy refuses card on file), before anything is claimed, created or
@@ -848,25 +855,26 @@ const datatransPreClaim = (ctx) => {
         return undefined;
     if (decision !== 'card')
         return datatransBlock(ctx, decision);
-    const approval = datatransRepeatApproval(ctx);
+    const approval = handoffRepeatApproval(ctx);
     const repeat = approval === null ? null : ctx.datatrans?.answerFor(ctx.frame, url, ctx.request.body, approval) ?? null;
     if (!repeat)
         return undefined;
-    return ctx.lifecycle.getState().status === 'awaiting_merchant' ? datatransRepeatAfterHandoff(ctx, repeat) : datatransRepeat(ctx, repeat);
+    return ctx.lifecycle.getState().status === 'awaiting_merchant' ? repeatAfterHandoff(ctx, repeat, 'datatrans') : answerRepeat(ctx, repeat, 'datatrans');
 };
 /**
- * The approval whose stored Datatrans answer a repeat may still receive, or null. A stored token
+ * The approval whose stored Datatrans or TokenEx answer a repeat may still receive, or null. A stored token
  * answers a re-submit only while the approval it came from is still being handed off: the lifecycle
  * names it and reads awaiting_approval (its answer is being delivered) or awaiting_merchant (the
  * merchant has not confirmed yet), and nothing latched, tore down or cancelled the attachment. The
  * order completing or failing, an unknown outcome, a decline, a hold for the cardholder, a retry
  * after a merchant failure and a new authorization all end it, and the re-submit is then a new
- * question for the terminal arbiter, which holds or pauses it like any card post: TOKENIZE binds no
- * amount, so one approval never answers for a later purchase. Once the answer reached the page
- * (awaiting_merchant), the gate also reconciles before it answers (datatransRepeatAfterHandoff), and
- * the stored answer itself ends once its form goes quiet (DatatransRepeats, DATATRANS_REPEAT_IDLE_MS).
+ * question for the terminal arbiter, which holds or pauses it like any card post: neither card post
+ * binds an amount, so one approval never answers for a later purchase. Once the answer reached the
+ * page (awaiting_merchant), the gate also reconciles before it answers (repeatAfterHandoff). A stored
+ * Datatrans answer also ends once its form goes quiet (DatatransRepeats, DATATRANS_REPEAT_IDLE_MS), and
+ * a stored TokenEx answer once its iframe key expires (TokenexIframeRepeats).
  */
-function datatransRepeatApproval(ctx) {
+function handoffRepeatApproval(ctx) {
     if (ctx.terminal() || ctx.interceptionAborted() || ctx.lifecycleAborted())
         return null;
     const { status, authorizationId } = ctx.lifecycle.getState();
@@ -883,36 +891,82 @@ function datatransRepeatApproval(ctx) {
  * arbiter, and so does every re-submit on an attachment with no resolver: a later purchase never
  * receives an earlier token without the cardholder, and the paused post never waits on a stalled read.
  */
-function datatransRepeatAfterHandoff(ctx, repeat) {
+function repeatAfterHandoff(ctx, repeat, psp) {
     if (!ctx.lifecycle.hasMerchantResolver())
         return undefined;
-    return datatransPendingRepeat(ctx, repeat);
+    return pendingRepeat(ctx, repeat, psp);
 }
-async function datatransPendingRepeat(ctx, repeat) {
+async function pendingRepeat(ctx, repeat, psp) {
     if (!await ctx.lifecycle.merchantOrderPending())
         return undefined;
     // The resolver answered asynchronously: the checkout must still be handing off this approval.
-    if (ctx.lifecycle.getState().status !== 'awaiting_merchant' || datatransRepeatApproval(ctx) !== repeat.authorizationId)
+    if (ctx.lifecycle.getState().status !== 'awaiting_merchant' || handoffRepeatApproval(ctx) !== repeat.authorizationId)
         return undefined;
-    return datatransRepeat(ctx, repeat);
+    return answerRepeat(ctx, repeat, psp);
 }
 async function datatransBlock(ctx, reason) {
     ctx.onEvent?.({ type: 'blocked', detail: reason });
     await ctx.effects.abort();
     return { kind: 'abort' };
 }
-async function datatransRepeat(ctx, repeat) {
+/** Fulfill a repeat with the stored answer (`repeat_answered`), or abort it when the browser cannot take it (`<psp>_repeat_unanswered`). */
+async function answerRepeat(ctx, repeat, psp) {
     try {
         await ctx.effects.answer(repeat.response);
     }
     catch {
-        ctx.onEvent?.({ type: 'blocked', detail: 'datatrans_repeat_unanswered' });
+        ctx.onEvent?.({ type: 'blocked', detail: `${psp}_repeat_unanswered` });
         await ctx.effects.abort();
         return { kind: 'abort' };
     }
-    ctx.onEvent?.({ type: 'repeat_answered', detail: { psp: 'datatrans', authorizationId: repeat.authorizationId } });
+    ctx.onEvent?.({ type: 'repeat_answered', detail: { psp, authorizationId: repeat.authorizationId } });
     return { kind: 'answer' };
 }
+// The TokenEx hosted iframe v3 (tokenex-iframe.ts), JetBlue's card form. TokenEx's card-number frame posts the
+// whole card to its own document URL, and the same path takes posts the device could never fill (a cvvOnly frame,
+// a query this lane has not read) and, after an approval, the frame's own re-sends. The recognizer matches only the
+// exact card URL, so once the registry serves the TokenEx iframe (servesTokenexIframe), every POST on the frame's
+// /iframe/v3 path is judged here, before the terminal arbiter would pause it, by payment-core's own pause decision:
+//   - the sound card post defers, and the arbiter pauses it for approval, unless the same frame already sent the
+//     same bytes and had them answered with an approved token, and that approval is still the one being handed off
+//     (handoffRepeatApproval): then that stored answer is fulfilled here, with no claim, create or prompt. Once the
+//     answer reached the page, the application's merchant resolver must first report the order still pending
+//     (repeatAfterHandoff). A post with another placeholder or CVV is a new question, as for Datatrans;
+//   - any other post on that path that carries a value in Data aborts with a `blocked` event that names the API's
+//     own code, invalid_tokenex_iframe_request, before anything is claimed, created or prompted. Like Datatrans's
+//     refusal it neither holds the attachment nor changes its state;
+//   - a post with nothing in Data carries no card and defers: on the exact URL it continues untouched through the
+//     recognizer's passWithoutCard, and anywhere else it continues as an unrecognized request.
+// Nothing is decided without the registry: for an org the API did not serve the entry to, the gate defers and every
+// TokenEx request continues as before. The frame's document GETs, BinLookup and Forter never reach it as a card post.
+// Synchronous until an effect, so a card post pauses with no await. A check that throws blocks the request.
+const tokenexIframePreClaim = (ctx) => {
+    const { url, method } = ctx.request;
+    if (method.toUpperCase() !== 'POST' || !isTokenexIframePath(url) || !servesTokenexIframe(ctx.vault))
+        return undefined;
+    let decision;
+    try {
+        decision = tokenexIframePauseDecision({ url, headers: ctx.request.headers, body: ctx.request.body });
+    }
+    catch {
+        decision = INVALID_TOKENEX_IFRAME_REQUEST;
+    }
+    if (decision === null)
+        return undefined;
+    if (decision !== 'card')
+        return tokenexIframeBlock(ctx, decision);
+    const approval = handoffRepeatApproval(ctx);
+    const repeat = approval === null ? null : ctx.tokenexIframe?.answerFor(ctx.frame, url, ctx.request.body, approval) ?? null;
+    if (!repeat)
+        return undefined;
+    return ctx.lifecycle.getState().status === 'awaiting_merchant'
+        ? repeatAfterHandoff(ctx, repeat, TOKENEX_IFRAME_PSP) : answerRepeat(ctx, repeat, TOKENEX_IFRAME_PSP);
+};
+async function tokenexIframeBlock(ctx, reason) {
+    ctx.onEvent?.({ type: 'blocked', detail: reason });
+    await ctx.effects.abort();
+    return { kind: 'abort' };
+}
 // Pelecard Iframe/Redirect 2.0 (pelecard.ts). The payment page's card URL, POST
 // /PaymentGW/Transaction on gateway21 or gateway20.pelecard.biz, also carries the wallet, Bit,
 // PIN pad and bank tabs with no card, and card-shaped bodies the device could never fill: a saved
@@ -1574,6 +1628,23 @@ async function shijiStsCompanion(ctx, body) {
     ctx.onEvent?.({ type: 'companion_continued', detail: { url: redactUrl(url), psp: 'shiji_sts', fields: ['cvv'] } });
     return { kind: 'continue' };
 }
+// Przelewy24's pay wall (przelewy24.ts). Once this build's registry serves Przelewy24's entry (a capability the
+// API serves only to a company Agentcard turned Przelewy24 on for), every request to the pay wall's two hosts
+// pauses. The merchant's entry, a GET of /trnRequest/<token> exactly, is no step of this gate's: it defers, and the
+// terminal arbiter pauses it for the claim flow like any card request, so the cardholder's device pays it. Every
+// step toward paying on the pay wall itself aborts as an unsupported checkout: every POST there (the card method's
+// post, the card form's post, a form posted to the entry's link) and the GET of the Saferpay resolver, which names
+// the typed card's type. So Przelewy24 never sees the card the agent typed. The agent's browser only reaches the
+// pay wall when the entry was not paused (an attachment made too late, say), and then only the cardholder's device
+// can pay. The pay wall's own pages, scripts and images are not this gate's and continue. With Przelewy24 not
+// served, the gate defers, and every request continues as before. Synchronous until it must abort, like every gate.
+// Exported for the gate registry's tests.
+export const przelewy24PreClaim = (ctx) => {
+    const { url, method } = ctx.request;
+    if (!isPrzelewy24PayStep(url, method) || !isArmedPrzelewy24Url(ctx.vault, url))
+        return undefined;
+    return processorPageAbort(ctx);
+};
 // NMI's hosted payment page (ekashu.ts). Once this build's registry serves NMI's entry (a
 // capability the API serves only to a company Agentcard turned NMI on for), every request to
 // NMI's two hosts pauses, and this gate judges the POSTs:
@@ -1598,7 +1669,7 @@ export const ekashuPreClaim = (ctx) => {
     return processorPageAbort(ctx);
 };
 // The stop for a card post into a processor's own page that only the cardholder's device may pay (NMI's, Redsys's,
-// QuickPay's).
+// QuickPay's, Eximbay's).
 async function processorPageAbort(ctx) {
     const { url, method } = ctx.request;
     ctx.preparationGate.invalidate('unsupported_checkout');
@@ -1607,6 +1678,27 @@ async function processorPageAbort(ctx) {
     await ctx.effects.abort();
     return { kind: 'abort' };
 }
+// Transbank's Webpay Plus (transbank.ts). Once this build's registry serves Webpay's entry (a capability the API
+// serves only to a company Agentcard turned Webpay on for), every request to Webpay's two hosts pauses, and this gate
+// judges them:
+//   - the merchant's entry, the GET of initTransaction?token_ws=<token> exactly as the redirect writes it, is a GET
+//     and not this gate's: the terminal arbiter pauses it for the claim flow like any card request, and the
+//     cardholder's device pays it;
+//   - every other request there but a GET (the token's one submit to init_transaction.cgi, Webpay's card lookup and
+//     card check, the card post to bp_control.cgi, and an entry posted as a form) aborts as an unsupported checkout,
+//     so the token is never spent in the agent's browser and Webpay never sees the card the agent typed. The agent's
+//     browser only reaches Webpay's pages when the entry was not paused (an attachment made too late, an entry with
+//     another parameter), and then only the cardholder's device can pay;
+//   - another GET there (Webpay's scripts and images, or an entry written another way, whose page then submits the
+//     token, which this gate aborts) continues.
+// With Webpay not served, the gate defers and every request continues as before. Synchronous until it must abort,
+// like every gate. Exported for the gate registry's tests.
+export const transbankPreClaim = (ctx) => {
+    const { url, method } = ctx.request;
+    if (String(method).toUpperCase() === 'GET' || !isArmedTransbankUrl(ctx.vault, url))
+        return undefined;
+    return processorPageAbort(ctx);
+};
 // Redsys's hosted payment page (redsys.ts). Once this build's registry serves Redsys's entry (a
 // capability the API serves only to a company Agentcard turned Redsys on for), every request to
 // Redsys's hosts pauses, and this gate judges the POSTs:
@@ -1655,6 +1747,42 @@ export const quickpayPreClaim = (ctx) => {
         return undefined;
     return processorPageAbort(ctx);
 };
+// ComGate's payment gateway (comgate.ts). Once this build's registry serves ComGate's entry (a capability the API serves
+// only to a company Agentcard turned ComGate on for), the gateway link pauses for the cardholder's device and every
+// request to ComGate's card hosts pauses too, and this gate judges those:
+//   - every request but a GET (the gateway's card post and card check, the Web Checkout SDK's provider calls and card
+//     check, the card frames' BIN lookup and their log) aborts as an unsupported checkout, so ComGate never sees the
+//     card the agent typed. The agent's browser only reaches ComGate's card form when the link was not paused (an
+//     attachment made too late, a link with another parameter, a shop on ComGate's Web Checkout SDK), and then only the
+//     cardholder's device can pay;
+//   - a GET there (the gateway's reads of the payment, the card frames' pages and scripts) is not this gate's and continues.
+// With ComGate not served, the gate defers and every request continues as before. Synchronous until it must abort, like
+// every gate. Exported for the gate registry's tests.
+export const comgatePreClaim = (ctx) => {
+    const { url, method } = ctx.request;
+    if (String(method).toUpperCase() === 'GET' || !isArmedComgateUrl(ctx.vault, url))
+        return undefined;
+    return processorPageAbort(ctx);
+};
+// Eximbay's payment window (eximbay.ts). Once this build's registry serves Eximbay's entry on a host (a capability the
+// API serves only to a company Agentcard turned Eximbay on for), every request to that host pauses, and this gate
+// judges the POSTs:
+//   - the merchant's entry (the entry path exactly, no query) defers, and the terminal arbiter pauses it for the claim
+//     flow like any card request: the cardholder's device pays it;
+//   - every other POST to Eximbay (the step that opens the window, the window's amount query and its card lookup,
+//     which carries the typed card's first eight digits, its card post, and its close and method posts) aborts as an
+//     unsupported checkout, so Eximbay never sees the card the agent typed. The agent's browser only reaches Eximbay's
+//     window when the entry was not paused (an attachment made too late, say), and then only the cardholder's device
+//     can pay.
+// A GET (the window's scripts and images) is not this gate's and continues. With Eximbay not served, the entry is no
+// card request, the gate defers, and every request continues as before. Synchronous until it must abort, like every
+// gate. Exported for the gate registry's tests.
+export const eximbayPreClaim = (ctx) => {
+    const { url, method } = ctx.request;
+    if (String(method).toUpperCase() !== 'POST' || !isArmedEximbayUrl(ctx.vault, url) || isEximbayEntry(url, method))
+        return undefined;
+    return processorPageAbort(ctx);
+};
 // PayPal's legacy Hosted Fields (paypal-hosted-fields.ts). Its tokenization frame posts the card the
 // agent typed to the Orders v2 confirm-payment-source on cors.api.paypal.com (or its sandbox), which
 // no Vault mode takes over, so every company's adapters hand each POST there to this gate:
@@ -2037,7 +2165,7 @@ async function hipayRefused(ctx, reason) {
 //     again. A checkout whose token request was already approved keeps that approval's state (lifecycle.unsupported),
 //     and its follow-ups stop (EbanxFollowUps.stop): a later request the approval would cover is refused too, so the
 //     page cannot finish 3-D Secure and pay through the confirm after a refusal. A failed send stops them the same way.
-//     A send goes on only while the checkout itself names the remembered approval (ebanxMaySend): it awaits the
+//     A send goes on only while the checkout itself names the remembered approval (followUpMaySend): it awaits the
 //     merchant, reports the bank's challenge, or holds that approval's answer for the page (awaiting_approval while
 //     the token's answer is on its way, since the adapters remember the approval before they hand the answer over, or
 //     ready_to_submit while the approval waits for the page's retry). A new token request awaiting the person, a new
@@ -2066,38 +2194,39 @@ export const ebanxPreClaim = (ctx) => {
     catch {
         body = null;
     }
-    const claim = ctx.ebanx && typeof ctx.vault.sendEbanxFollowUp === 'function' && ebanxMaySend(ctx)
+    const claim = ctx.ebanx && typeof ctx.vault.sendEbanxFollowUp === 'function' && followUpMaySend(ctx, ctx.ebanx)
         ? ctx.ebanx.claim({ url, method: 'POST', headers: ctx.request.headers ?? {}, body }) : null;
     return claim ? ebanxFollowUp(ctx, claim) : ebanxResendRefused(ctx, refusal);
 };
 /**
  * The checkout states in which a send may go on under the remembered approval, an allowlist: the checkout awaits the
- * merchant, the application reported the bank's challenge (requestUserAction), the token's answer is still on its way
+ * merchant, the application reported the bank's challenge (requestUserAction), the approved answer is still on its way
  * to the page (awaiting_approval: the page may send its first 3-D Secure call the moment the answer lands), or the
  * approval waits for the page's retry (ready_to_submit). Every other state refuses, idle and the final ones among them.
+ * The same for EBANX's sends and Payrexx's.
  */
-const EBANX_SENDING_STATES = new Set(['awaiting_merchant', 'requires_user_action', 'awaiting_approval', 'ready_to_submit']);
+const FOLLOW_UP_SENDING_STATES = new Set(['awaiting_merchant', 'requires_user_action', 'awaiting_approval', 'ready_to_submit']);
 /**
  * Whether a send may go on: nothing aborted the checkout, no reconciliation of the merchant's order is running (one
  * that resolves failed while a confirm is out would let the application start another attempt), it is in one of
- * EBANX_SENDING_STATES, and its state names the approval the attachment remembered. A new token request awaiting the
- * person (awaiting_approval with no approval, or another one), a new attempt after a merchant failure, a prepared
- * checkout and another approval's state all refuse.
+ * FOLLOW_UP_SENDING_STATES, and its state names the approval the attachment remembered (`followUps`, EBANX's or
+ * Payrexx's). A new card request awaiting the person (awaiting_approval with no approval, or another one), a new
+ * attempt after a merchant failure, a prepared checkout and another approval's state all refuse.
  */
-function ebanxMaySend(ctx) {
-    if (ctx.lifecycleAborted() || ctx.terminal() || !ctx.ebanx || ctx.lifecycle.isReconciling())
+function followUpMaySend(ctx, followUps) {
+    if (ctx.lifecycleAborted() || ctx.terminal() || !followUps || ctx.lifecycle.isReconciling())
         return false;
-    const approval = ctx.ebanx.authorizationId;
+    const approval = followUps.authorizationId;
     const state = ctx.lifecycle.getState();
-    return approval !== null && EBANX_SENDING_STATES.has(state.status) && state.authorizationId === approval;
+    return approval !== null && FOLLOW_UP_SENDING_STATES.has(state.status) && state.authorizationId === approval;
 }
 /**
  * The checkout's final merchant results: completed, failed, declined, timed out, cancelled, an unknown outcome, or an
  * unsupported request. A 3-D Secure call, which charges nothing, that fails in one of them leaves that outcome alone.
  */
-const EBANX_FINAL_STATES = new Set(['completed', 'failed', 'declined', 'timed_out', 'cancelled', 'outcome_unknown', 'unsupported']);
-/** Whether the checkout already ended (EBANX_FINAL_STATES): its state and reason stand, whatever a later 3-D Secure call does. */
-const ebanxCheckoutEnded = (ctx) => EBANX_FINAL_STATES.has(ctx.lifecycle.getState().status);
+const FOLLOW_UP_FINAL_STATES = new Set(['completed', 'failed', 'declined', 'timed_out', 'cancelled', 'outcome_unknown', 'unsupported']);
+/** Whether the checkout already ended (FOLLOW_UP_FINAL_STATES): its state and reason stand, whatever a later 3-D Secure call does. */
+const followUpCheckoutEnded = (ctx) => FOLLOW_UP_FINAL_STATES.has(ctx.lifecycle.getState().status);
 /**
  * A confirm whose card may have reached EBANX and whose answer the page never got: only a payment the merchant
  * already confirmed (completed) stands, and every other state of this approval turns unknown, since EBANX may have
@@ -2138,7 +2267,7 @@ async function ebanxUnreadable(ctx) {
  * (CheckoutLifecycle.followUpStarted): meanwhile reconcile() and retryAfterMerchantFailure() throw, so the application
  * starts no other attempt while a confirm may pay. A confirm that may have left keeps only a payment the merchant
  * confirmed (completed); any other state of its approval turns unknown (ebanxConfirmUnconfirmed). Any other send keeps
- * a final outcome (EBANX_FINAL_STATES) with its reason.
+ * a final outcome (FOLLOW_UP_FINAL_STATES) with its reason.
  */
 async function ebanxFollowUp(ctx, claim) {
     const settle = ctx.lifecycle.followUpStarted();
@@ -2164,7 +2293,7 @@ async function sendEbanxFollowUp(ctx, claim) {
         ctx.onEvent?.({ type: 'ebanx_follow_up_failed', detail: { ...detail, reason, cardSent } });
         if (cardSent && claim.kind === 'confirm')
             ebanxConfirmUnconfirmed(ctx, claim.authorizationId, 'ebanx_confirm_unconfirmed');
-        else if (!ebanxCheckoutEnded(ctx))
+        else if (!followUpCheckoutEnded(ctx))
             ctx.lifecycle.unsupported(EBANX_RESEND_REASON);
         await ctx.effects.abort();
         return { kind: 'abort' };
@@ -2179,7 +2308,7 @@ async function sendEbanxFollowUp(ctx, claim) {
         ctx.onEvent?.({ type: 'ebanx_follow_up_failed', detail: { ...detail, reason: 'handoff_failed', cardSent: true } });
         if (claim.kind === 'confirm')
             ebanxConfirmUnconfirmed(ctx, claim.authorizationId, 'ebanx_follow_up_handoff_failed');
-        else if (!ebanxCheckoutEnded(ctx))
+        else if (!followUpCheckoutEnded(ctx))
             ctx.lifecycle.unsupported(EBANX_RESEND_REASON);
         await ctx.effects.abort();
         return { kind: 'abort' };
@@ -2187,6 +2316,95 @@ async function sendEbanxFollowUp(ctx, claim) {
     ctx.onEvent?.({ type: 'ebanx_follow_up_answered', detail: { ...detail, status: answer.status } });
     return { kind: 'answer' };
 }
+// Payrexx Pay's card frame after its card request (payrexx.ts, payment-core payrexx.js). When Payrexx answers the card
+// request by starting 3-D Secure, the frame posts the card again to its own URL for the authentication after the ACS
+// method and the post-authentication after the bank's challenge. On a page this SDK is attached to that card is the
+// agent's placeholder, and the frame's URL is the card request's, so this gate judges each such post before the
+// card-request arbiter would pause it as a new card request:
+//   - one the approved card request on this attachment covers (PayrexxFollowUps.claim) goes to the cardholder's device
+//     under that approval (payrexxFollowUp below), and the frame receives Payrexx's answer to the real card;
+//   - any other aborts as an unsupported checkout, reason `unsupported_payrexx_card_resend`, with no claim, create or
+//     prompt, so Payrexx never receives the placeholder as a card, and the attachment holds. A checkout whose card
+//     request was already approved keeps that approval's state, and its sends stop (PayrexxFollowUps.stop), as
+//     EBANX's do. A send goes on only while the checkout itself names the remembered approval (followUpMaySend).
+// The card request itself, a wallet's body with no card value, a body the adapter could not read and every other
+// request defer: the arbiter pauses the card request for its recognizer and judges the rest (card-fields.js).
+// Synchronous until it must abort or send, like every gate. Exported for the gate registry's tests.
+export const payrexxPreClaim = (ctx) => {
+    const { url, method } = ctx.request;
+    if (!isPayrexxResend(url, method, () => ctx.request.body))
+        return undefined;
+    let body;
+    try {
+        body = ctx.request.body;
+    }
+    catch {
+        body = null;
+    }
+    const claim = ctx.payrexx && typeof ctx.vault.sendPayrexxFollowUp === 'function' && followUpMaySend(ctx, ctx.payrexx)
+        ? ctx.payrexx.claim({ url, method: 'POST', headers: ctx.request.headers ?? {}, body }) : null;
+    return claim ? payrexxFollowUp(ctx, claim) : payrexxResendRefused(ctx);
+};
+async function payrexxResendRefused(ctx) {
+    const { url, method } = ctx.request;
+    ctx.preparationGate.invalidate('unsupported_checkout');
+    ctx.payrexx?.stop();
+    ctx.lifecycle.unsupported(PAYREXX_RESEND_REASON);
+    ctx.onEvent?.({ type: 'unsupported_checkout', detail: { url: eventUrl(ctx.vault, url), method, reason: PAYREXX_RESEND_REASON, step: 'three_d_secure' } });
+    await ctx.effects.abort();
+    return { kind: 'abort' };
+}
+/**
+ * A 3-D Secure send the approved card request covers: the cardholder's device sends it with the real card
+ * (VaultClient.sendPayrexxFollowUp), and the frame receives Payrexx's answer, with no second prompt. The events name the
+ * approval and the step, never the request, the card or Payrexx's answer. A send charges nothing: the merchant's page
+ * charges only the token a later answer names, at its own validateForm. So a send that gets no answer, or whose answer
+ * the frame never receives, leaves no payment behind it: the frame's request fails, the attachment holds as the
+ * refusal above does (a final outcome keeps its state and reason), and nothing more is sent. While a send is out it
+ * counts as work in flight (CheckoutLifecycle.followUpStarted), so the application starts no other attempt over it.
+ */
+async function payrexxFollowUp(ctx, claim) {
+    const settle = ctx.lifecycle.followUpStarted();
+    try {
+        return await sendPayrexxFollowUp(ctx, claim);
+    }
+    finally {
+        settle();
+    }
+}
+async function sendPayrexxFollowUp(ctx, claim) {
+    const detail = { authorizationId: claim.authorizationId, step: claim.kind };
+    ctx.onEvent?.({ type: 'payrexx_follow_up_requested', detail });
+    let answer;
+    try {
+        answer = await ctx.vault.sendPayrexxFollowUp(claim.authorizationId, claim.request, { signal: ctx.lifecycle.abort.signal, until: claim.until });
+    }
+    catch (error) {
+        claim.settle(null);
+        ctx.payrexx?.stop();
+        const reason = error instanceof PayrexxFollowUpError ? error.reason : 'follow_up_unavailable';
+        const cardSent = error instanceof PayrexxFollowUpError ? error.cardSent : true;
+        ctx.onEvent?.({ type: 'payrexx_follow_up_failed', detail: { ...detail, reason, cardSent } });
+        if (!followUpCheckoutEnded(ctx))
+            ctx.lifecycle.unsupported(PAYREXX_RESEND_REASON);
+        await ctx.effects.abort();
+        return { kind: 'abort' };
+    }
+    claim.settle({ status: answer.status, text: answer.body });
+    try {
+        await ctx.effects.answer({ status: answer.status, headers: answer.headers, body: answer.body });
+    }
+    catch {
+        ctx.payrexx?.stop();
+        ctx.onEvent?.({ type: 'payrexx_follow_up_failed', detail: { ...detail, reason: 'handoff_failed', cardSent: true } });
+        if (!followUpCheckoutEnded(ctx))
+            ctx.lifecycle.unsupported(PAYREXX_RESEND_REASON);
+        await ctx.effects.abort();
+        return { kind: 'abort' };
+    }
+    ctx.onEvent?.({ type: 'payrexx_follow_up_answered', detail: { ...detail, status: answer.status } });
+    return { kind: 'answer' };
+}
 // The terminal arbiter, always last. A request that no gate claimed and that is
 // neither a native Stripe step nor a recognized card request continues, unless
 // it matches a declared payment endpoint we do not support (then it aborts as an
@@ -2220,8 +2438,8 @@ async function unsupportedContinue(ctx) {
  * arbiter runs after all of them and is not part of this list. A gate appended
  * after Stripe is never offered a step Stripe claimed: Stripe answers, aborts or
  * pauses each one itself. */
-export const PSP_PRE_CLAIM_GATES = [cardEndpointResendPreClaim, cardEndpointPreClaim, mercadoPreClaim, juspayPreClaim, braintreePreClaim, stripePreClaim, merchantHostedPreClaim, verifonePreClaim, fiservPreClaim, gmoPreClaim, cybersourceFlexPreClaim, datatransPreClaim, pelecardPreClaim, aciPreClaim, creditguardPreClaim, primerPreClaim, payrailsPreClaim, convergePreClaim, eprotectPreClaim, wspayPreClaim, shijiStsPreClaim, ekashuPreClaim, redsysPreClaim, quickpayPreClaim, paypalHostedFieldsPreClaim,
-    paypalCardFormsPreClaim, cybersourceSecureAcceptancePreClaim, worldlineMyCheckoutPreClaim, paddleVgsPayPreClaim, ebanxPreClaim, hipayPreClaim];
+export const PSP_PRE_CLAIM_GATES = [cardEndpointResendPreClaim, cardEndpointPreClaim, mercadoPreClaim, juspayPreClaim, braintreePreClaim, stripePreClaim, merchantHostedPreClaim, verifonePreClaim, fiservPreClaim, gmoPreClaim, cybersourceFlexPreClaim, datatransPreClaim, tokenexIframePreClaim, pelecardPreClaim, aciPreClaim, creditguardPreClaim, primerPreClaim, payrailsPreClaim, convergePreClaim, eprotectPreClaim, wspayPreClaim, shijiStsPreClaim, ekashuPreClaim, redsysPreClaim, quickpayPreClaim, comgatePreClaim, przelewy24PreClaim, transbankPreClaim, eximbayPreClaim, paypalHostedFieldsPreClaim,
+    paypalCardFormsPreClaim, cybersourceSecureAcceptancePreClaim, worldlineMyCheckoutPreClaim, paddleVgsPayPreClaim, ebanxPreClaim, payrexxPreClaim, hipayPreClaim];
 /** Run each gate in order; the first to return a decision wins. If none does,
  * the terminal arbiter decides between continue, abort (unsupported) and pause.
  * Returns synchronously while every gate defers synchronously (an ordinary card

package/dist/preflight-catalog.json

@@ -2174,6 +2174,64 @@
       "hostname_pattern": "^assets\\.braintreegateway\\.com$",
       "pathname_pattern": "^\\/web\\/[0-9]+\\.[0-9]+\\.[0-9]+-payments-sdk(?:-[a-z]+)?\\/html\\/hosted-fields-(?:input-frame|payments-sdk-tokenization-frame)(?:\\.min)?\\.html$"
     },
+    {
+      "id": "paypal-card-fields-v5",
+      "psp": "paypal",
+      "kinds": [
+        "frame",
+        "iframe"
+      ],
+      "origin": "https://www.paypal.com",
+      "path_pattern": "/smart/card-field",
+      "sources": [
+        {
+          "kind": "primary_source",
+          "reference": "https://www.paypal.com/sdk/js?components=card-fields",
+          "reviewed_on": "2026-10-15"
+        },
+        {
+          "kind": "primary_source",
+          "reference": "https://developer.paypal.com/docs/checkout/advanced/integrate/",
+          "reviewed_on": "2026-10-15"
+        },
+        {
+          "kind": "saved_observation",
+          "reference": "lake-antoine-park-2026-10-15:paypal-card-field-frames",
+          "reviewed_on": "2026-10-15"
+        }
+      ],
+      "hostname_pattern": "^www\\.paypal\\.com$",
+      "pathname_pattern": "^\\/smart\\/card-field$"
+    },
+    {
+      "id": "paypal-card-fields-v6",
+      "psp": "paypal",
+      "kinds": [
+        "frame",
+        "iframe"
+      ],
+      "origin": "https://www.paypal.com",
+      "path_pattern": "/web-sdk/v6/card-fields-content",
+      "sources": [
+        {
+          "kind": "primary_source",
+          "reference": "https://www.paypal.com/sdk/js?components=card-fields",
+          "reviewed_on": "2026-10-15"
+        },
+        {
+          "kind": "primary_source",
+          "reference": "https://developer.paypal.com/docs/checkout/advanced/integrate/",
+          "reviewed_on": "2026-10-15"
+        },
+        {
+          "kind": "saved_observation",
+          "reference": "lake-antoine-park-2026-10-15:paypal-card-field-frames",
+          "reviewed_on": "2026-10-15"
+        }
+      ],
+      "hostname_pattern": "^www\\.paypal\\.com$",
+      "pathname_pattern": "^\\/web-sdk\\/v6\\/card-fields-content$"
+    },
     {
       "id": "cybersource-secure-acceptance-silent-order-post",
       "psp": "cybersource_secure_acceptance",

package/dist/preflight-schemas.json

@@ -467,6 +467,8 @@
                 "gravy-secure-fields-script",
                 "gravy-secure-fields-script-sandbox",
                 "paypal-hosted-fields-payments-sdk",
+                "paypal-card-fields-v5",
+                "paypal-card-fields-v6",
                 "cybersource-secure-acceptance-silent-order-post",
                 "fiserv-commercehub-payment-fields",
                 "fiserv-commercehub-checkout-script",
@@ -1101,6 +1103,8 @@
                       "gravy-secure-fields-script",
                       "gravy-secure-fields-script-sandbox",
                       "paypal-hosted-fields-payments-sdk",
+                      "paypal-card-fields-v5",
+                      "paypal-card-fields-v6",
                       "cybersource-secure-acceptance-silent-order-post",
                       "fiserv-commercehub-payment-fields",
                       "fiserv-commercehub-checkout-script",

package/dist/preflight.generated.js

@@ -1,5 +1,5 @@
 // Generated from @agent-cards/payment-core. Do not edit.
-// source-sha256: f0596389845388a1c6150964e576c420abb0b44a805347e4ba4d0617f3b8ea2b
+// source-sha256: 639ffa689e8dfcf093eeba7e34b86c570e53ab17970976ae462a41fd2120d753
 import { CHECKOUT_PREFLIGHT_CAPABILITIES } from './preflight-capabilities.generated.js';
 /** Advisory page discovery. These rules never admit a payment destination. */
 export const CHECKOUT_PREFLIGHT_VERSION = '1';
@@ -87,6 +87,20 @@ RULES.push({ id: 'paypal-hosted-fields-payments-sdk', psp: 'paypal', kinds: ['fr
         paypalHostedFieldsSource('https://www.paypal.com/sdk/js?components=hosted-fields'),
         { kind: 'saved_observation', reference: 'planet-golf-uk-2026-10-06:paypal-hosted-fields-payments-sdk-frames', reviewed_on: '2026-10-07' }],
     variant_unverified: 'PayPal legacy Hosted Fields frames send the card to the Orders v2 confirm-payment-source on cors.api.paypal.com; no Vault mode takes that request over.' });
+// PayPal Card Fields (its JS SDK's components=card-fields, v5, and web-sdk v6), reviewed 2026-10-15 from
+// WooCommerce PayPal Payments 4.1.3 checkouts (PayPal JS SDK 5.0.582, card-field client 1.270.0) and PayPal's
+// public web-sdk v6 6.68.0 bundles, with no card typed. v5 renders each card field as a frame on
+// www.paypal.com/smart/card-field (?type=number, expiry, cvv or name), and v6 as
+// www.paypal.com/web-sdk/v6/card-fields-content. Each sends the card to the Orders v2 confirm-payment-source,
+// which payment-core's paypal entry takes while it ships dark, so the frames name paypal and the result
+// stays unknown until the lane is served to every client.
+const paypalCardFieldsSource = (reference) => ({ kind: 'primary_source', reference, reviewed_on: '2026-10-15' });
+const PAYPAL_CARD_FIELDS_SOURCES = [paypalCardFieldsSource('https://www.paypal.com/sdk/js?components=card-fields'),
+    paypalCardFieldsSource('https://developer.paypal.com/docs/checkout/advanced/integrate/'),
+    { kind: 'saved_observation', reference: 'lake-antoine-park-2026-10-15:paypal-card-field-frames', reviewed_on: '2026-10-15' }];
+RULES.push({ id: 'paypal-card-fields-v5', psp: 'paypal', kinds: ['frame', 'iframe'], hostname: /^www\.paypal\.com$/, pathname: /^\/smart\/card-field$/,
+    origin: 'https://www.paypal.com', path_pattern: '/smart/card-field', sources: PAYPAL_CARD_FIELDS_SOURCES }, { id: 'paypal-card-fields-v6', psp: 'paypal', kinds: ['frame', 'iframe'], hostname: /^www\.paypal\.com$/, pathname: /^\/web-sdk\/v6\/card-fields-content$/,
+    origin: 'https://www.paypal.com', path_pattern: '/web-sdk/v6/card-fields-content', sources: PAYPAL_CARD_FIELDS_SOURCES });
 // CyberSource Secure Acceptance's Silent Order POST (the Secure Acceptance Checkout API), reviewed 2026-10-08 from
 // CyberSource's endpoint table and Arrow Electronics' public bundles (no card was sent). The merchant's own page
 // posts the card fields, unsigned, beside the fields its server signed, to a /silent/ path on CyberSource's Secure
@@ -308,7 +322,7 @@ RULES.push({ id: 'worldline-mycheckout-page', psp: 'worldline_mycheckout', kinds
     origin: 'https://payment.pay1.checkout.worldline-solutions.com', path_pattern: '/checkout/{payment-product-details/}:hosted_checkout', sources: worldlineSources }, { id: 'worldline-mycheckout-card-form', psp: 'worldline_mycheckout', kinds: ['form'], hostname: /^payment\.pay1\.checkout\.worldline-solutions\.com$/, pathname: /^\/checkout$/,
     origin: 'https://payment.pay1.checkout.worldline-solutions.com', path_pattern: '/checkout', sources: worldlineSources });
 // A processor that ships dark (its definition declares a capability) is left out of the bundled
-// catalog. Datatrans's discovery rules wait with it: they join RULES only once KNOWN_PSPS, the
+// catalog. Datatrans's and the TokenEx iframe's discovery rules wait with it: they join RULES only once KNOWN_PSPS, the
 // bundled catalog's processors, lists its psp. Until then its assets are not evidence, so a page
 // that loads them, alone or beside another processor's SDK, reads exactly as it did before the
 // processor existed. (The dark GMO, CyberSource Flex, Juspay, Pelecard, ACI, CreditGuard,
@@ -326,6 +340,16 @@ for (const [suffix, hostname, origin] of [['', /^pay\.datatrans\.com$/, 'https:/
         sources: [datatransSource('https://pay.datatrans.com/upp/payment/js/secure-fields-2.0.0.js'), datatransSource('https://docs.pci-proxy.com/docs/secure-fields-quick-start')] }, { id: `datatrans-secure-fields-frame${suffix}`, psp: 'datatrans', kinds: ['document', 'frame', 'iframe'], hostname, pathname: /^\/upp\/payment\/SecureFields\/paymentField$/, origin, path_pattern: '/upp/payment/SecureFields/paymentField',
         sources: [datatransSource('https://pay.datatrans.com/upp/payment/SecureFields/field.js'), datatransSource('https://docs.datatrans.ch/docs/secure-fields')] });
 }
+// TokenEx hosted iframe v3, read 2026-10-18 from JetBlue's checkout: the parent library
+// (htp.tokenex.com/Iframe/Iframe-v3.min.js) and the iframe document it loads (/iframe/v3?<query>), on the
+// live host and its test twin. Dark behind tokenex_iframe_tokenize, so it waits with Datatrans.
+const tokenexSource = (reference) => ({ kind: 'primary_source', reference, reviewed_on: '2026-10-18' });
+for (const [suffix, hostname, origin] of [['', /^htp\.tokenex\.com$/, 'https://htp.tokenex.com'],
+    ['-test', /^test-htp\.tokenex\.com$/, 'https://test-htp.tokenex.com']]) {
+    SERVED_ONLY_RULES.push({ id: `tokenex-iframe-v3-script${suffix}`, psp: 'tokenex_iframe', kinds: ['script'], hostname, pathname: /^\/Iframe\/Iframe-v3(?:\.min)?\.js$/, origin, path_pattern: '/Iframe/Iframe-v3{,.min}.js',
+        sources: [tokenexSource('https://htp.tokenex.com/Iframe/Iframe-v3.min.js')] }, { id: `tokenex-iframe-v3-frame${suffix}`, psp: 'tokenex_iframe', kinds: ['document', 'frame', 'iframe'], hostname, pathname: /^\/iframe\/v3$/, origin, path_pattern: '/iframe/v3',
+        sources: [tokenexSource('https://htp.tokenex.com/Iframe/v3.min.js?version=latest')] });
+}
 RULES.push(...SERVED_ONLY_RULES.filter(rule => KNOWN_PSPS.includes(rule.psp)));
 // Keep sandbox evidence truthful instead of labelling it with a production origin.
 for (const [baseId, suffix, hostname, origin] of [