@astrasyncai/verification-gateway 5.4.2 → 5.6.0

package/dist/{types-Bd2O3eX1.d.mts → types-BCmHFdkJ.d.mts}

@@ -425,11 +425,72 @@ interface VerificationResult {
      * instrument on file (steer the user to add one via onboarding).
      */
     settlementOutcome?: SettlementOutcomeInfo;
+    /**
+     * 5.5.0 (astra-pay): interim merchant self-settlement token. Present ONLY
+     * for firstParty merchants opted into settlement_mode='self_settle' on the
+     * confirm leg — YOUR server charges with this material on the shared Stripe
+     * account and reports the outcome via `client.reportSettlement()`.
+     * MERCHANT-ONLY lane: never expose it to the agent plane, never log it,
+     * never echo it back over the bridge handoff (the bridge strips it
+     * defensively). Charge with idempotency key `voucher:<jti>` and
+     * `metadata.jti` — that lets the platform webhook auto-reconcile even if
+     * your report never arrives.
+     */
+    settlementToken?: MerchantSettlementToken;
+    /**
+     * 5.6.0 (astra-pay): fulfilment contact for first-party confirm legs.
+     * The platform always resolves an email for the merchant — the agent's
+     * `buyerEmail` when one was supplied, else the buyer's account email
+     * (`emailSource` says which). Present on every first-party confirm leg that
+     * progressed (settled, pending_merchant, held, requires_action) so it can be
+     * stored with a pending order; only FULFIL against it once the order is
+     * settled / pending_merchant. MERCHANT-ONLY lane like `settlementToken` —
+     * the bridge strips it from the agent plane. An explicit `buyerEmail` on the
+     * confirm handoff body wins over `fulfilment.email` (the platform default).
+     */
+    fulfilment?: FulfilmentInfo;
     /** Timestamp of verification */
     verifiedAt: Date;
     /** TTL for this result (seconds) */
     cacheTtl?: number;
 }
+/**
+ * 5.5.0 (astra-pay): agent-blind settlement token for self-settling
+ * first-party merchants. Self-describing via `type`, so a Stripe Shared
+ * Payment Token can replace the raw customer/payment-method pair without a
+ * contract change.
+ */
+interface MerchantSettlementToken {
+    type: 'stripe_delegated_charge';
+    stripeCustomerId: string;
+    stripePaymentMethodId: string;
+    /** Integer minor units — money is never a float on the wire. */
+    amountMinor: number;
+    /** Upper-case ISO-4217. */
+    currency: string;
+    /** Verification session id — the report-back key. */
+    sessionId: string | null;
+    /** The pending kya_shop_order row your report resolves. */
+    orderId: string;
+    /** Settlement spine: charge with Stripe idempotency key `voucher:<jti>`
+     * and set `metadata.jti` on the PaymentIntent. */
+    jti: string;
+    statementSuffix: string | null;
+    /** Advisory charge-by bound (ISO); stuck orders are ops-swept after it. */
+    expiresAt: string;
+}
+/**
+ * 5.6.0 (astra-pay): fulfilment contact block. `emailSource` is an OPEN union
+ * (same rule as settlement statuses): treat unknown sources like
+ * 'agent_provided' — the email is still the one to use.
+ */
+interface FulfilmentInfo {
+    /** Canonicalized (trimmed, lower-cased) receipt/delivery email. */
+    email: string;
+    /** 'agent_provided' = the agent passed buyerEmail on this confirm;
+     * 'account' = platform default — the buyer's account email. */
+    emailSource: 'agent_provided' | 'account' | (string & {});
+}
 /**
  * 5.3.0 (astra-pay): sanitized outcome of first-party charge-at-redeem
  * settlement. Carries NO voucher/instrument material — the settlement channel
@@ -440,9 +501,16 @@ interface VerificationResult {
  * approves, the platform re-drives the confirm with the SAME
  * checkoutSessionId and that re-drive carries the settling outcome
  * (one order row per session — the re-drive claims the same row).
+ *
+ * 5.5.0: OPEN union — the platform may introduce statuses (e.g.
+ * `pending_merchant` for self-settling merchants) ahead of your SDK version.
+ * Rule: treat any status you don't recognize as PENDING, never as failed.
+ * Also 5.5.0: `no_instrument` on a held/approved session is NON-terminal —
+ * the human's approval is NOT consumed; a re-drive with the same
+ * checkoutSessionId settles once a card is on file.
  */
 interface SettlementOutcomeInfo {
-    status: 'settled' | 'failed' | 'requires_action' | 'no_instrument' | 'requires_approval';
+    status: 'settled' | 'failed' | 'requires_action' | 'no_instrument' | 'requires_approval' | 'pending_merchant' | (string & {});
     /** First-party order id — the buyer sees the purchase in their AstraSync
      * dashboard orders view (no public receipt page). */
     orderId?: string;
@@ -532,6 +600,15 @@ interface VerificationRequest {
             currency: string;
         };
     }>;
