@atumlabs/mppx-atum-escrow 0.2.2 → 0.3.0

package/dist/client.d.ts

@@ -1,8 +1,8 @@
 import * as zod_v4_core from 'zod/v4/core';
 import * as z from 'zod/mini';
 import { Signer } from 'ethers';
-import { S as SenderSigner, f as SenderSignerOptions, h as SolanaClusterUnixTimeReader } from './internal-DzEGXm14.js';
-export { A as AtumEscrowChallenge, a as AtumEscrowCredential, C as ChargeCredentialPayload, c as ChargeRequest, d as ChargeRequestSchema, e as CredentialPayloadSchema, I as INTENT, M as METHOD_NAME, g as atumEscrowChargeMethod } from './internal-DzEGXm14.js';
+import { S as SenderSigner, g as SenderSignerOptions, i as SolanaClusterUnixTimeReader } from './internal-9tB7y-A7.js';
+export { A as AtumEscrowChallenge, a as AtumEscrowCredential, C as ChargeCredentialPayload, c as ChargeRequest, d as ChargeRequestSchema, e as CredentialPayloadSchema, I as INTENT, f as INTENT_ID_META_KEY, M as METHOD_NAME, h as atumEscrowChargeMethod } from './internal-9tB7y-A7.js';
 import { Method } from 'mppx';
 export { PaymentRequest } from './generated/index.js';
 
@@ -38,16 +38,18 @@ interface AtumEscrowClientConfig {
  * built through the payment-gateway client's request builder, so the same call handles
  * EVM, Tron, and Solana sources.
  *
- * Idempotency: for EVM and Tron sources the deposit nonce (and the `request_id`) are
- * derived deterministically from the challenge id, so even if a caller rebuilds the
- * credential for the same challenge the escrow admits at most one deposit — the reused
- * nonce reverts the second on-chain. This holds only when the merchant issues a stable,
- * per-intent challenge id: set `opaque` to a per-payment identifier (e.g. an order id),
- * reused on retry of that intent, and keep `expires` stable or absent per intent (both feed
- * the challenge-id HMAC). Solana sources use a replay-window nonce rather than a
- * deterministic one and rely on the gateway's content-keyed dedup (the request id, and
- * thus the payment id, are still derived deterministically from the challenge id).
- * Building once and resubmitting the identical bytes remains the simplest safe pattern.
+ * Idempotency: the `request_id` is derived from the challenge's per-intent identifier (see
+ * {@link INTENT_ID_META_KEY}) via the shared sender_auth SDK, and `preparePaymentRequest` then
+ * derives the deposit nonce from that `request_id` on every chain. So rebuilding the credential
+ * for the same purchase reproduces the same payment identity, and the gateway de-duplicates the
+ * retry onto the original payment instead of charging twice. On EVM/Tron the reused Permit2
+ * nonce is a second, on-chain backstop (the duplicate deposit reverts); on Solana the replay
+ * nonce only guards a ~128s window, so there the gateway's `request_id` dedup is the durable
+ * protection.
+ *
+ * A challenge that carries no such identifier cannot be paid safely, so this client refuses it
+ * rather than falling back to something per-attempt. See
+ * {@link ../server!buildChargeChallenge | buildChargeChallenge} for the merchant side.
  *
  * @param config - the payer's signer, source account, and options.
  */

package/dist/client.js

