@agent-cards/sdk 0.23.12 → 0.23.14

package/dist/ebanx.js

@@ -0,0 +1,159 @@
+/**
+ * EBANX after its card token (payment-core ebanx.js holds the rules; this SDK vendors them as ebanx.generated.ts).
+ *
+ * The adapters pause EBANX's POST /ws/token, the cardholder's device sends the real card there, and the page
+ * receives EBANX's token. EBANX's hosted payment page (payment.ebanx.com, where Nuuvem's Colombia store sends its
+ * shoppers) and EBANX.js 1.135.0 then send the card the page holds again, and on a page this SDK is attached to,
+ * that card is the agent's placeholder:
+ *   - 3-D Secure posts paymentInformation.card (number, expiry, holder) to /ws/threedsecureserver-generateToken,
+ *     -authentications and -authentication-results (up to 48 times while a Netcetera challenge polls) on the host
+ *     the token request went to;
+ *   - the hosted page's confirm posts payment.card.card_cvv, the code the agent typed, beside EBANX's token, to
+ *     /ws/checkout-v2/confirm on the invoice's host.
+ * Both adapters arm those requests on every attachment, whatever the synced registry serves, and the pre-claim
+ * gate (ebanxPreClaim, pre-claim.ts) judges each POST:
+ *   - one the approved token request on this attachment covers (EbanxFollowUps.claim: the API said the approval
+ *     covers sends after it, until when, and payment-core's rule binds the request to that approval): sent from the
+ *     cardholder's device under that same approval, with no second prompt (VaultClient.sendEbanxFollowUp), and the
+ *     page receives EBANX's answer. Never after a refused or failed send, a failed handoff of the token's answer, or a
+ *     final merchant result (completed, failed, declined, timed out, cancelled, unknown): nothing more is covered then;
+ *   - any other 3-D Secure call, or a confirm whose payment.card names a card code or number: abort, so EBANX never
+ *     receives the placeholder as a card. The page shows its own payment error and nothing is charged. The checkout
+ *     reads `unsupported` with reason `unsupported_ebanx_card_resend` and holds, as every unsupported refusal does;
+ *     after an approval it keeps the approval's state;
+ *   - a confirm whose body cannot be read: abort that request alone, since nothing proves it carries no card;
+ *   - any other request (a confirm for a bank transfer, cash or a wallet, -record, a GET, a preflight): continue.
+ * A request the synced registry recognizes as a card request belongs to that recognizer instead; no build serves
+ * one today.
+ */
+import { EBANX_CONFIRM_PATH as CONFIRM_PATH, EBANX_FOLLOW_UP_KINDS, EBANX_RESEND_HOSTS as RESEND_HOSTS, ebanxFollowUpVerdict, ebanxResendKind, ebanxResendRefusal, readEbanxTokenAnswer, readEbanxTokenRequest, } from './ebanx.generated.js';
+export const EBANX_RESEND_REASON = 'unsupported_ebanx_card_resend';
+/** EBANX's hosts for these requests (payment-core EBANX_RESEND_HOSTS). */
+export const EBANX_RESEND_HOSTS = Object.freeze([...RESEND_HOSTS]);
+/** The tenant host only the confirm uses: no card recognizer names it, so its patterns here are the only ones that pause it. */
+const CONFIRM_TENANT_HOST = 'customer-local-latam.ebanx.com';
+/**
+ * CDP Fetch patterns for the 3-D Secure calls and the confirm on each of EBANX's hosts, armed on every attachment.
+ * The card recognizer already arms every request on the hosts it names; these keep both requests armed for a client
+ * whose registry names no EBANX host. The -record call matches the 3-D Secure pattern too and continues untouched.
+ * The third pattern arms any address on the host that holds a percent-escape, since CDP matches the address as written
+ * and a server may decode /ws/%63heckout-v2/confirm to the confirm: the gate decodes the path the same way
+ * (payment-core ebanxResendKind) and continues every one that is not a card send. CDP matches literally and in one
+ * letter case, so the tenant host only the confirm uses (CONFIRM_TENANT_HOST) is armed whole, its host text anywhere
+ * in the address as the card recognizer arms its own hosts: /WS/CHECKOUT-V2/CONFIRM, //, ;x=1 and a trailing-dot
+ * host all pause, and the gate judges each one.
+ */
+export const EBANX_RESEND_PATTERNS = Object.freeze([
+    ...EBANX_RESEND_HOSTS.flatMap((host) => [`https://${host}/ws/threedsecureserver-*`, `https://${host}${CONFIRM_PATH}*`, `https://${host}/*%*`]),
+    `*${CONFIRM_TENANT_HOST}*`,
+]);
+/**
+ * Whether this URL is one of the three 3-D Secure calls that carry the card or the hosted page's confirm on an EBANX
+ * host, or an EBANX path still percent-encoded after the last decoding round, which the gate refuses as unreadable.
+ */
+export function isEbanxResendUrl(url) {
+    return ebanxResendKind(url) !== null;
+}
+/**
+ * Why this request must not leave the browser with the card the page holds, or null when it may. The body is read
+ * only for a confirm, through `readBody`, and a reader that throws reads as a body nobody could read.
+ */
+export function ebanxResendRefusalOf(url, method, readBody) {
+    return ebanxResendRefusal({
+        url, method,
+        get body() { try {
+            return readBody();
+        }
+        catch {
+            return null;
+        } },
+    });
+}
+/**
+ * A send the cardholder's device did not answer with EBANX'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` (EBANX'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 EBANX: false only when the API confirmed it never left the device. Nothing in it names the
+ * request, the card or EBANX's answer.
+ */
+export class EbanxFollowUpError extends Error {
+    reason;
+    cardSent;
+    authorizationId;
+    constructor(reason, cardSent, authorizationId) {
+        super(cardSent
+            ? `This EBANX request under ${authorizationId} has no answer, and the cardholder's device may have sent it: ${reason}.`
+            : `The cardholder's device did not send this EBANX request under ${authorizationId}: ${reason}.`);
+        this.reason = reason;
+        this.cardSent = cardSent;
+        this.authorizationId = authorizationId;
+        this.name = 'EbanxFollowUpError';
+    }
+}
+/**
+ * What one attachment keeps of its approved EBANX token request: the request and EBANX'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 token approval whose read named that window (`followUpsUntil`, served for a company Agentcard turned it on for)
+ * is kept; a later approval replaces it, and a send the window has passed is never claimed. Once the gate refuses a
+ * send or a send fails, the attachment stops (stop()): nothing after it is claimed, a later approval included, so
+ * a page the controller already reads as stopped cannot finish 3-D Secure and pay through the confirm.
+ */
+export class EbanxFollowUps {
+    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 token request went under, or null when none is remembered. The gate sends nothing
+     * unless the checkout's own state names this same approval (pre-claim.ts ebanxMaySend).
+     */
+    get authorizationId() { return this.parent?.authorizationId ?? null; }
+    /**
+     * As the adapter hands an approved token request's answer to the page: before the answer lands, since the page may
+     * send its first 3-D Secure call at once. A handoff that fails then stops the attachment (stop()).
+     */
+    remember(request, replay) {
+        const until = typeof replay.followUpsUntil === 'string' ? Date.parse(replay.followUpsUntil) : NaN;
+        if ((replay.mode ?? 'token') !== 'token' || !Number.isFinite(until))
+            return;
+        const answer = { status: replay.status, text: replay.body };
+        if (!readEbanxTokenRequest({ url: request.url, body: request.body }) || !readEbanxTokenAnswer(answer))
+            return;
+        this.parent = { authorizationId: replay.authorizationId, url: request.url, body: request.body, answer, until };
+        this.sent = [];
+    }
+    /**
+     * The claim for a paused request the remembered approval covers, or null: no approval covers sends here, its
+     * window has passed, or payment-core's rule refuses the request against the sends already claimed (the amount
+     * is left to the API and the device, which hold the approved figure). 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 = ebanxFollowUpVerdict({ parent, sent: this.sent, request: { url: request.url, method: request.method, body: request.body } }, { skipAmount: true });
+        if (!verdict.ok || !EBANX_FOLLOW_UP_KINDS.includes(verdict.kind))
+            return null;
+        const entry = { kind: verdict.kind, state: 'pending', body: request.body };
+        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 : 'text/plain' }, body: request.body },
+            settle(answer) {
+                if (entry.state !== 'pending')
+                    return;
+                if (answer) {
+                    entry.state = 'answered';
+                    entry.answer = answer;
+                }
+                else
+                    entry.state = 'failed';
+            },
+        };
+    }
+}

package/dist/index.d.ts

@@ -14,6 +14,7 @@ export type { PausedRequest, ReplayResponse, TokenReplay, CseReplay, MerchantHos
 export type { MicroformField, MicroformSidecar } from './cybersource-flex.js';
 export { attachToCdp, attachToPlaywright, corsHeadersFor, corsDecision, withCorsHeaders } from './cdp.js';
 export { CheckoutAttachmentError } from './attachment.js';
+export { EbanxFollowUpError } from './ebanx.js';
 export { CardEndpointRefusedError, cardEndpointPatterns } from './card-endpoint.js';
 export { MerchantSessionRefusedError, captureMerchantSession, merchantSessionCapture, merchantSessionReadUrl } from './merchant-session-probe.js';
 export type { MerchantSessionCapture, MerchantSessionCookie, MerchantSessionCdp, MerchantSessionRefusal } from './merchant-session-probe.js';

package/dist/index.js

@@ -5,6 +5,8 @@ export { CardEncryptedError, UnsupportedModeError, UnsupportedCapabilityError, P
 export { CONVERGE_REFUSAL_REASONS } from './elavon-converge.js';
 export { attachToCdp, attachToPlaywright, corsHeadersFor, corsDecision, withCorsHeaders } from './cdp.js';
 export { CheckoutAttachmentError } from './attachment.js';
+// EBANX after its card token: why a send an approved token request covers got no answer from the cardholder's device.
+export { EbanxFollowUpError } from './ebanx.js';
 export { CardEndpointRefusedError, cardEndpointPatterns } from './card-endpoint.js';
 // The merchant-session probe's capture (the deterministic merchant total, phase 0): no card, no Pay.
 export { MerchantSessionRefusedError, captureMerchantSession, merchantSessionCapture, merchantSessionReadUrl } from './merchant-session-probe.js';

package/dist/lifecycle.d.ts

@@ -4,6 +4,7 @@ import type { PayrailsUnsupportedReason } from './payrails.js';
 import type { Substitutions } from './substitute.js';
 import type { GmoUnsupportedReason } from './gmo.js';
 import type { ShijiStsUnsupportedReason } from './shiji-sts.js';
+import type { PaddleVgsPayRefusal } from './paddle-vgs-pay.js';
 /** The application's resolver confirmed the payment for this checkout authorization. */
 export interface MerchantPaymentConfirmation {
     kind: 'merchant_payment';
@@ -91,6 +92,11 @@ export interface ResumeResult {
         headers: Record<string, string>;
         body: string;
     };
+    /**
+     * The read's `processor_context`, as the API serves it. A Paddle VGS read carries the approved card's
+     * details here, which the frame's /pay names; without them the stored card's id is never handed to the page.
+     */
+    processor_context?: unknown;
     substitutions?: Substitutions;
     submitted_at?: string;
     execution_mode?: string;
@@ -152,6 +158,11 @@ export declare class CheckoutLifecycle implements CheckoutController {
     private ownedShopOrderId;
     private readonly handoffs;
     private reconciliation;
+    /**
+     * EBANX sends this attachment claimed that are still out (pre-claim.ts ebanxFollowUp): the cardholder's device may be
+     * sending a confirm that pays, outside `active`, so reconcile() and retryAfterMerchantFailure() wait for them too.
+     */
+    private followUpsOut;
     private preparationHandler?;
     private preparationUsed;
     private resumeHandler;
@@ -168,6 +179,21 @@ export declare class CheckoutLifecycle implements CheckoutController {
     prepared(preparation: PreparedCheckout): void;
     preparationFailed(error: CheckoutPreparationError): void;
     isBlocked(): boolean;
+    /**
+     * An EBANX send left for the cardholder's device under this attachment's approval (pre-claim.ts ebanxFollowUp). Until
+     * the returned function runs, once the send's answer reached the page or the send failed, reconcile() and
+     * retryAfterMerchantFailure() throw, as they do while a card request is active: a confirm may still pay. The returned
+     * function settles the send once, however often it runs.
+     */
+    followUpStarted(): () => void;
+    /** Whether a reconcile() is still waiting on the application's merchant resolver; pre-claim.ts claims no EBANX send then. */
+    isReconciling(): boolean;
+    /**
+     * Whether an EBANX send this attachment claimed is still out (followUpStarted). Both adapters refuse a new card
+     * request meanwhile, as they do while an approval is outstanding: a confirm that may pay is never hidden behind
+     * another payment's state.
+     */
+    followUpsInFlight(): boolean;
     isCancelled(): boolean;
     /** Whether the application gave a merchant resolver, so reconcile() reads the merchant's own record. */
     hasMerchantResolver(): boolean;
@@ -236,12 +262,18 @@ export declare class CheckoutLifecycle implements CheckoutController {
      * shiji-sts.ts reasons), a post to a processor's own card page that only
      * the cardholder's device can fill (processor_card_page: NMI's), a card
      * sent to PayPal's legacy Hosted Fields confirm, which no Vault mode takes
-     * over (unsupported_paypal_hosted_fields, paypal-hosted-fields.ts), or a card
+     * over (unsupported_paypal_hosted_fields, paypal-hosted-fields.ts), a card
      * a merchant's page posts to CyberSource Secure Acceptance's Silent Order
      * POST, which no Vault mode takes over either
-     * (unsupported_cybersource_secure_acceptance, cybersource-secure-acceptance.ts).
+     * (unsupported_cybersource_secure_acceptance, cybersource-secure-acceptance.ts), a
+     * Paddle /pay naming a stored card that its binding does not continue (the
+     * paddle-vgs-pay.ts reasons), or the typed card that EBANX's 3-D Secure calls or
+     * its hosted page's confirm send again after the token, when no approved token
+     * request on this attachment covers that send or the cardholder's device did not
+     * send it (unsupported_ebanx_card_resend, ebanx.ts): once an approval exists the
+     * state keeps it, and only the hold changes.
      */
-    unsupported(reason?: 'unrecognized_payment_endpoint' | 'merchant_profile_observe' | 'merchant_request_unsupported' | GmoUnsupportedReason | 'microform_unsupported' | 'juspay_request_unsupported' | 'merchant_card_endpoint_not_enabled' | 'merchant_card_endpoint_resend_refused' | 'creditguard_three_d_secure' | 'unsupported_primer_sdk' | 'unsupported_primer_request' | PayrailsUnsupportedReason | ShijiStsUnsupportedReason | 'processor_card_page' | 'unsupported_paypal_hosted_fields' | 'unsupported_cybersource_secure_acceptance'): void;
+    unsupported(reason?: 'unrecognized_payment_endpoint' | 'merchant_profile_observe' | 'merchant_request_unsupported' | GmoUnsupportedReason | 'microform_unsupported' | 'juspay_request_unsupported' | 'merchant_card_endpoint_not_enabled' | 'merchant_card_endpoint_resend_refused' | 'creditguard_three_d_secure' | 'unsupported_primer_sdk' | 'unsupported_primer_request' | PayrailsUnsupportedReason | ShijiStsUnsupportedReason | 'processor_card_page' | 'unsupported_paypal_hosted_fields' | 'unsupported_cybersource_secure_acceptance' | PaddleVgsPayRefusal | 'unsupported_ebanx_card_resend'): void;
     /**
      * A card request that only a prepared checkout pays (an Adyen merchant
      * profile's, or a Fiserv card capture) arrived with no preparation on this

package/dist/lifecycle.js

@@ -64,6 +64,11 @@ export class CheckoutLifecycle {
     // Every request this attachment handed the card to: see cardHandoffs().
     handoffs = [];
     reconciliation = null;
+    /**
+     * EBANX sends this attachment claimed that are still out (pre-claim.ts ebanxFollowUp): the cardholder's device may be
+     * sending a confirm that pays, outside `active`, so reconcile() and retryAfterMerchantFailure() wait for them too.
+     */
+    followUpsOut = 0;
     preparationHandler;
     preparationUsed = false;
     resumeHandler = null;
@@ -104,6 +109,28 @@ export class CheckoutLifecycle {
         this.set({ ...this.state, status: error.reason === 'expired' ? 'timed_out' : error.reason === 'cancelled' ? 'cancelled' : 'failed', reason: error.reason });
     }
     isBlocked() { return this.held || this.cancelled; }
+    /**
+     * An EBANX send left for the cardholder's device under this attachment's approval (pre-claim.ts ebanxFollowUp). Until
+     * the returned function runs, once the send's answer reached the page or the send failed, reconcile() and
+     * retryAfterMerchantFailure() throw, as they do while a card request is active: a confirm may still pay. The returned
+     * function settles the send once, however often it runs.
+     */
+    followUpStarted() {
+        this.followUpsOut += 1;
+        let settled = false;
+        return () => { if (!settled) {
+            settled = true;
+            this.followUpsOut -= 1;
+        } };
+    }
+    /** Whether a reconcile() is still waiting on the application's merchant resolver; pre-claim.ts claims no EBANX send then. */
+    isReconciling() { return this.reconciliation !== null; }
+    /**
+     * Whether an EBANX send this attachment claimed is still out (followUpStarted). Both adapters refuse a new card
+     * request meanwhile, as they do while an approval is outstanding: a confirm that may pay is never hidden behind
+     * another payment's state.
+     */
+    followUpsInFlight() { return this.followUpsOut > 0; }
     isCancelled() { return this.cancelled; }
     /** Whether the application gave a merchant resolver, so reconcile() reads the merchant's own record. */
     hasMerchantResolver() { return typeof this.options.resolveMerchantResult === 'function'; }
@@ -235,10 +262,16 @@ export class CheckoutLifecycle {
      * shiji-sts.ts reasons), a post to a processor's own card page that only
      * the cardholder's device can fill (processor_card_page: NMI's), a card
      * sent to PayPal's legacy Hosted Fields confirm, which no Vault mode takes
-     * over (unsupported_paypal_hosted_fields, paypal-hosted-fields.ts), or a card
+     * over (unsupported_paypal_hosted_fields, paypal-hosted-fields.ts), a card
      * a merchant's page posts to CyberSource Secure Acceptance's Silent Order
      * POST, which no Vault mode takes over either
-     * (unsupported_cybersource_secure_acceptance, cybersource-secure-acceptance.ts).
+     * (unsupported_cybersource_secure_acceptance, cybersource-secure-acceptance.ts), a
+     * Paddle /pay naming a stored card that its binding does not continue (the
+     * paddle-vgs-pay.ts reasons), or the typed card that EBANX's 3-D Secure calls or
+     * its hosted page's confirm send again after the token, when no approved token
+     * request on this attachment covers that send or the cardholder's device did not
+     * send it (unsupported_ebanx_card_resend, ebanx.ts): once an approval exists the
+     * state keeps it, and only the hold changes.
      */
     unsupported(reason = 'unrecognized_payment_endpoint') {
         this.held = true;
@@ -464,6 +497,8 @@ export class CheckoutLifecycle {
             return Promise.resolve(this.getState());
         if (this.active)
             throw new Error('Wait for the paused request to finish before reconciling the merchant order.');
+        if (this.followUpsOut > 0)
+            throw new Error('Wait for the EBANX send in flight to finish before reconciling the merchant order.');
         this.reconciliation = this.resolve().finally(() => { this.reconciliation = null; });
         return this.reconciliation;
     }
@@ -517,7 +552,7 @@ export class CheckoutLifecycle {
             throw new Error('This shop payment already has a receipt; another payment is not permitted.');
         if (this.preparationUsed)
             throw new Error('Prepared checkouts are single use. Reconcile this attempt and create a new attachment.');
-        if (this.active || this.reconciliation)
+        if (this.active || this.reconciliation || this.followUpsOut > 0)
             throw new Error('Cannot start another attempt while payment or reconciliation is in progress.');
         if (this.cancelled)
             throw new Error('This attachment was cancelled; attach again after reconciling the merchant order.');

package/dist/paddle-tokenex.d.ts

@@ -0,0 +1,56 @@
+/** The PSP id the API and the recognizer name this lane, re-exported so the client dispatches by it. */
+export { PADDLE_TOKENEX_PSP } from './paddle-tokenex.generated.js';
+/** The dark-launch capability a build declares when it fills a Paddle TokenEx /pay with the device's card. */
+export declare const PADDLE_TOKENEX_CAPABILITY = "paddle_tokenex_pay";
+/** A cse substitution as the API serves it (substitute.ts Substitutions): here the two ciphertexts only. */
+interface PaddleTokenexServedSubstitution {
+    encoding: string;
+    at: string;
+    fields: Record<string, string>;
+    remove?: string[];
+}
+/**
+ * Whether an approved Paddle TokenEx authorization's served substitution is one this SDK can continue: JSON
+ * at the frame's tokenex_card holder, no sibling to remove, and exactly the two ciphertext fields, each a
+ * non-empty string and distinct from the other. substitutePaddleTokenex checks each against the pinned key
+ * for the /pay's environment; this is the shape gate the client runs before it acts.
+ */
+export declare function isPaddleTokenexServedSubstitution(sub: unknown): sub is PaddleTokenexServedSubstitution;
+/** The five metadata facts the device read from the real card, served beside the ciphertexts. */
+export interface PaddleTokenexServedFacts {
+    card_first_six: string;
+    card_last_four: string;
+    expiry_month: number;
+    expiry_year: number;
+    card_brand: string;
+}
+/**
+ * Whether the API's `paddle_tokenex_facts` beside an approved set is the five facts this SDK can write over
+ * the placeholder's: exactly the five keys, the three strings as strings and the two expiry parts as
+ * numbers. paddleTokenexSubstitutionOf checks the digits, range and network at the swap; this is the shape
+ * gate the client runs before it acts, so a malformed approval is refused before anything is written.
+ */
+export declare function isPaddleTokenexServedFacts(value: unknown): value is PaddleTokenexServedFacts;
+/** The paused request an approval was created from: the URL and body the API reviewed at create. */
+export interface PaddleTokenexApprovedRequest {
+    url: string;
+    body: string;
+}
+/**
+ * The continuation of an approved Paddle TokenEx /pay: the paused body with the device's two ciphertexts
+ * written over the placeholder's at tokenex_card and the five facts over the placeholder's at metadata
+ * (payment-core substitutePaddleTokenex, which refuses a ciphertext that is not one under the pinned key
+ * for the /pay's environment, or one already in the paused body).
+ *
+ * Only into `approved`, the paused /pay the approval was created from: `url` and `body` must equal it byte
+ * for byte. The account-level TokenEx key is the same for every checkout of that seller, so the device's
+ * ciphertext could be decrypted in any later /pay of the same shape; binding it to the one request keeps
+ * this lane from ever submitting one checkout's ciphertext to another.
+ *
+ * Null when neither URL is a TokenEx /pay, so every other processor keeps the generic swap. Throws for any
+ * other body or URL, and for a substitution or facts the shape gates refuse, in each case before anything
+ * continues.
+ */
+export declare function paddleTokenexTokenContinuation(url: string, body: string, sub: unknown, facts: unknown, approved: PaddleTokenexApprovedRequest): {
+    body: string;
+} | null;

package/dist/paddle-tokenex.generated.d.ts

@@ -0,0 +1,67 @@
+declare function paddleVgsCardFactsAgree(facts: any, stored: any): boolean;
+declare var PADDLE_TOKENEX_PSP: string;
+declare var PADDLE_TOKENEX_CAPABILITY: string;
+declare var PADDLE_TOKENEX_OPERATION: string;
+declare var PADDLE_TOKENEX_SCHEME: string;
+declare var PADDLE_TOKENEX_FIELDS: readonly string[];
+declare var PADDLE_TOKENEX_FACT_KEYS: readonly string[];
+declare var PADDLE_TOKENEX_CARD_NETWORKS: readonly string[];
+declare var PADDLE_TOKENEX_REFUSAL_CODES: readonly string[];
+declare function paddleTokenexPayTarget(url: any): Readonly<{
+    environment: "production" | "sandbox";
+    line: "classic" | "billing";
+}> | null;
+declare function paddleTokenexPayCarriesCard(body: any): boolean;
+declare function isPaddleTokenexCiphertextUnderKey(value: any, environment: any): boolean;
+declare function isPaddleTokenexCiphertext(value: any, environment: any): boolean;
+declare function paddleTokenexRequestRefusal(request: any, environment: any): "paddle_tokenex_pay_unsupported" | null;
+declare function isPaddleTokenexCardRequest(request: any): boolean;
+declare function paddleTokenexBodyVerdict(body: any, line: any): Readonly<{
+    verdict: "continue";
+}> | Readonly<{
+    verdict: "card";
+}> | Readonly<{
+    verdict: "refuse";
+    code: any;
+}>;
+declare function paddleTokenexRefusalMessage(code: any): any;
+declare function paddleTokenexStoredCardRefusal(brand: any): "paddle_tokenex_card_unsupported" | null;
+declare function encryptPaddleTokenexCard(card: any, environment: any, facilities?: {}): Readonly<{
+    card_first_six: string;
+    card_last_four: string;
+    expiry_month: number;
+    expiry_year: number;
+    card_brand: "visa" | "master" | "american_express";
+    encrypted_card_number: string;
+    encrypted_cvv: string;
+}>;
+declare function paddleTokenexSubstitutionOf(value: any, environment: any): Readonly<{
+    card_first_six: any;
+    card_last_four: string;
+    expiry_month: any;
+    expiry_year: any;
+    card_brand: any;
+    encrypted_card_number: any;
+    encrypted_cvv: any;
+}> | null;
+declare function substitutePaddleTokenex(url: any, body: any, substitution: any): string;
+declare function paddleTokenexKeyUsable(authorization: any): boolean;
+declare function paddleTokenexSubstitutionsRefusal(template: any, substitution: any): {
+    code: string;
+    message: any;
+} | null;
+declare function paddleTokenexRefusalCode(text: any): string | null;
+declare function paddleTokenexAnswerOutcome(status: any, text: any): {
+    outcome: string;
+    reason: string;
+    code?: undefined;
+} | {
+    outcome: string;
+    code: string;
+    reason?: undefined;
+} | {
+    outcome: string;
+    reason?: undefined;
+    code?: undefined;
+};
+export { PADDLE_TOKENEX_CAPABILITY, PADDLE_TOKENEX_CARD_NETWORKS, PADDLE_TOKENEX_FACT_KEYS, PADDLE_TOKENEX_FIELDS, PADDLE_TOKENEX_OPERATION, PADDLE_TOKENEX_PSP, PADDLE_TOKENEX_REFUSAL_CODES, PADDLE_TOKENEX_SCHEME, encryptPaddleTokenexCard, isPaddleTokenexCardRequest, isPaddleTokenexCiphertext, isPaddleTokenexCiphertextUnderKey, paddleTokenexAnswerOutcome, paddleTokenexBodyVerdict, paddleVgsCardFactsAgree as paddleTokenexCardFactsAgree, paddleTokenexKeyUsable, paddleTokenexPayCarriesCard, paddleTokenexPayTarget, paddleTokenexRefusalCode, paddleTokenexRefusalMessage, paddleTokenexRequestRefusal, paddleTokenexStoredCardRefusal, paddleTokenexSubstitutionOf, paddleTokenexSubstitutionsRefusal, substitutePaddleTokenex };