+    /**
+     * 5.6.0 (astra-pay): buyer's receipt/delivery email, forwarded on the
+     * confirm leg only. TRANSIT-ONLY fulfilment PII — the platform echoes it
+     * back (canonicalized) in `VerificationResult.fulfilment` for first-party
+     * merchants and never persists it. When omitted, the platform defaults
+     * `fulfilment.email` to the buyer's account email, so supplying this is
+     * only needed for an alternate contact (gift delivery etc.).
+     */
+    buyerEmail?: string;
     /** Whether this is a sub-agent request */
     isSubAgentRequest?: boolean;
     /** Parent agent ID for sub-agent requests */

package/dist/{types-BU04qAAR.d.mts → types-BK_pRNSs.d.mts}

@@ -475,11 +475,72 @@ interface VerificationResult {
      * instrument on file (steer the user to add one via onboarding).
      */
     settlementOutcome?: SettlementOutcomeInfo;
+    /**
+     * 5.5.0 (astra-pay): interim merchant self-settlement token. Present ONLY
+     * for firstParty merchants opted into settlement_mode='self_settle' on the
+     * confirm leg — YOUR server charges with this material on the shared Stripe
+     * account and reports the outcome via `client.reportSettlement()`.
+     * MERCHANT-ONLY lane: never expose it to the agent plane, never log it,
+     * never echo it back over the bridge handoff (the bridge strips it
+     * defensively). Charge with idempotency key `voucher:<jti>` and
+     * `metadata.jti` — that lets the platform webhook auto-reconcile even if
+     * your report never arrives.
+     */
+    settlementToken?: MerchantSettlementToken;
+    /**
+     * 5.6.0 (astra-pay): fulfilment contact for first-party confirm legs.
+     * The platform always resolves an email for the merchant — the agent's
+     * `buyerEmail` when one was supplied, else the buyer's account email
+     * (`emailSource` says which). Present on every first-party confirm leg that
+     * progressed (settled, pending_merchant, held, requires_action) so it can be
+     * stored with a pending order; only FULFIL against it once the order is
+     * settled / pending_merchant. MERCHANT-ONLY lane like `settlementToken` —
+     * the bridge strips it from the agent plane. An explicit `buyerEmail` on the
+     * confirm handoff body wins over `fulfilment.email` (the platform default).
+     */
+    fulfilment?: FulfilmentInfo;
     /** Timestamp of verification */
     verifiedAt: Date;
     /** TTL for this result (seconds) */
     cacheTtl?: number;
 }