@@ -8,18 +8,20 @@ import { createRequire as __atumCreateRequire } from 'module'; const require = _
 import {
   ensureSourceApproval,
   registerClient
-} from "./chunk-IPZJXELQ.js";
+} from "./chunk-ZFA5SSUP.js";
 import {
   ChargeRequestSchema,
   CredentialPayloadSchema,
   INTENT,
+  INTENT_ID_META_KEY,
   METHOD_NAME,
   atumEscrowChargeMethod
-} from "./chunk-4P34CLTO.js";
+} from "./chunk-Z3AUNEU5.js";
 export {
   ChargeRequestSchema,
   CredentialPayloadSchema,
   INTENT,
+  INTENT_ID_META_KEY,
   METHOD_NAME,
   atumEscrowChargeMethod,
   ensureSourceApproval,

package/dist/index.d.ts

@@ -1,6 +1,6 @@
-export { A as AtumEscrowChallenge, a as AtumEscrowCredential, b as AtumEscrowRequest, C as ChargeCredentialPayload, c as ChargeRequest, d as ChargeRequestSchema, e as CredentialPayloadSchema, I as INTENT, M as METHOD_NAME, S as SenderSigner, f as SenderSignerOptions, g as atumEscrowChargeMethod } from './internal-DzEGXm14.js';
+export { A as AtumEscrowChallenge, a as AtumEscrowCredential, b as AtumEscrowRequest, C as ChargeCredentialPayload, c as ChargeRequest, d as ChargeRequestSchema, e as CredentialPayloadSchema, I as INTENT, f as INTENT_ID_META_KEY, M as METHOD_NAME, S as SenderSigner, g as SenderSignerOptions, h as atumEscrowChargeMethod } from './internal-9tB7y-A7.js';
 export { AtumEscrowClientConfig, EnsureApprovalResult, ensureSourceApproval, registerClient } from './client.js';
-export { AtumEscrowCorridor, AtumEscrowReceipt, AtumEscrowServerConfig, AtumEscrowSource, ChainDefaultsSource, FulfillmentConfirmation, PaymentSubmitter, buildChargeRequest, corridorFromDefaults, registerServer, validateCorridor } from './server.js';
+export { AtumEscrowCorridor, AtumEscrowReceipt, AtumEscrowServerConfig, AtumEscrowSource, ChainDefaultsSource, ChargeChallenge, FulfillmentConfirmation, PaymentRejectedError, PaymentSettlementStatus, PaymentSubmitResult, PaymentSubmitter, SettlementErrorDetails, SettlementFailedError, SettlementPendingError, buildChargeChallenge, buildChargeRequest, corridorFromDefaults, isPaymentRejected, isSettlementFailed, isSettlementPending, registerServer, validateCorridor } from './server.js';
 export { PaymentRequest } from './generated/index.js';
 import 'zod/mini';
 import 'mppx';

package/dist/index.js

@@ -8,29 +8,45 @@ import { createRequire as __atumCreateRequire } from 'module'; const require = _
 import {
   ensureSourceApproval,
   registerClient
-} from "./chunk-IPZJXELQ.js";
+} from "./chunk-ZFA5SSUP.js";
 import {
+  PaymentRejectedError,
+  SettlementFailedError,
+  SettlementPendingError,
+  buildChargeChallenge,
   buildChargeRequest,
   corridorFromDefaults,
+  isPaymentRejected,
+  isSettlementFailed,
+  isSettlementPending,
   registerServer,
   validateCorridor
-} from "./chunk-NEM3HEZW.js";
+} from "./chunk-4YD6566T.js";
 import {
   ChargeRequestSchema,
   CredentialPayloadSchema,
   INTENT,
+  INTENT_ID_META_KEY,
   METHOD_NAME,
   atumEscrowChargeMethod
-} from "./chunk-4P34CLTO.js";
+} from "./chunk-Z3AUNEU5.js";
 export {
   ChargeRequestSchema,
   CredentialPayloadSchema,
   INTENT,
+  INTENT_ID_META_KEY,
   METHOD_NAME,
+  PaymentRejectedError,
+  SettlementFailedError,
+  SettlementPendingError,
   atumEscrowChargeMethod,
+  buildChargeChallenge,
   buildChargeRequest,
   corridorFromDefaults,
   ensureSourceApproval,
+  isPaymentRejected,
+  isSettlementFailed,
+  isSettlementPending,
   registerClient,
   registerServer,
   validateCorridor

package/dist/{internal-DzEGXm14.d.ts → internal-9tB7y-A7.d.ts}

@@ -245,6 +245,24 @@ interface AtumEscrowExtra {
 declare const METHOD_NAME = "atum-escrow";
 /** The MPP intent this method implements. */
 declare const INTENT = "charge";
+/**
+ * Challenge-metadata key carrying the merchant's per-intent payment identifier.
+ *
+ * The payer derives the payment's `request_id` from this value, and the gateway
+ * de-duplicates on that `request_id`. So the key's lifetime defines what counts as "the same
+ * payment": one value per thing being bought, reused on every retry of that purchase, never
+ * shared between two purchases.
+ *
+ * It rides in challenge metadata rather than in the charge request because it identifies the
+ * purchase, not its terms — two sequential orders for the same item have identical terms and
+ * must still be two payments. Metadata is covered by the challenge-id HMAC, so a payer cannot
+ * substitute another intent's identifier to have a second purchase resolve onto an
+ * already-settled payment.
+ *
+ * Prefixed to keep it distinct from a merchant's own metadata and from the framework's
+ * reserved keys.
+ */
+declare const INTENT_ID_META_KEY = "atumIntentId";
 /**
  * Schema for the `charge` challenge request — the method-specific data a merchant
  * publishes in an MPP `402` challenge. It describes what the merchant receives and the
@@ -344,4 +362,4 @@ declare const atumEscrowChargeMethod: {
     };
 };
 
-export { type AtumEscrowChallenge as A, type ChargeCredentialPayload as C, INTENT as I, METHOD_NAME as M, type SenderSigner as S, type AtumEscrowCredential as a, type AtumEscrowRequest as b, type ChargeRequest as c, ChargeRequestSchema as d, CredentialPayloadSchema as e, type SenderSignerOptions as f, atumEscrowChargeMethod as g, type SolanaClusterUnixTimeReader as h, type ChainDefaults as i };
+export { type AtumEscrowChallenge as A, type ChargeCredentialPayload as C, INTENT as I, METHOD_NAME as M, type SenderSigner as S, type AtumEscrowCredential as a, type AtumEscrowRequest as b, type ChargeRequest as c, ChargeRequestSchema as d, CredentialPayloadSchema as e, INTENT_ID_META_KEY as f, type SenderSignerOptions as g, atumEscrowChargeMethod as h, type SolanaClusterUnixTimeReader as i, type ChainDefaults as j };

package/dist/server.d.ts

@@ -1,8 +1,8 @@
 import * as zod_v4_core from 'zod/v4/core';
 import * as z from 'zod/mini';
-import { i as ChainDefaults, c as ChargeRequest } from './internal-DzEGXm14.js';
-export { A as AtumEscrowChallenge, a as AtumEscrowCredential, C as ChargeCredentialPayload, d as ChargeRequestSchema, e as CredentialPayloadSchema, I as INTENT, M as METHOD_NAME, g as atumEscrowChargeMethod } from './internal-DzEGXm14.js';
-import { Receipt, Method } from 'mppx';
+import { j as ChainDefaults, c as ChargeRequest } from './internal-9tB7y-A7.js';
+export { A as AtumEscrowChallenge, a as AtumEscrowCredential, C as ChargeCredentialPayload, d as ChargeRequestSchema, e as CredentialPayloadSchema, I as INTENT, f as INTENT_ID_META_KEY, M as METHOD_NAME, h as atumEscrowChargeMethod } from './internal-9tB7y-A7.js';
+import { Errors, Receipt, Method } from 'mppx';
 import { PaymentRequest } from './generated/index.js';
 export { PaymentRequest } from './generated/index.js';
 
@@ -53,6 +53,131 @@ interface FulfillmentConfirmation {
     destination_block_number?: number;
 }
 
+/**
+ * Settlement outcomes that are not a receipt.
+ *
+ * MPP models a completed payment and nothing else: a receipt's status is the literal
+ * `"success"`, so a payment that has not settled cannot be expressed as one and has to leave
+ * `verify()` as a throw. What matters is that the two non-success outcomes stay
+ * distinguishable, because they call for opposite responses:
+ *
+ * - {@link SettlementPendingError} — the payment is still settling. Retrying the SAME purchase
+ *   is safe and is how the payer collects the result: the identifier it derives from resolves to
+ *   this same payment, so the gateway returns the original rather than charging again.
+ * - {@link SettlementFailedError} — the payment reached a terminal failure. Retrying the same
+ *   purchase resolves to the dead payment forever, so recovering means starting a NEW purchase
+ *   under a new identifier.
+ *
+ * Both carry the gateway's payment id when one was issued, so a merchant can reconcile the
+ * attempt against the gateway without parsing a message.
+ *
+ * Both extend the framework's error types, so a merchant that does not distinguish them still
+ * gets the standard `402` + problem-details response.
+ *
+ * @packageDocumentation
+ */
+
+/** Fields shared by both settlement outcomes. */
+interface SettlementErrorDetails {
+    /** The gateway's payment id, when the payment was accepted and given one. */
+    readonly paymentId: string | undefined;
+}
+/** True if the payment is still settling — a retry of the same purchase is safe. */
+declare function isSettlementPending(err: unknown): err is SettlementPendingError;
+/** True if the payment reached a terminal failure — the same purchase can never settle. */
+declare function isSettlementFailed(err: unknown): err is SettlementFailedError;
+/** True if the gateway refused the request outright — nothing was charged. */
+declare function isPaymentRejected(err: unknown): err is PaymentRejectedError;
+/**
+ * The payment was accepted but had not settled when the merchant's synchronous window closed.
+ *
+ * Not a failure: the payment is in flight. Re-attempting the same purchase is safe — it resolves to
+ * this payment and returns its result once settled.
+ *
+ * **What re-attempting means.** Run the purchase again: request a fresh challenge and sign it again,
+ * keeping the same intent id. The intent id is what makes the re-attempt resolve onto the payment
+ * already in flight rather than taking a second one, so it must not change — while everything
+ * time-bound about the authorization must, because the deadlines are absolute timestamps fixed when
+ * it was signed. A stored credential therefore cannot simply be presented a second time; once its
+ * quote window has closed it is refused, and on Solana the deposit authorization carries its own
+ * replay window that expires with it.
+ *
+ * A payment-enabled `fetch` does this for the caller, since each attempt fetches a new challenge.
+ * Code that drives the client directly has to rebuild.
+ */
+declare class SettlementPendingError extends Errors.PaymentActionRequiredError implements SettlementErrorDetails {
+    /** Discriminant; test it with {@link isSettlementPending}. */
+    readonly isSettlementPending: true;
+    readonly paymentId: string | undefined;
+    constructor(options?: {
+        paymentId?: string | undefined;
+    });
+    /**
+     * Adds `paymentId` as its own field, not just interpolated into `detail`'s prose. A merchant
+     * catching this in-process already has `.paymentId`; a real cross-network payer only ever
+     * sees this JSON body, and without a dedicated field would have to parse it out of a sentence
+     * to reconcile the attempt against the gateway. The return type is declared (not left to
+     * inference) so a TypeScript merchant that re-serializes through the base type still sees
+     * `paymentId` in intellisense.
+     */
+    toProblemDetails(challengeId?: string): Errors.PaymentError.ProblemDetails & {
+        paymentId?: string;
+    };
+}
+/**
+ * The payment reached a terminal failure state and will not settle.
+ *
+ * A retry of the same purchase cannot recover it: that purchase's identifier now resolves to
+ * this failed payment. Recovering means a new purchase under a new identifier.
+ */
+declare class SettlementFailedError extends Errors.VerificationFailedError implements SettlementErrorDetails {
+    /** Discriminant; test it with {@link isSettlementFailed}. */
+    readonly isSettlementFailed: true;
+    readonly paymentId: string | undefined;
+    /** The terminal state the gateway reported. */
+    readonly state: string;
+    constructor(options: {
+        paymentId?: string | undefined;
+        state: string;
+    });
+    /**
+     * Adds `paymentId` and `state` as their own fields, not just interpolated into `detail`'s
+     * prose — see {@link SettlementPendingError.toProblemDetails} for why a payer needs this on
+     * the wire, not only a same-process merchant. Return type declared for the same reason: so a
+     * TypeScript merchant sees `paymentId`/`state` in intellisense, not only at runtime.
+     */
+    toProblemDetails(challengeId?: string): Errors.PaymentError.ProblemDetails & {
+        paymentId?: string;
+        state: string;
+    };
+}
+/**
+ * The gateway refused the payment outright — it never entered settlement.
+ *
+ * Distinct from {@link SettlementFailedError}: nothing was charged and nothing is in flight, so
+ * the fault is in the request and fixing it makes the same purchase payable. The most common
+ * cause is reusing one purchase identifier for two different sets of terms, which the gateway
+ * rejects rather than silently resolving to the first payment.
+ *
+ * Thrown by a {@link ../server!PaymentSubmitter | PaymentSubmitter} — the submitter owns the
+ * gateway call, so it is the only place that can tell a refusal (the request was rejected) from
+ * a transport or server failure (the outcome is unknown, and reporting it as a refusal would
+ * invite a second payment). Classify on the response status rather than on the body, so an
+ * intermediary that rewrites the error payload cannot turn a refusal into an unknown outcome.
+ * Raising it preserves the gateway's error code through to the payer instead of flattening every
+ * cause into one generic verification failure.
+ */
+declare class PaymentRejectedError extends Errors.BadRequestError {
+    /** Discriminant; test it with {@link isPaymentRejected}. */
+    readonly isPaymentRejected: true;
+    /** The gateway's error code, for programmatic handling. */
+    readonly code: string;
+    constructor(options: {
+        code: string;
+        detail: string;
+    });
+}
+
 /** One source chain/token the merchant accepts payment from. */
 interface AtumEscrowSource {
     /** CAIP-2 source chain id (e.g. `eip155:8453`, `tron:mainnet`, `solana:<genesis>`). */
@@ -95,15 +220,37 @@ interface AtumEscrowCorridor {
     /** Accepted source options; selected per charge by `(network, asset)`. */
     sources: AtumEscrowSource[];
 }
+/** Lifecycle state the gateway reports for a payment. */
+type PaymentSettlementStatus = "pending" | "completed" | "failed" | "cancelled";
+/** What a {@link PaymentSubmitter} resolves with. */
+interface PaymentSubmitResult {
+    /** The gateway's payment id. Present whenever the payment was accepted. */
+    payment_id?: string;
+    /**
+     * The payment's state. When absent, an unsettled payment is treated as still in flight —
+     * the conservative reading, since calling an in-flight payment failed would tell the payer to
+     * start a second one.
+     */
+    status?: PaymentSettlementStatus;
+    /** The settlement confirmation, present once the payment has completed. */
+    fulfillment_confirmation?: FulfillmentConfirmation;
+}
 /**
  * Submits a signed payment request to the Atum Payment Gateway and resolves with the
  * settlement result. Satisfied by an adapter over `@atum-labs/payment-gateway-client`.
+ *
+ * Submit and return what the gateway said; do not poll for completion inside the submitter.
+ * A payment that outlives the gateway's synchronous window surfaces to the payer as
+ * {@link SettlementPendingError}, and the payer's retry of the same purchase is what collects the
+ * result — the gateway resolves that retry to the same payment. Polling inside the submitter
+ * instead holds the merchant's request open for the full settlement window and hides the pending
+ * state that makes the retry safe.
+ *
+ * Throw {@link PaymentRejectedError} when the gateway refuses the request, so the refusal keeps
+ * its code. Any other throw is treated as an unknown outcome.
  */
 interface PaymentSubmitter {
-    submit(request: PaymentRequest): Promise<{
-        payment_id?: string;
-        fulfillment_confirmation?: FulfillmentConfirmation;
-    }>;
+    submit(request: PaymentRequest): Promise<PaymentSubmitResult>;
 }
 /** Configuration for the merchant side of the method. */
 interface AtumEscrowServerConfig {
@@ -182,10 +329,16 @@ declare function registerServer(config: AtumEscrowServerConfig): Method.Server<{
  */
 declare function validateCorridor(corridor: AtumEscrowCorridor): void;
 /**
- * Build the `charge` challenge request for a specific source option from a corridor. The
- * merchant uses this to construct the 402 challenge; the source cap is
- * `fulfillmentAmount + markup`, quoted in the source token. The corridor is validated
- * first, so a misconfiguration fails here rather than at signing time.
+ * Build the `charge` challenge request for a specific source option from a corridor — the
+ * payment terms alone. The source cap is `fulfillmentAmount + markup`, quoted in the source
+ * token. The corridor is validated first, so a misconfiguration fails here rather than at
+ * signing time.
+ *
+ * Prefer {@link buildChargeChallenge}, which pairs these terms with the per-purchase identifier
+ * the payer requires. A challenge built from this function alone carries no such identifier and
+ * the payer's client refuses it — at signing time, not at build time, so code that calls this
+ * directly and worked before only surfaces the problem when a real payer's client refuses the
+ * payment. Reach for it directly only when supplying the per-purchase metadata by hand.
  *
  * @param corridor - the corridor to serve.
  * @param select - which configured source to fund from, by `(network, asset)`.
@@ -205,6 +358,62 @@ declare function buildChargeRequest(corridor: AtumEscrowCorridor, select: {
 }, fulfillmentAmount: string, options?: {
     issuedAt?: string;
 }): ChargeRequest;
+/**
+ * A charge challenge's two halves, ready to hand to the framework.
+ *
+ * They are separate because the framework keeps them separate: `request` is the
+ * method-specific payment terms, `meta` is challenge metadata. Both are covered by the
+ * challenge-id HMAC, but nesting the metadata inside the request would bury the purchase
+ * identifier in the terms blob where the payer does not look for it — so this type keeps them in
+ * the shape the framework expects.
+ */
+interface ChargeChallenge {
+    /** The method-specific charge request (the payment terms). */
+    request: ChargeRequest;
+    /** Challenge metadata carrying the per-intent identifier. */
+    meta: Record<string, string>;
+}
+/**
+ * Build a charge challenge for a specific source option from a corridor.
+ *
+ * This is the entry point a merchant should use: it pairs the payment terms with the per-purchase
+ * identifier the payer needs to make the payment retry-safe. A challenge built without that
+ * identifier is refused by the payer's client rather than paid unsafely.
+ *
+ * Pass the result straight through to the framework:
+ *
+ * ```ts
+ * const { request, meta } = buildChargeChallenge(corridor, source, amount, { intentId: order.id })
+ *
+ * // Route-handler style:
+ * mppx.compose(['atum-escrow/charge', { ...request, meta }])(input)
+ *
+ * // Or building the challenge directly:
+ * Challenge.fromMethod(atumEscrowChargeMethod, { request, meta, realm, secretKey })
+ * ```
+ *
+ * @param corridor - the corridor to serve.
+ * @param select - which configured source to fund from, by `(network, asset)`.
+ * @param fulfillmentAmount - exact amount the merchant receives, atomic units of the
+ *   destination token.
+ * @param options.intentId - identifies the thing being bought. Use the merchant's own order,
+ *   invoice, or cart identifier: one value per purchase, the SAME value every time that purchase
+ *   is re-offered or retried, and never shared between two purchases. The payer derives the
+ *   payment's identity from it and the gateway de-duplicates on that, so its lifetime is what
+ *   decides whether a retry is recognized (a value that changes per attempt causes a second
+ *   charge) and whether two purchases stay distinct (a value shared between them leaves the
+ *   second unpaid). Do not derive it from the terms: two orders for the same item have identical
+ *   terms.
+ * @param options.issuedAt - Solana-source only; see {@link buildChargeRequest}.
+ * @throws if `intentId` is empty, or the corridor/source selection is invalid.
+ */
+declare function buildChargeChallenge(corridor: AtumEscrowCorridor, select: {
+    network: string;
+    asset: string;
+}, fulfillmentAmount: string, options: {
+    intentId: string;
+    issuedAt?: string;
+}): ChargeChallenge;
 /** The minimal defaults source `corridorFromDefaults` needs; satisfied by the gateway client. */
 interface ChainDefaultsSource {
     fetchChainDefaults(chainId: string): Promise<ChainDefaults>;
@@ -235,4 +444,4 @@ declare function corridorFromDefaults(defaults: ChainDefaultsSource, params: {
     fulfillmentDeadlineSeconds: number;
 }): Promise<AtumEscrowCorridor>;
 
-export { type AtumEscrowCorridor, type AtumEscrowReceipt, type AtumEscrowServerConfig, type AtumEscrowSource, type ChainDefaultsSource, ChargeRequest, type FulfillmentConfirmation, type PaymentSubmitter, buildChargeRequest, corridorFromDefaults, registerServer, validateCorridor };
+export { type AtumEscrowCorridor, type AtumEscrowReceipt, type AtumEscrowServerConfig, type AtumEscrowSource, type ChainDefaultsSource, type ChargeChallenge, ChargeRequest, type FulfillmentConfirmation, PaymentRejectedError, type PaymentSettlementStatus, type PaymentSubmitResult, type PaymentSubmitter, type SettlementErrorDetails, SettlementFailedError, SettlementPendingError, buildChargeChallenge, buildChargeRequest, corridorFromDefaults, isPaymentRejected, isSettlementFailed, isSettlementPending, registerServer, validateCorridor };

package/dist/server.js

@@ -6,26 +6,42 @@
  */
 import { createRequire as __atumCreateRequire } from 'module'; const require = __atumCreateRequire(import.meta.url);
 import {
+  PaymentRejectedError,
+  SettlementFailedError,
+  SettlementPendingError,
+  buildChargeChallenge,
   buildChargeRequest,
   corridorFromDefaults,
+  isPaymentRejected,
+  isSettlementFailed,
+  isSettlementPending,
   registerServer,
   validateCorridor
-} from "./chunk-NEM3HEZW.js";
+} from "./chunk-4YD6566T.js";
 import {
   ChargeRequestSchema,
   CredentialPayloadSchema,
   INTENT,
+  INTENT_ID_META_KEY,
   METHOD_NAME,
   atumEscrowChargeMethod
-} from "./chunk-4P34CLTO.js";
+} from "./chunk-Z3AUNEU5.js";
 export {
   ChargeRequestSchema,
   CredentialPayloadSchema,
   INTENT,
+  INTENT_ID_META_KEY,
   METHOD_NAME,
+  PaymentRejectedError,
+  SettlementFailedError,
+  SettlementPendingError,
   atumEscrowChargeMethod,
+  buildChargeChallenge,
   buildChargeRequest,
   corridorFromDefaults,
+  isPaymentRejected,
+  isSettlementFailed,
+  isSettlementPending,
   registerServer,
   validateCorridor
 };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@atumlabs/mppx-atum-escrow",
-  "version": "0.2.2",
+  "version": "0.3.0",
   "description": "Atum cross-chain escrow payment method for the Machine Payments Protocol (MPP).",
   "author": "Atum Labs, Inc.",
   "license": "SEE LICENSE IN LICENSE",