@agent-cards/sdk 0.23.21 → 0.23.22

package/dist/payrexx.js

@@ -0,0 +1,141 @@
+/**
+ * Payrexx Pay's card frame after its card request (payment-core payrexx.js holds the rules; this SDK vendors them as
+ * payrexx.generated.ts).
+ *
+ * The frame, https://checkout.payrexx.com/?pspId=44&lang=<xx>, posts the card to its own URL. When Payrexx answers that
+ * card request by starting 3-D Secure (no token, a threeDSServerTransID), the merchant's page runs 3-D Secure and the
+ * frame posts the whole card again to the same URL for each step, with the step's own keys after the card request's
+ * fifteen:
+ *   - the authentication, after the ACS method: threeDSServerTransID, threeDSVersion when the first answer named one,
+ *     and ten authData values the page reads from the agent's browser;
+ *   - the post-authentication, after the bank's challenge: threeDSServerTransID and postAuth=true.
+ * On a page this SDK is attached to, that card is the agent's placeholder. One approval covers at most one of each, in
+ * that order, for the 3-D Secure run its own answer opened (payment-core payrexxFollowUpVerdict), so a run sends the
+ * card at most three times. What this module keeps of the approved card request (PayrexxFollowUps) is what the
+ * pre-claim gate reads to decide whether the cardholder's device sends a step, or the step fails in the browser.
+ * The card request itself, and a body with no card value at all (a wallet's own encryptedCard), are not 3-D Secure
+ * sends: the card-request arbiter pauses the one and continues the other (card-fields.js).
+ */
+import { PAYREXX_FOLLOW_UP_KINDS, isPayrexxFrameUrl, payrexxAnswerOutcome, payrexxBodyVerdict, payrexxFollowUpVerdict, payrexxGateVerdict, } from './payrexx.generated.js';
+export const PAYREXX_PSP = 'payrexx';
+/** The capability a build declares to be served Payrexx's recognizer (payment-core PAYREXX_CAPABILITY). */
+export const PAYREXX_CAPABILITY = 'payrexx_card_frame';
+/** The reason a checkout reads when a 3-D Secure send of the placeholder card fails in the browser. */
+export const PAYREXX_RESEND_REASON = 'unsupported_payrexx_card_resend';
+/**
+ * Whether a request is a POST to Payrexx's card frame URL whose body sends the card again for a 3-D Secure step
+ * (payment-core payrexxBodyVerdict: payrexx_three_ds_resend). `readBody` is called only for a POST to the frame URL,
+ * and a reader that throws, or a body nobody could read, reads as no 3-D Secure send.
+ */
+export function isPayrexxResend(url, method, readBody) {
+    if (String(method).toUpperCase() !== 'POST' || !isPayrexxFrameUrl(url))
+        return false;
+    let body;
+    try {
+        body = readBody();
+    }
+    catch {
+        body = null;
+    }
+    if (typeof body !== 'string')
+        return false;
+    const verdict = payrexxBodyVerdict(body);
+    return verdict.verdict === 'refuse' && verdict.code === 'payrexx_three_ds_resend';
+}
+/**
+ * A 3-D Secure send the cardholder's device did not answer with Payrexx's own answer. `reason` is the API's word for
+ * it: `not_picked_up` (no device started it in time: the Vault page was closed or asleep), `not_sent` (the device
+ * refused it before the card left), `no_answer`, `answer_withheld` (Payrexx's answer carried the card),
+ * `answer_refused`, `answer_late`, `response_expired`, or the API's refusal code when it did not take the send at all
+ * (`follow_up_refused`, `follow_up_not_covered`, `follow_up_window_closed`). `cardSent` says whether the card may
+ * have reached Payrexx: false only when the API confirmed it never left the device. Nothing in it names the request,
+ * the card or Payrexx's answer.
+ */
+export class PayrexxFollowUpError extends Error {
+    reason;
+    cardSent;
+    authorizationId;
+    constructor(reason, cardSent, authorizationId) {
+        super(cardSent
+            ? `This Payrexx 3-D Secure request under ${authorizationId} has no answer, and the cardholder's device may have sent it: ${reason}.`
+            : `The cardholder's device did not send this Payrexx 3-D Secure request under ${authorizationId}: ${reason}.`);
+        this.reason = reason;
+        this.cardSent = cardSent;
+        this.authorizationId = authorizationId;
+        this.name = 'PayrexxFollowUpError';
+    }
+}
+/**
+ * What one attachment keeps of its approved Payrexx card request: the request and Payrexx's answer as the page received
+ * them, until when the API said the approval covers sends after it, and the sends it claimed since, in order. Only a
+ * card request whose answer started 3-D Secure (payment-core payrexxAnswerOutcome: pending three_ds) and whose read
+ * named that window (`followUpsUntil`) is kept. Any later Payrexx card request handed over replaces it, a send the
+ * window has passed is never claimed, and once a send is refused or fails the attachment stops (stop()): nothing after
+ * it is claimed, a later approval included.
+ */
+export class PayrexxFollowUps {
+    parent = null;
+    sent = [];
+    stopped = false;
+    /** After a refused or failed send: no later request on this attachment is claimed. */
+    stop() { this.stopped = true; }
+    /**
+     * The approval the remembered card request went under, or null when none is remembered. The gate sends nothing
+     * unless the checkout's own state names this same approval.
+     */
+    get authorizationId() { return this.parent?.authorizationId ?? null; }
+    /**
+     * As the adapter hands an approved card request's answer to the page: before the answer lands, since the page may
+     * start 3-D Secure at once. Every Payrexx card request handed over clears what an earlier one left; only one whose
+     * answer started 3-D Secure, under a read that named the window, is kept.
+     */
+    remember(request, replay) {
+        if (payrexxGateVerdict(request.url, request.body).verdict !== 'card')
+            return;
+        this.parent = null;
+        this.sent = [];
+        const until = typeof replay.followUpsUntil === 'string' ? Date.parse(replay.followUpsUntil) : NaN;
+        if ((replay.mode ?? 'token') !== 'token' || !Number.isFinite(until))
+            return;
+        // No card: this browser only ever held the placeholder.
+        const outcome = payrexxAnswerOutcome(replay.status, replay.body, null);
+        if (outcome.outcome !== 'approved' || outcome.pending !== 'three_ds')
+            return;
+        this.parent = { authorizationId: replay.authorizationId, url: request.url, body: request.body, answer: { status: replay.status, text: replay.body }, until };
+    }
+    /**
+     * The claim for a paused 3-D Secure send the remembered approval covers, or null: no approval covers sends here, its
+     * window has passed, or payment-core's rule refuses the send against the sends already claimed. Synchronous, and it
+     * reserves the send, so two requests can never both be claimed as the next one.
+     */
+    claim(request, now = Date.now()) {
+        const parent = this.parent;
+        if (this.stopped || !parent || now >= parent.until || typeof request.body !== 'string')
+            return null;
+        const verdict = payrexxFollowUpVerdict({
+            parent: { url: parent.url, body: parent.body, answer: parent.answer }, sent: this.sent,
+            request: { url: request.url, method: request.method, body: request.body },
+        });
+        if (!verdict.ok || !PAYREXX_FOLLOW_UP_KINDS.includes(verdict.kind))
+            return null;
+        const entry = { kind: verdict.kind, state: 'pending' };
+        this.sent.push(entry);
+        const contentType = Object.entries(request.headers ?? {}).find(([name]) => /^content-type$/i.test(name))?.[1];
+        return {
+            authorizationId: parent.authorizationId, kind: verdict.kind, until: parent.until,
+            request: { url: request.url, method: 'POST', headers: { 'content-type': typeof contentType === 'string' ? contentType : 'application/x-www-form-urlencoded; charset=UTF-8' },
+                body: request.body },
+            settle(answer) {
+                if (entry.state !== 'pending')
+                    return;
+                // A copy of the answer as it was settled: a caller that changes its own object later changes no claim.
+                if (answer) {
+                    entry.state = 'answered';
+                    entry.answer = { status: answer.status, text: answer.text };
+                }
+                else
+                    entry.state = 'failed';
+            },
+        };
+    }
+}