+/**
+ * 5.5.0 (astra-pay): agent-blind settlement token for self-settling
+ * first-party merchants. Self-describing via `type`, so a Stripe Shared
+ * Payment Token can replace the raw customer/payment-method pair without a
+ * contract change.
+ */
+interface MerchantSettlementToken {
+    type: 'stripe_delegated_charge';
+    stripeCustomerId: string;
+    stripePaymentMethodId: string;
+    /** Integer minor units — money is never a float on the wire. */
+    amountMinor: number;
+    /** Upper-case ISO-4217. */
+    currency: string;
+    /** Verification session id — the report-back key. */
+    sessionId: string | null;
+    /** The pending kya_shop_order row your report resolves. */
+    orderId: string;
+    /** Settlement spine: charge with Stripe idempotency key `voucher:<jti>`
+     * and set `metadata.jti` on the PaymentIntent. */
+    jti: string;
+    statementSuffix: string | null;
+    /** Advisory charge-by bound (ISO); stuck orders are ops-swept after it. */
+    expiresAt: string;
+}
+/**
+ * 5.6.0 (astra-pay): fulfilment contact block. `emailSource` is an OPEN union
+ * (same rule as settlement statuses): treat unknown sources like
+ * 'agent_provided' — the email is still the one to use.
+ */
+interface FulfilmentInfo {
+    /** Canonicalized (trimmed, lower-cased) receipt/delivery email. */
+    email: string;
+    /** 'agent_provided' = the agent passed buyerEmail on this confirm;
+     * 'account' = platform default — the buyer's account email. */
+    emailSource: 'agent_provided' | 'account' | (string & {});
+}
 /**
  * 5.3.0 (astra-pay): sanitized outcome of first-party charge-at-redeem
  * settlement. Carries NO voucher/instrument material — the settlement channel
@@ -490,9 +551,16 @@ interface VerificationResult {
  * approves, the platform re-drives the confirm with the SAME
  * checkoutSessionId and that re-drive carries the settling outcome
  * (one order row per session — the re-drive claims the same row).
+ *
+ * 5.5.0: OPEN union — the platform may introduce statuses (e.g.
+ * `pending_merchant` for self-settling merchants) ahead of your SDK version.
+ * Rule: treat any status you don't recognize as PENDING, never as failed.
+ * Also 5.5.0: `no_instrument` on a held/approved session is NON-terminal —
+ * the human's approval is NOT consumed; a re-drive with the same
+ * checkoutSessionId settles once a card is on file.
  */
 interface SettlementOutcomeInfo {
-    status: 'settled' | 'failed' | 'requires_action' | 'no_instrument' | 'requires_approval';
+    status: 'settled' | 'failed' | 'requires_action' | 'no_instrument' | 'requires_approval' | 'pending_merchant' | (string & {});
     /** First-party order id — the buyer sees the purchase in their AstraSync
      * dashboard orders view (no public receipt page). */
     orderId?: string;
@@ -582,6 +650,15 @@ interface VerificationRequest {
             currency: string;
         };
     }>;
+    /**
+     * 5.6.0 (astra-pay): buyer's receipt/delivery email, forwarded on the
+     * confirm leg only. TRANSIT-ONLY fulfilment PII — the platform echoes it
+     * back (canonicalized) in `VerificationResult.fulfilment` for first-party
+     * merchants and never persists it. When omitted, the platform defaults
+     * `fulfilment.email` to the buyer's account email, so supplying this is
+     * only needed for an alternate contact (gift delivery etc.).
+     */
+    buyerEmail?: string;
     /** Whether this is a sub-agent request */
     isSubAgentRequest?: boolean;
     /** Parent agent ID for sub-agent requests */

package/dist/{types-BU04qAAR.d.ts → types-BK_pRNSs.d.ts}

@@ -475,11 +475,72 @@ interface VerificationResult {
      * instrument on file (steer the user to add one via onboarding).
      */
     settlementOutcome?: SettlementOutcomeInfo;
+    /**
+     * 5.5.0 (astra-pay): interim merchant self-settlement token. Present ONLY
+     * for firstParty merchants opted into settlement_mode='self_settle' on the
+     * confirm leg — YOUR server charges with this material on the shared Stripe
+     * account and reports the outcome via `client.reportSettlement()`.
+     * MERCHANT-ONLY lane: never expose it to the agent plane, never log it,
+     * never echo it back over the bridge handoff (the bridge strips it
+     * defensively). Charge with idempotency key `voucher:<jti>` and
+     * `metadata.jti` — that lets the platform webhook auto-reconcile even if
+     * your report never arrives.
+     */
+    settlementToken?: MerchantSettlementToken;
+    /**
+     * 5.6.0 (astra-pay): fulfilment contact for first-party confirm legs.
+     * The platform always resolves an email for the merchant — the agent's
+     * `buyerEmail` when one was supplied, else the buyer's account email
+     * (`emailSource` says which). Present on every first-party confirm leg that
+     * progressed (settled, pending_merchant, held, requires_action) so it can be
+     * stored with a pending order; only FULFIL against it once the order is
+     * settled / pending_merchant. MERCHANT-ONLY lane like `settlementToken` —
+     * the bridge strips it from the agent plane. An explicit `buyerEmail` on the
+     * confirm handoff body wins over `fulfilment.email` (the platform default).
+     */
+    fulfilment?: FulfilmentInfo;
     /** Timestamp of verification */
     verifiedAt: Date;
     /** TTL for this result (seconds) */
     cacheTtl?: number;
 }
