@agent-cards/sdk 0.23.21 → 0.23.23

package/dist/pre-claim.js

@@ -80,12 +80,14 @@ import { cardEndpointCarriesCard, cardEndpointDetail, cardEndpointFor, cardEndpo
 import { cardEndpointStoppedPage, refusedNavigationOutcome } from './card-endpoint-page.js';
 import { PAYRAILS_HOLDING_REASONS, PAYRAILS_SESSION_MESSAGE, isPayrailsHost, isPayrailsPaymentUrl, isPayrailsStaticHost, payrailsKeyRefusal, payrailsPaymentRefusal, payrailsRequestKind, payrailsSaveRefusal, } from './payrails.js';
 import { classifyVerifoneProfileRequest, verifoneTemplatedUrl } from './verifone.js';
+import { isPaymentHighwayCardLookup, isPaymentHighwayHost, isPaytrailCardMethodUrl, isPaytrailEntry, isPaytrailServed } from './paytrail.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';
@@ -93,6 +95,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
@@ -1507,6 +1510,23 @@ const eprotectPreClaim = (ctx) => {
         return eprotectFailoverAbort(ctx);
     return unsupportedAbort(ctx);
 };
+// SB Payment Service, once the registry serves it (a synced build that declares its capability, for
+// an org the API enabled); for every other client the gate defers on everything, so nothing changes.
+// On SBPS's token hosts:
+//   - the token request GET the recognizer admits defers to the arbiter, which pauses it for the vault
+//     claim flow; one the registry does not cover aborts as unsupported instead of reaching SBPS;
+//   - any other request on /token/generateToken (another method, query or spelling) aborts as an
+//     unsupported checkout, so the placeholder's ciphertext never leaves;
+//   - everything else there (the scripts, the 3-D Secure info request) continues.
+// Synchronous for a token request, so it pauses in the microtask it paused in.
+const sbpsPreClaim = (ctx) => {
+    const request = ctx.sbps?.classify(ctx.request.url, ctx.request.method);
+    if (!request || request.kind === 'sibling')
+        return undefined;
+    if (request.kind === 'token_request')
+        return ctx.vault.isCardRequest(ctx.request.url, ctx.request.method) ? undefined : unsupportedAbort(ctx);
+    return unsupportedAbort(ctx);
+};
 async function eprotectFailoverAbort(ctx) {
     ctx.onEvent?.({ type: 'blocked', detail: 'eprotect_failover_aborted' });
     await ctx.effects.abort();
@@ -1667,7 +1687,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');
@@ -1697,6 +1717,32 @@ export const transbankPreClaim = (ctx) => {
         return undefined;
     return processorPageAbort(ctx);
 };
+// Paytrail's card method (paytrail.ts). Once this build's registry serves Paytrail's entry (a capability the API serves
+// only to a company Agentcard turned Paytrail on for), every request to Paytrail's entry host and to Payment Highway's
+// card page host pauses, and this gate judges the card method's posts and the card page's card lookup:
+//   - the merchant's entry (the card method's loading-and-redirect route for one transaction, exactly) defers, and the
+//     terminal arbiter pauses it for the claim flow like any card request: the cardholder's device pays it;
+//   - every other post of the card method on Paytrail's host (the loading page's post to initialize-payment, which
+//     opens Payment Highway's card page, or the entry in another spelling) aborts as an unsupported checkout, and so do
+//     every POST to Payment Highway (the card post, the Click to Pay posts, the 3-D Secure step, the older card form's
+//     post) and the card page's GET that looks up the typed card's first digits, so Payment Highway never sees the card
+//     the agent typed. The agent's browser reaches Payment Highway only when the entry was not paused (an attachment
+//     made too late, say), and then only the cardholder's device can pay.
+// Any other request (another payment method's form, the card page itself, its scripts and images) is not this gate's
+// and continues. With Paytrail 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 paytrailPreClaim = (ctx) => {
+    const { url, method } = ctx.request;
+    const post = String(method).toUpperCase() === 'POST';
+    const paymentHighway = isPaymentHighwayHost(url) && (post || isPaymentHighwayCardLookup(url, method));
+    if (!paymentHighway && !(post && isPaytrailCardMethodUrl(url)))
+        return undefined;
+    if (!isPaytrailServed(ctx.vault))
+        return undefined;
+    if (isPaytrailEntry(url, method))
+        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:
@@ -1762,6 +1808,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 +2209,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 +2238,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 +2311,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 +2337,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 +2352,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 +2360,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 +2482,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, sbpsPreClaim, wspayPreClaim, shijiStsPreClaim, ekashuPreClaim, redsysPreClaim, quickpayPreClaim, comgatePreClaim, przelewy24PreClaim, transbankPreClaim, eximbayPreClaim, paypalHostedFieldsPreClaim,
+    paypalCardFormsPreClaim, cybersourceSecureAcceptancePreClaim, worldlineMyCheckoutPreClaim, paddleVgsPayPreClaim, ebanxPreClaim, payrexxPreClaim, hipayPreClaim, paytrailPreClaim];
 /** 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.