package/dist/pre-claim.d.ts

@@ -16,6 +16,7 @@ import { type VerifoneProfile } from './verifone.js';
 import { type WorldlineMyCheckoutProducts } from './worldline-mycheckout.js';
 import { type PaddleVgsPayGate } from './paddle-vgs-pay.js';
 import { type EbanxFollowUps } from './ebanx.js';
+import { type PayrexxFollowUps } from './payrexx.js';
 /** The native Stripe step the gate claimed, or null when none was: exactly what StripeCheckoutGate.claim returns. */
 type StripeStep = ReturnType<StripeCheckoutGate['claim']>;
 /** A synthetic response a gate fulfills locally. The effect applies CORS and encoding. */
@@ -116,6 +117,20 @@ export interface PreClaimContext {
             headers: Record<string, string>;
             body: string;
         }>;
+        /** VaultClient.sendPayrexxFollowUp: a 3-D Secure send an approved Payrexx card request covers, from the cardholder's device. */
+        sendPayrexxFollowUp?(authorizationId: string, request: {
+            url: string;
+            method: 'POST';
+            headers: Record<string, string>;
+            body: string;
+        }, options?: {
+            signal?: AbortSignal;
+            until?: number;
+        }): Promise<{
+            status: number;
+            headers: Record<string, string>;
+            body: string;
+        }>;
     };
     guards: {
         matches(url: string, method?: string): boolean;
@@ -226,6 +241,12 @@ export interface PreClaimContext {
      * is refused, as before the approval covered them.
      */
     ebanx?: EbanxFollowUps;
+    /**
+     * The attachment's approved Payrexx card request and the 3-D Secure sends claimed under it (payrexx.ts
+     * PayrexxFollowUps). Absent, or holding no approval whose answer started 3-D Secure, and every 3-D Secure send of the
+     * card frame is refused.
+     */
+    payrexx?: PayrexxFollowUps;
 }
 /**
  * The URL an event may name for a request. For an armed merchant profile's
@@ -260,6 +281,7 @@ export declare const transbankPreClaim: PreClaimGate;
 export declare const redsysPreClaim: PreClaimGate;
 export declare const quickpayPreClaim: PreClaimGate;
 export declare const comgatePreClaim: PreClaimGate;
+export declare const eximbayPreClaim: PreClaimGate;
 export declare const paypalHostedFieldsPreClaim: PreClaimGate;
 export declare const paypalCardFormsPreClaim: PreClaimGate;
 export declare const cybersourceSecureAcceptancePreClaim: PreClaimGate;
@@ -277,6 +299,7 @@ export declare function routesHipayVault(vault: {
     recognizesProcessor?: (psp: string) => boolean;
 } | null | undefined, url: string): boolean;
 export declare const ebanxPreClaim: PreClaimGate;
+export declare const payrexxPreClaim: PreClaimGate;
 /** The processor gates, in order. A new family adds one entry here; the terminal
  * 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

package/dist/pre-claim.js

@@ -86,6 +86,7 @@ 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';
@@ -93,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
@@ -1667,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');
@@ -1762,6 +1764,25 @@ export const comgatePreClaim = (ctx) => {
         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:
@@ -2144,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
@@ -2173,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
@@ -2245,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();
@@ -2271,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' };
@@ -2286,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' };
@@ -2294,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
@@ -2327,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, tokenexIframePreClaim, pelecardPreClaim, aciPreClaim, creditguardPreClaim, primerPreClaim, payrailsPreClaim, convergePreClaim, eprotectPreClaim, wspayPreClaim, shijiStsPreClaim, ekashuPreClaim, redsysPreClaim, quickpayPreClaim, comgatePreClaim, przelewy24PreClaim, transbankPreClaim, 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/prepared-processor.d.ts

@@ -25,11 +25,15 @@
  * Cashier's card frame for a token, too soon for an approval after Pay. Its one environment is
  * production: Wix's tokenizer has no test host.
  *
+ * paygent: prepared only. Paygent's PaygentToken.js abandons its token request 35 seconds after the
+ * merchant's press sends it, too soon for an approval after the press. Its environments are its two token
+ * hosts: token.paygent.co.jp (production) and sandbox.paygent.co.jp (sandbox).
+ *
  * hipay: prepared only. The merchant's page gives HiPay's hosted fields 20 seconds after Pay, too soon for an
  * approval after Pay. Its environments are its two vault hosts: secure2-vault (production) and
  * stage-secure2-vault (sandbox).
  */
-export type PreparationProcessor = 'square' | 'braintree' | 'worldpay' | 'bambora' | 'mercado_pago' | 'recurly' | 'spreedly' | 'adyen' | 'checkout_com' | 'paysafe' | 'fiserv' | 'cybersource_flex' | 'aci' | 'creditguard' | 'worldpay_eprotect' | 'amadeus_checkout' | 'verifone' | 'cybersource_secure_acceptance' | 'paddle_vgs' | 'wix_payments' | 'hipay';
+export type PreparationProcessor = 'square' | 'braintree' | 'worldpay' | 'bambora' | 'mercado_pago' | 'recurly' | 'spreedly' | 'adyen' | 'checkout_com' | 'paysafe' | 'fiserv' | 'cybersource_flex' | 'aci' | 'creditguard' | 'worldpay_eprotect' | 'amadeus_checkout' | 'verifone' | 'cybersource_secure_acceptance' | 'paddle_vgs' | 'wix_payments' | 'paygent' | 'hipay';
 export type PreparationEnvironment = 'production' | 'sandbox' | 'shared';
 /**
  * How the approved card reaches the processor: the device's own request (token), or
@@ -66,7 +70,8 @@ export declare function preparedApprovalAnswersRetry(psp: string): boolean;
  * its own signing keys. A Verifone preparation pays in the environment of the key its reviewed
  * profile pins. CyberSource Secure Acceptance's are separate hosts too: secureacceptance is
  * live, testsecureacceptance is test. So are Paddle VGS's two card URLs: vault is live,
- * sandbox-vault is test. So are HiPay's two vault hosts: secure2-vault is live, stage-secure2-vault is test.
+ * sandbox-vault is test. So are Paygent's two token hosts: token is live, sandbox is test. So are
+ * HiPay's two vault hosts: secure2-vault is live, stage-secure2-vault is test.
  */
 export declare function validPreparationEnvironment(psp: string, environment: string): boolean;
 /**

package/dist/prepared-processor.js

@@ -15,6 +15,7 @@ import { isPreparedVerifoneRequest } from './verifone.js';
 import { isPreparedSecureAcceptanceRequest, secureAcceptanceEnvironment, secureAcceptancePreparationUrl, secureAcceptanceRequestRefusal, } from './cybersource-secure-acceptance.generated.js';
 import { PADDLE_VGS_CARDS_URLS, isPreparedPaddleVgsRequest } from './paddle-vgs.generated.js';
 import { WIX_PAYMENTS_TOKENIZE_URL, isPreparedWixPaymentsRequest } from './wix-payments.generated.js';
+import { paygentEnvironment, paygentPreparationUrl, paygentRequestRefusal } from './paygent.generated.js';
 import { HIPAY_TOKEN_URLS, hipayRequestRefusal, hipayTokenEnvironment, isPreparedHipayRequest } from './hipay.generated.js';
 export function preparationMode(psp) {
     return psp === 'adyen' || psp === 'fiserv' || psp === 'verifone' ? 'cse' : 'token';
@@ -50,7 +51,8 @@ export function preparedApprovalAnswersRetry(psp) {
  * its own signing keys. A Verifone preparation pays in the environment of the key its reviewed
  * profile pins. CyberSource Secure Acceptance's are separate hosts too: secureacceptance is
  * live, testsecureacceptance is test. So are Paddle VGS's two card URLs: vault is live,
- * sandbox-vault is test. So are HiPay's two vault hosts: secure2-vault is live, stage-secure2-vault is test.
+ * sandbox-vault is test. So are Paygent's two token hosts: token is live, sandbox is test. So are
+ * HiPay's two vault hosts: secure2-vault is live, stage-secure2-vault is test.
  */
 export function validPreparationEnvironment(psp, environment) {
     if (psp === 'bambora' || psp === 'mercado_pago' || psp === 'recurly' || psp === 'spreedly')
@@ -59,7 +61,7 @@ export function validPreparationEnvironment(psp, environment) {
     if (psp === 'wix_payments')
         return environment === 'production';
     return ['square', 'braintree', 'worldpay', 'adyen', 'checkout_com', 'paysafe', 'fiserv', 'cybersource_flex', 'aci', 'creditguard', 'worldpay_eprotect', 'amadeus_checkout', 'verifone',
-        'cybersource_secure_acceptance', 'paddle_vgs', 'hipay'].includes(psp) && ['production', 'sandbox'].includes(environment);
+        'cybersource_secure_acceptance', 'paddle_vgs', 'paygent', 'hipay'].includes(psp) && ['production', 'sandbox'].includes(environment);
 }
 /**
  * ACI's prepared endpoint, the literal the API names (backend checkout-prepared-processor.ts): its
@@ -107,6 +109,9 @@ export function preparationEndpoint(psp, environment) {
     // Wix Payments: the tokenize URL, the only URL the claim takes for it.
     if (psp === 'wix_payments')
         return WIX_PAYMENTS_TOKENIZE_URL;
+    // Paygent: the token URL on the environment's host, the only URL the claim takes for it.
+    if (psp === 'paygent')
+        return paygentPreparationUrl(environment);
     // HiPay: the token create on the environment's vault, the only URL the claim takes for it.
     if (psp === 'hipay')
         return HIPAY_TOKEN_URLS[environment];
@@ -267,6 +272,15 @@ export function matchesPreparedRequest(psp, environment, requestUrl, method, bod
     // site's app instance and the card frame's body), the rule the API and the Vault bind with too.
     if (psp === 'wix_payments')
         return isPreparedWixPaymentsRequest(requestUrl, method.toUpperCase(), body ?? null, environment, headers ?? {});
+    // Paygent: the environment's own token URL and payment-core's whole request rule (the script's text/plain
+    // and createToken's body byte for byte), the rule the API and the Vault bind with too. The method as the page
+    // sent it: the device sends only an uppercase POST. Which merchant_id and token key a live request may name
+    // is the API's to judge at the bind and the Vault's before it writes the card, against the reviewed pins
+    // each of them holds, so a merchant a later release reviews needs no new build of this library.
+    if (psp === 'paygent') {
+        return paygentEnvironment(requestUrl) === environment
+            && paygentRequestRefusal({ url: requestUrl, method, headers: headers ?? {}, body: body ?? null }) === null;
+    }
     // HiPay: the environment's own vault and payment-core's whole request rule (a JSON content type, a public username of
     // that environment and a complete create, never the hosted fields' number-only post), the rule the API and the Vault
     // bind with too.