+/**
+ * 5.5.0 (astra-pay): agent-blind settlement token for self-settling
+ * first-party merchants. Self-describing via `type`, so a Stripe Shared
+ * Payment Token can replace the raw customer/payment-method pair without a
+ * contract change.
+ */
+interface MerchantSettlementToken {
+    type: 'stripe_delegated_charge';
+    stripeCustomerId: string;
+    stripePaymentMethodId: string;
+    /** Integer minor units — money is never a float on the wire. */
+    amountMinor: number;
+    /** Upper-case ISO-4217. */
+    currency: string;
+    /** Verification session id — the report-back key. */
+    sessionId: string | null;
+    /** The pending kya_shop_order row your report resolves. */
+    orderId: string;
+    /** Settlement spine: charge with Stripe idempotency key `voucher:<jti>`
+     * and set `metadata.jti` on the PaymentIntent. */
+    jti: string;
+    statementSuffix: string | null;
+    /** Advisory charge-by bound (ISO); stuck orders are ops-swept after it. */
+    expiresAt: string;
+}
+/**
+ * 5.6.0 (astra-pay): fulfilment contact block. `emailSource` is an OPEN union
+ * (same rule as settlement statuses): treat unknown sources like
+ * 'agent_provided' — the email is still the one to use.
+ */
+interface FulfilmentInfo {
+    /** Canonicalized (trimmed, lower-cased) receipt/delivery email. */
+    email: string;
+    /** 'agent_provided' = the agent passed buyerEmail on this confirm;
+     * 'account' = platform default — the buyer's account email. */
+    emailSource: 'agent_provided' | 'account' | (string & {});
+}
 /**
  * 5.3.0 (astra-pay): sanitized outcome of first-party charge-at-redeem
  * settlement. Carries NO voucher/instrument material — the settlement channel
@@ -490,9 +551,16 @@ interface VerificationResult {
  * approves, the platform re-drives the confirm with the SAME
  * checkoutSessionId and that re-drive carries the settling outcome
  * (one order row per session — the re-drive claims the same row).
+ *
+ * 5.5.0: OPEN union — the platform may introduce statuses (e.g.
+ * `pending_merchant` for self-settling merchants) ahead of your SDK version.
+ * Rule: treat any status you don't recognize as PENDING, never as failed.
+ * Also 5.5.0: `no_instrument` on a held/approved session is NON-terminal —
+ * the human's approval is NOT consumed; a re-drive with the same
+ * checkoutSessionId settles once a card is on file.
  */
 interface SettlementOutcomeInfo {
-    status: 'settled' | 'failed' | 'requires_action' | 'no_instrument' | 'requires_approval';
+    status: 'settled' | 'failed' | 'requires_action' | 'no_instrument' | 'requires_approval' | 'pending_merchant' | (string & {});
     /** First-party order id — the buyer sees the purchase in their AstraSync
      * dashboard orders view (no public receipt page). */
     orderId?: string;
@@ -582,6 +650,15 @@ interface VerificationRequest {
             currency: string;
         };
     }>;
+    /**
+     * 5.6.0 (astra-pay): buyer's receipt/delivery email, forwarded on the
+     * confirm leg only. TRANSIT-ONLY fulfilment PII — the platform echoes it
+     * back (canonicalized) in `VerificationResult.fulfilment` for first-party
+     * merchants and never persists it. When omitted, the platform defaults
+     * `fulfilment.email` to the buyer's account email, so supplying this is
+     * only needed for an alternate contact (gift delivery etc.).
+     */
+    buyerEmail?: string;
     /** Whether this is a sub-agent request */
     isSubAgentRequest?: boolean;
     /** Parent agent ID for sub-agent requests */

package/dist/{types-DMChboN_.d.ts → types-CwY5IY-0.d.ts}

@@ -425,11 +425,72 @@ interface VerificationResult {
      * instrument on file (steer the user to add one via onboarding).
      */
     settlementOutcome?: SettlementOutcomeInfo;
+    /**
+     * 5.5.0 (astra-pay): interim merchant self-settlement token. Present ONLY
+     * for firstParty merchants opted into settlement_mode='self_settle' on the
+     * confirm leg — YOUR server charges with this material on the shared Stripe
+     * account and reports the outcome via `client.reportSettlement()`.
+     * MERCHANT-ONLY lane: never expose it to the agent plane, never log it,
+     * never echo it back over the bridge handoff (the bridge strips it
+     * defensively). Charge with idempotency key `voucher:<jti>` and
+     * `metadata.jti` — that lets the platform webhook auto-reconcile even if
+     * your report never arrives.
+     */
+    settlementToken?: MerchantSettlementToken;
+    /**
+     * 5.6.0 (astra-pay): fulfilment contact for first-party confirm legs.
+     * The platform always resolves an email for the merchant — the agent's
+     * `buyerEmail` when one was supplied, else the buyer's account email
+     * (`emailSource` says which). Present on every first-party confirm leg that
+     * progressed (settled, pending_merchant, held, requires_action) so it can be
+     * stored with a pending order; only FULFIL against it once the order is
+     * settled / pending_merchant. MERCHANT-ONLY lane like `settlementToken` —
+     * the bridge strips it from the agent plane. An explicit `buyerEmail` on the
+     * confirm handoff body wins over `fulfilment.email` (the platform default).
+     */
+    fulfilment?: FulfilmentInfo;
     /** Timestamp of verification */
     verifiedAt: Date;
     /** TTL for this result (seconds) */
     cacheTtl?: number;
 }
+/**
+ * 5.5.0 (astra-pay): agent-blind settlement token for self-settling
+ * first-party merchants. Self-describing via `type`, so a Stripe Shared
+ * Payment Token can replace the raw customer/payment-method pair without a
+ * contract change.
+ */
+interface MerchantSettlementToken {
+    type: 'stripe_delegated_charge';
+    stripeCustomerId: string;
+    stripePaymentMethodId: string;
+    /** Integer minor units — money is never a float on the wire. */
+    amountMinor: number;
+    /** Upper-case ISO-4217. */
+    currency: string;
+    /** Verification session id — the report-back key. */
+    sessionId: string | null;
+    /** The pending kya_shop_order row your report resolves. */
+    orderId: string;
+    /** Settlement spine: charge with Stripe idempotency key `voucher:<jti>`
+     * and set `metadata.jti` on the PaymentIntent. */
+    jti: string;
+    statementSuffix: string | null;
+    /** Advisory charge-by bound (ISO); stuck orders are ops-swept after it. */
+    expiresAt: string;
+}
+/**
+ * 5.6.0 (astra-pay): fulfilment contact block. `emailSource` is an OPEN union
+ * (same rule as settlement statuses): treat unknown sources like
+ * 'agent_provided' — the email is still the one to use.
+ */
+interface FulfilmentInfo {
+    /** Canonicalized (trimmed, lower-cased) receipt/delivery email. */
+    email: string;
+    /** 'agent_provided' = the agent passed buyerEmail on this confirm;
+     * 'account' = platform default — the buyer's account email. */
+    emailSource: 'agent_provided' | 'account' | (string & {});
+}
 /**
  * 5.3.0 (astra-pay): sanitized outcome of first-party charge-at-redeem
  * settlement. Carries NO voucher/instrument material — the settlement channel
@@ -440,9 +501,16 @@ interface VerificationResult {
  * approves, the platform re-drives the confirm with the SAME
  * checkoutSessionId and that re-drive carries the settling outcome
  * (one order row per session — the re-drive claims the same row).
+ *
+ * 5.5.0: OPEN union — the platform may introduce statuses (e.g.
+ * `pending_merchant` for self-settling merchants) ahead of your SDK version.
+ * Rule: treat any status you don't recognize as PENDING, never as failed.
+ * Also 5.5.0: `no_instrument` on a held/approved session is NON-terminal —
+ * the human's approval is NOT consumed; a re-drive with the same
+ * checkoutSessionId settles once a card is on file.
  */
 interface SettlementOutcomeInfo {
-    status: 'settled' | 'failed' | 'requires_action' | 'no_instrument' | 'requires_approval';
+    status: 'settled' | 'failed' | 'requires_action' | 'no_instrument' | 'requires_approval' | 'pending_merchant' | (string & {});
     /** First-party order id — the buyer sees the purchase in their AstraSync
      * dashboard orders view (no public receipt page). */
     orderId?: string;
@@ -532,6 +600,15 @@ interface VerificationRequest {
             currency: string;
         };
     }>;
+    /**
+     * 5.6.0 (astra-pay): buyer's receipt/delivery email, forwarded on the
+     * confirm leg only. TRANSIT-ONLY fulfilment PII — the platform echoes it
+     * back (canonicalized) in `VerificationResult.fulfilment` for first-party
+     * merchants and never persists it. When omitted, the platform defaults
+     * `fulfilment.email` to the buyer's account email, so supplying this is
+     * only needed for an alternate contact (gift delivery etc.).
+     */
+    buyerEmail?: string;
     /** Whether this is a sub-agent request */
     isSubAgentRequest?: boolean;
     /** Parent agent ID for sub-agent requests */

package/dist/ui/index.d.mts

@@ -1,4 +1,4 @@
-import { V as VerificationInterstitialProps, d as VerificationResult, A as AgentCredentials, b as GuidanceInfo, T as TrustLevel } from '../types-BU04qAAR.mjs';
+import { V as VerificationInterstitialProps, d as VerificationResult, A as AgentCredentials, b as GuidanceInfo, T as TrustLevel } from '../types-BK_pRNSs.mjs';
 
 /**
  * AstraSync Verification Interstitial Component

package/dist/ui/index.d.ts

@@ -1,4 +1,4 @@
-import { V as VerificationInterstitialProps, d as VerificationResult, A as AgentCredentials, b as GuidanceInfo, T as TrustLevel } from '../types-BU04qAAR.js';
+import { V as VerificationInterstitialProps, d as VerificationResult, A as AgentCredentials, b as GuidanceInfo, T as TrustLevel } from '../types-BK_pRNSs.js';
 
 /**
  * AstraSync Verification Interstitial Component

package/dist/verify.d.mts

@@ -1,4 +1,4 @@
-import { A as AgentCredentials, G as GatewayConfig, a as AttemptReport, V as VerificationRequest, c as VerificationResult } from './types-Bd2O3eX1.mjs';
+import { A as AgentCredentials, G as GatewayConfig, a as AttemptReport, V as VerificationRequest, c as VerificationResult } from './types-BCmHFdkJ.mjs';
 import { ObservedMetadata } from './metadata-capture.mjs';
 
 /**

package/dist/verify.d.ts

@@ -1,4 +1,4 @@
-import { A as AgentCredentials, G as GatewayConfig, a as AttemptReport, V as VerificationRequest, c as VerificationResult } from './types-DMChboN_.js';
+import { A as AgentCredentials, G as GatewayConfig, a as AttemptReport, V as VerificationRequest, c as VerificationResult } from './types-CwY5IY-0.js';
 import { ObservedMetadata } from './metadata-capture.js';
 
 /**

package/dist/verify.js

@@ -36,7 +36,7 @@ __export(verify_exports, {
 module.exports = __toCommonJS(verify_exports);
 
 // src/version.ts
-var SDK_VERSION = "5.4.1";
+var SDK_VERSION = "5.6.0";
 
 // src/http.ts
 var SDK_USER_AGENT = `astrasync-sdk/${SDK_VERSION}`;
@@ -358,6 +358,7 @@ async function callVerifyAccessAPI(config, request) {
   if (requestData.commercePhase) body.commercePhase = requestData.commercePhase;
   if (requestData.checkoutSessionId) body.checkoutSessionId = requestData.checkoutSessionId;
   if (requestData.checkoutItems) body.checkoutItems = requestData.checkoutItems;
+  if (requestData.buyerEmail) body.buyerEmail = requestData.buyerEmail;
   if (requestData.commerceArtifacts) body.commerceArtifacts = requestData.commerceArtifacts;
   if (requestData.attemptId) body.attemptId = requestData.attemptId;
   if (requestData.considerationSet) body.considerationSet = requestData.considerationSet;
@@ -530,7 +531,12 @@ async function verify(config, request, options) {
       recommendationReasons: apiResponse.recommendationReasons,
       stepUpApproval: apiResponse.stepUpApproval,
       settlement: apiResponse.settlement,
-      settlementOutcome: apiResponse.settlementOutcome
+      settlementOutcome: apiResponse.settlementOutcome,
+      // 5.5.0 self-settlement: merchant-only material — passes through to the
+      // MERCHANT caller only (bridge callers strip it before the agent plane).
+      settlementToken: apiResponse.settlementToken,
+      // 5.6.0: fulfilment contact — merchant-only lane, same strip rule.
+      fulfilment: apiResponse.fulfilment
     };
     return result2;
   }
@@ -588,7 +594,10 @@ async function verify(config, request, options) {
     warningHeader: apiResponse.warningHeader,
     stepUpApproval: apiResponse.stepUpApproval,
     settlement: apiResponse.settlement,
-    settlementOutcome: apiResponse.settlementOutcome
+    settlementOutcome: apiResponse.settlementOutcome,
+    settlementToken: apiResponse.settlementToken,
+    // 5.6.0: fulfilment contact — merchant-only lane, same strip rule.
+    fulfilment: apiResponse.fulfilment
   };
   if (result.recommendation === "deny") {
     result.policyAllowed = false;