@agent-score/commerce 2.2.0 → 2.4.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (68) hide show
  1. package/README.md +7 -7
  2. package/dist/challenge/index.d.mts +4 -4
  3. package/dist/challenge/index.d.ts +4 -4
  4. package/dist/challenge/index.js.map +1 -1
  5. package/dist/challenge/index.mjs.map +1 -1
  6. package/dist/{checkout-CfgxgPZL.d.ts → checkout-B-MIzYzW.d.ts} +8 -11
  7. package/dist/{checkout-CKQE2QpJ.d.mts → checkout-Bn7ZKIBD.d.mts} +8 -11
  8. package/dist/core.d.mts +4 -6
  9. package/dist/core.d.ts +4 -6
  10. package/dist/core.js +1 -1
  11. package/dist/core.js.map +1 -1
  12. package/dist/core.mjs +1 -1
  13. package/dist/core.mjs.map +1 -1
  14. package/dist/discovery/index.d.mts +10 -9
  15. package/dist/discovery/index.d.ts +10 -9
  16. package/dist/discovery/index.js +44 -6
  17. package/dist/discovery/index.js.map +1 -1
  18. package/dist/discovery/index.mjs +44 -6
  19. package/dist/discovery/index.mjs.map +1 -1
  20. package/dist/identity/express.js +13 -13
  21. package/dist/identity/express.js.map +1 -1
  22. package/dist/identity/express.mjs +13 -13
  23. package/dist/identity/express.mjs.map +1 -1
  24. package/dist/identity/fastify.js +13 -13
  25. package/dist/identity/fastify.js.map +1 -1
  26. package/dist/identity/fastify.mjs +13 -13
  27. package/dist/identity/fastify.mjs.map +1 -1
  28. package/dist/identity/hono.js +13 -13
  29. package/dist/identity/hono.js.map +1 -1
  30. package/dist/identity/hono.mjs +13 -13
  31. package/dist/identity/hono.mjs.map +1 -1
  32. package/dist/identity/nextjs.js +13 -13
  33. package/dist/identity/nextjs.js.map +1 -1
  34. package/dist/identity/nextjs.mjs +13 -13
  35. package/dist/identity/nextjs.mjs.map +1 -1
  36. package/dist/identity/policy.js.map +1 -1
  37. package/dist/identity/policy.mjs.map +1 -1
  38. package/dist/identity/web.js +13 -13
  39. package/dist/identity/web.js.map +1 -1
  40. package/dist/identity/web.mjs +13 -13
  41. package/dist/identity/web.mjs.map +1 -1
  42. package/dist/index.d.mts +12 -13
  43. package/dist/index.d.ts +12 -13
  44. package/dist/index.js +88 -65
  45. package/dist/index.js.map +1 -1
  46. package/dist/index.mjs +86 -65
  47. package/dist/index.mjs.map +1 -1
  48. package/dist/{default_rails-C5gKZJMI.d.ts → network_kind-BIJM2peR.d.ts} +22 -8
  49. package/dist/{default_rails-XFCuRddA.d.mts → network_kind-C0EMkdzz.d.mts} +22 -8
  50. package/dist/payment/index.d.mts +16 -26
  51. package/dist/payment/index.d.ts +16 -26
  52. package/dist/payment/index.js +64 -57
  53. package/dist/payment/index.js.map +1 -1
  54. package/dist/payment/index.mjs +64 -57
  55. package/dist/payment/index.mjs.map +1 -1
  56. package/dist/{pricing-uFGRNoGl.d.ts → pricing-CytRwhC2.d.ts} +1 -1
  57. package/dist/{pricing-dSI3ePmE.d.mts → pricing-KHDqMLd7.d.mts} +1 -1
  58. package/dist/{rail_spec-D6qzh3J0.d.mts → rail_spec-BFZmW9RN.d.mts} +28 -4
  59. package/dist/{rail_spec-D6qzh3J0.d.ts → rail_spec-BFZmW9RN.d.ts} +28 -4
  60. package/dist/stripe-multichain/index.d.mts +61 -18
  61. package/dist/stripe-multichain/index.d.ts +61 -18
  62. package/dist/stripe-multichain/index.js +82 -42
  63. package/dist/stripe-multichain/index.js.map +1 -1
  64. package/dist/stripe-multichain/index.mjs +81 -42
  65. package/dist/stripe-multichain/index.mjs.map +1 -1
  66. package/dist/{wwwauthenticate-D_FMnPgU.d.mts → wwwauthenticate-CVaGUMjU.d.mts} +8 -6
  67. package/dist/{wwwauthenticate-D_FMnPgU.d.ts → wwwauthenticate-CVaGUMjU.d.ts} +8 -6
  68. package/package.json +12 -11
@@ -1,4 +1,4 @@
1
- import { T as TempoRailSpec, X as X402BaseRailSpec, S as SolanaMppRailSpec, b as StripeRailSpec } from './rail_spec-D6qzh3J0.js';
1
+ import { T as TempoRailSpec, X as X402BaseRailSpec, S as SolanaMppRailSpec, b as StripeRailSpec } from './rail_spec-BFZmW9RN.js';
2
2
 
3
3
  interface HowToPayRailEntry {
4
4
  setup?: string[];
@@ -1,4 +1,4 @@
1
- import { T as TempoRailSpec, X as X402BaseRailSpec, S as SolanaMppRailSpec, b as StripeRailSpec } from './rail_spec-D6qzh3J0.mjs';
1
+ import { T as TempoRailSpec, X as X402BaseRailSpec, S as SolanaMppRailSpec, b as StripeRailSpec } from './rail_spec-BFZmW9RN.mjs';
2
2
 
3
3
  interface HowToPayRailEntry {
4
4
  setup?: string[];
@@ -58,6 +58,31 @@ interface SolanaMppRailSpec {
58
58
  rpcUrl?: string;
59
59
  signer?: unknown;
60
60
  tokenProgram?: string;
61
+ /** Whether the recipient's ATA may be auto-created on first payment. **Default `true`.**
62
+ *
63
+ * When `true` (default), the SDK passes
64
+ * `splits: [{ recipient, amount: '0', ataCreationRequired: true }]` to
65
+ * `solana.charge`, which puts the recipient in the MPP spec §13.6
66
+ * `allowedAtaOwners` allow-list. Required on `@solana/mpp >= 0.6.0` with a
67
+ * sponsored (fee-payer) setup — without it, every settle that emits a
68
+ * `CreateIdempotent` ATA instruction is rejected. On `@solana/mpp 0.5.x`
69
+ * the field is unknown and silently ignored, so the default is safe across
70
+ * versions.
71
+ *
72
+ * Opt out (`false`) only when every recipient's ATA is guaranteed to exist
73
+ * out-of-band — typically when the merchant pre-creates the ATA from an
74
+ * external wallet (one-time USDC transfer of any amount) and refuses to
75
+ * let the fee-payer fund creation. Rare; mainly useful for low-margin
76
+ * endpoints that use a stable merchant-owned recipient via
77
+ * `staticRecipients` and want to guarantee zero rent per call.
78
+ *
79
+ * Economic note: with rotating recipients (Stripe-multichain per-PI deposit
80
+ * addresses), the sponsor pays ~0.002 SOL (~$0.50) of rent per call into
81
+ * accounts the merchant can't close. Acceptable when settle amounts
82
+ * dominate ($50+ transactions); not viable for sub-dollar merchants —
83
+ * those should pair `ataCreationRequired: false` with a static recipient
84
+ * whose ATA has been pre-created (one-time external USDC transfer). */
85
+ ataCreationRequired?: boolean;
61
86
  }
62
87
  /**
63
88
  * Canonical config for the Stripe SPT rail.
@@ -91,10 +116,9 @@ interface TempoSessionRailSpec {
91
116
  chains?: unknown;
92
117
  }
93
118
  /**
94
- * Default field values for each `*RailSpec`. Mirrors python-commerce's
95
- * `*RailSpec` dataclass defaults callers can spread these into their spec
96
- * literal when they want defaults without typing them out. Sourced from the
97
- * USDC registry so they stay in sync with on-chain reality.
119
+ * Default field values for each `*RailSpec` callers can spread these into
120
+ * their spec literal when they want defaults without typing them out. Sourced
121
+ * from the USDC registry so they stay in sync with on-chain reality.
98
122
  */
99
123
  declare const RAIL_SPEC_DEFAULTS: {
100
124
  readonly tempo: {
@@ -58,6 +58,31 @@ interface SolanaMppRailSpec {
58
58
  rpcUrl?: string;
59
59
  signer?: unknown;
60
60
  tokenProgram?: string;
61
+ /** Whether the recipient's ATA may be auto-created on first payment. **Default `true`.**
62
+ *
63
+ * When `true` (default), the SDK passes
64
+ * `splits: [{ recipient, amount: '0', ataCreationRequired: true }]` to
65
+ * `solana.charge`, which puts the recipient in the MPP spec §13.6
66
+ * `allowedAtaOwners` allow-list. Required on `@solana/mpp >= 0.6.0` with a
67
+ * sponsored (fee-payer) setup — without it, every settle that emits a
68
+ * `CreateIdempotent` ATA instruction is rejected. On `@solana/mpp 0.5.x`
69
+ * the field is unknown and silently ignored, so the default is safe across
70
+ * versions.
71
+ *
72
+ * Opt out (`false`) only when every recipient's ATA is guaranteed to exist
73
+ * out-of-band — typically when the merchant pre-creates the ATA from an
74
+ * external wallet (one-time USDC transfer of any amount) and refuses to
75
+ * let the fee-payer fund creation. Rare; mainly useful for low-margin
76
+ * endpoints that use a stable merchant-owned recipient via
77
+ * `staticRecipients` and want to guarantee zero rent per call.
78
+ *
79
+ * Economic note: with rotating recipients (Stripe-multichain per-PI deposit
80
+ * addresses), the sponsor pays ~0.002 SOL (~$0.50) of rent per call into
81
+ * accounts the merchant can't close. Acceptable when settle amounts
82
+ * dominate ($50+ transactions); not viable for sub-dollar merchants —
83
+ * those should pair `ataCreationRequired: false` with a static recipient
84
+ * whose ATA has been pre-created (one-time external USDC transfer). */
85
+ ataCreationRequired?: boolean;
61
86
  }
62
87
  /**
63
88
  * Canonical config for the Stripe SPT rail.
@@ -91,10 +116,9 @@ interface TempoSessionRailSpec {
91
116
  chains?: unknown;
92
117
  }
93
118
  /**
94
- * Default field values for each `*RailSpec`. Mirrors python-commerce's
95
- * `*RailSpec` dataclass defaults callers can spread these into their spec
96
- * literal when they want defaults without typing them out. Sourced from the
97
- * USDC registry so they stay in sync with on-chain reality.
119
+ * Default field values for each `*RailSpec` callers can spread these into
120
+ * their spec literal when they want defaults without typing them out. Sourced
121
+ * from the USDC registry so they stay in sync with on-chain reality.
98
122
  */
99
123
  declare const RAIL_SPEC_DEFAULTS: {
100
124
  readonly tempo: {
@@ -112,15 +112,20 @@ declare function createPiCache({ redisUrl, ttlSeconds, keyPrefix, }?: {
112
112
  * the 402 advertises a stable per-order deposit address.
113
113
  * - **Settle leg** (MPP credential attached): reuse the buyer's
114
114
  * signed-against payTo from the credential (after verifying it's in the
115
- * local cache) otherwise the verify leg would compare against a
116
- * freshly-rotated address and reject the credential.
115
+ * local cache OR matches a configured `staticRecipients` entry)
116
+ * otherwise the verify leg would compare against a freshly-rotated
117
+ * address and reject the credential.
117
118
  *
118
119
  * Stripe SPT and card methods don't carry an on-chain recipient, so the
119
120
  * settle leg still mints a fresh PaymentIntent for them.
120
121
  *
121
- * Mirrors the hand-rolled `createPayToAddress` block consumers wrote in
122
- * `lib/payment.ts`. Lifts the structural branching; merchants keep
123
- * env-driven config (network list, default network, metadata) at the call site.
122
+ * Two public entrypoints share the same options and internal helpers:
123
+ * - `createPayToAddressFromStripePI` returns a single string (the
124
+ * `preferredNetwork`'s address). Convenient when the merchant only needs
125
+ * one rail's payTo back.
126
+ * - `mintMultichainRecipients` returns the full per-rail map plus the PI
127
+ * id. Preferred for multi-rail merchants — avoids the second pi-cache
128
+ * lookup to stitch sibling addresses back together.
124
129
  */
125
130
 
126
131
  interface CreatePayToAddressFromStripePIOptions {
@@ -132,8 +137,26 @@ interface CreatePayToAddressFromStripePIOptions {
132
137
  stripe: StripeClientLike;
133
138
  /** Cache backing the merchant's minted addresses + PI lookups. */
134
139
  piCache: PiCache;
135
- /** Networks to advertise to Stripe `deposit_options`. Default ['tempo', 'base', 'solana']. */
140
+ /** Networks to advertise to Stripe `deposit_options`. Default ['tempo', 'base', 'solana'].
141
+ * Networks present as a key in `staticRecipients` are removed from this list
142
+ * automatically — Stripe is not asked to mint a per-PI address for them. */
136
143
  networks?: string[];
144
+ /** Merchant-owned static deposit addresses, keyed by network. Use this to bypass
145
+ * Stripe per-PI rotation on chains where a rotating recipient is expensive
146
+ * (Solana: each new recipient address costs ~0.002 SOL of ATA rent locked on
147
+ * an account the merchant can't close — see MPP spec §13.6 "ATA Rent Drain").
148
+ *
149
+ * The SDK handles everything: (a) excludes these networks from the Stripe mint,
150
+ * (b) registers them with `piCache.cacheAddress` on every call (so settle-leg
151
+ * `hasAddress` checks pass during the TTL window), (c) merges them into the
152
+ * per-PI network map (so `getNetworkDepositAddress(piId, network)` returns the
153
+ * static address transparently), and (d) accepts the credential's signed-against
154
+ * recipient on the settle leg when it matches a configured static address
155
+ * (bypassing the `hasAddress` TTL window since merchant-owned addresses are
156
+ * always valid).
157
+ *
158
+ * Example: `{ solana: 'FR96wd96urHJdMnYayFrPYmDeAjKvwi3rQ2wkgXXTSP8' }` */
159
+ staticRecipients?: Record<string, string>;
137
160
  /** Optional Stripe metadata. */
138
161
  metadata?: Record<string, string>;
139
162
  /** Pending-order id; used as the Stripe idempotency key seed so retries
@@ -143,14 +166,39 @@ interface CreatePayToAddressFromStripePIOptions {
143
166
  * picks `tempo`, falls back to `base`. */
144
167
  preferredNetwork?: string;
145
168
  }
146
- /** Returns the on-chain `pay_to` address the agent should be told to pay
147
- * (in the 402 challenge or the bound MPP credential).
169
+ /** Structured result for `mintMultichainRecipients` exposes the full per-network
170
+ * deposit map plus the PI id, so merchants can stop guessing "is the returned
171
+ * string the tempo address or the solana static". */
172
+ interface MintMultichainRecipientsResult {
173
+ /** Per-network deposit address map (e.g. `{ tempo: '0x...', base: '0x...', solana: 'FR96...' }`).
174
+ * Merges Stripe-minted addresses with any `staticRecipients` overrides. */
175
+ recipients: Record<string, string>;
176
+ /** Stripe PaymentIntent id (when a PI was minted on this call) or undefined
177
+ * if all networks were covered by staticRecipients. */
178
+ paymentIntentId?: string;
179
+ /** True when the settle leg short-circuited to the credential-bound recipient
180
+ * instead of minting a new PI. The merchant's downstream sibling-address
181
+ * lookups (e.g. for the 402 retry body) should fall back to the PI cache. */
182
+ reusedFromCredential: boolean;
183
+ }
184
+ /** Returns the on-chain `pay_to` address the agent should be told to pay.
148
185
  *
149
186
  * On the settle leg, when the inbound `Authorization: Payment` credential
150
187
  * binds a `tempo` or `solana` recipient, the helper returns THAT address
151
- * (after verifying it's still in `piCache`). Otherwise it mints a fresh
152
- * `createMultichainPaymentIntent` and caches the addresses + PI mapping. */
188
+ * (after verifying it's still in `piCache` OR matches a configured
189
+ * `staticRecipients` entry). Otherwise it mints a fresh
190
+ * `createMultichainPaymentIntent` and caches the addresses + PI mapping.
191
+ *
192
+ * When `staticRecipients` is configured, prefer `mintMultichainRecipients`
193
+ * instead — its structured return avoids the "is this string the tempo or
194
+ * the solana static" ambiguity on the settle leg. */
153
195
  declare function createPayToAddressFromStripePI(opts: CreatePayToAddressFromStripePIOptions): Promise<string>;
196
+ /** Structured variant of `createPayToAddressFromStripePI`: returns the full
197
+ * per-rail map plus the PI id. Preferred when the merchant's `mintRecipients`
198
+ * hook needs all rail addresses (typical multi-rail merchant) — saves the
199
+ * pi-cache lookups + sidesteps the "returned-string-is-ambiguous" trap on
200
+ * the settle leg when `staticRecipients` is configured. */
201
+ declare function mintMultichainRecipients(opts: CreatePayToAddressFromStripePIOptions): Promise<MintMultichainRecipientsResult>;
154
202
 
155
203
  /**
156
204
  * Stripe's documented magic test_helpers transaction hash that resolves the
@@ -258,13 +306,8 @@ declare function createMppxStripe({ profileId, secretKey, paymentMethodTypes, }:
258
306
  }): Promise<unknown>;
259
307
 
260
308
  /** Settle-outcome → simulator dispatch. Replaces the 3-branch rail/railKey
261
- * switch + thin `simulateDepositIfTestnet(addr, network)` wrapper that
262
- * consumer codebases (sayer, martin, sandbox) hand-rolled in their own
263
- * `lib/payment.ts` files.
264
- *
265
- * Folding the dispatch into the SDK removes the consumer-wrap anti-pattern
266
- * (`feedback_no_consumer_sdk_rewrapping`): merchants call this directly from
267
- * `onSettled`, no per-merchant payment.ts wrapper needed.
309
+ * switch + thin testnet-deposit wrapper a merchant would otherwise hand-roll
310
+ * in their own payment helpers. Call it directly from `onSettled`.
268
311
  */
269
312
  type SimulateNetwork = 'tempo' | 'base' | 'solana';
270
313
  /** Map a settle outcome (from `Checkout.onSettled` or
@@ -310,4 +353,4 @@ interface SimulateDepositForOutcomeOptions {
310
353
  * `simulateDepositIfTestnet` wrapper pattern. */
311
354
  declare function simulateDepositForOutcome(opts: SimulateDepositForOutcomeOptions): Promise<void>;
312
355
 
313
- export { type CreatePayToAddressFromStripePIOptions, type MultichainPaymentIntentResult, type PiCache, STRIPE_TEST_TX_HASH_FAILED, STRIPE_TEST_TX_HASH_SUCCESS, type SimulateDepositForOutcomeOptions, type SimulateNetwork, type StripeClientLike, type StripePaymentIntent, createMppxStripe, createMultichainPaymentIntent, createPayToAddressFromStripePI, createPiCache, networkForOutcome, simulateCryptoDeposit, simulateDepositForOutcome, simulateDepositIfTestMode };
356
+ export { type CreatePayToAddressFromStripePIOptions, type MintMultichainRecipientsResult, type MultichainPaymentIntentResult, type PiCache, STRIPE_TEST_TX_HASH_FAILED, STRIPE_TEST_TX_HASH_SUCCESS, type SimulateDepositForOutcomeOptions, type SimulateNetwork, type StripeClientLike, type StripePaymentIntent, createMppxStripe, createMultichainPaymentIntent, createPayToAddressFromStripePI, createPiCache, mintMultichainRecipients, networkForOutcome, simulateCryptoDeposit, simulateDepositForOutcome, simulateDepositIfTestMode };
@@ -112,15 +112,20 @@ declare function createPiCache({ redisUrl, ttlSeconds, keyPrefix, }?: {
112
112
  * the 402 advertises a stable per-order deposit address.
113
113
  * - **Settle leg** (MPP credential attached): reuse the buyer's
114
114
  * signed-against payTo from the credential (after verifying it's in the
115
- * local cache) otherwise the verify leg would compare against a
116
- * freshly-rotated address and reject the credential.
115
+ * local cache OR matches a configured `staticRecipients` entry)
116
+ * otherwise the verify leg would compare against a freshly-rotated
117
+ * address and reject the credential.
117
118
  *
118
119
  * Stripe SPT and card methods don't carry an on-chain recipient, so the
119
120
  * settle leg still mints a fresh PaymentIntent for them.
120
121
  *
121
- * Mirrors the hand-rolled `createPayToAddress` block consumers wrote in
122
- * `lib/payment.ts`. Lifts the structural branching; merchants keep
123
- * env-driven config (network list, default network, metadata) at the call site.
122
+ * Two public entrypoints share the same options and internal helpers:
123
+ * - `createPayToAddressFromStripePI` returns a single string (the
124
+ * `preferredNetwork`'s address). Convenient when the merchant only needs
125
+ * one rail's payTo back.
126
+ * - `mintMultichainRecipients` returns the full per-rail map plus the PI
127
+ * id. Preferred for multi-rail merchants — avoids the second pi-cache
128
+ * lookup to stitch sibling addresses back together.
124
129
  */
125
130
 
126
131
  interface CreatePayToAddressFromStripePIOptions {
@@ -132,8 +137,26 @@ interface CreatePayToAddressFromStripePIOptions {
132
137
  stripe: StripeClientLike;
133
138
  /** Cache backing the merchant's minted addresses + PI lookups. */
134
139
  piCache: PiCache;
135
- /** Networks to advertise to Stripe `deposit_options`. Default ['tempo', 'base', 'solana']. */
140
+ /** Networks to advertise to Stripe `deposit_options`. Default ['tempo', 'base', 'solana'].
141
+ * Networks present as a key in `staticRecipients` are removed from this list
142
+ * automatically — Stripe is not asked to mint a per-PI address for them. */
136
143
  networks?: string[];
144
+ /** Merchant-owned static deposit addresses, keyed by network. Use this to bypass
145
+ * Stripe per-PI rotation on chains where a rotating recipient is expensive
146
+ * (Solana: each new recipient address costs ~0.002 SOL of ATA rent locked on
147
+ * an account the merchant can't close — see MPP spec §13.6 "ATA Rent Drain").
148
+ *
149
+ * The SDK handles everything: (a) excludes these networks from the Stripe mint,
150
+ * (b) registers them with `piCache.cacheAddress` on every call (so settle-leg
151
+ * `hasAddress` checks pass during the TTL window), (c) merges them into the
152
+ * per-PI network map (so `getNetworkDepositAddress(piId, network)` returns the
153
+ * static address transparently), and (d) accepts the credential's signed-against
154
+ * recipient on the settle leg when it matches a configured static address
155
+ * (bypassing the `hasAddress` TTL window since merchant-owned addresses are
156
+ * always valid).
157
+ *
158
+ * Example: `{ solana: 'FR96wd96urHJdMnYayFrPYmDeAjKvwi3rQ2wkgXXTSP8' }` */
159
+ staticRecipients?: Record<string, string>;
137
160
  /** Optional Stripe metadata. */
138
161
  metadata?: Record<string, string>;
139
162
  /** Pending-order id; used as the Stripe idempotency key seed so retries
@@ -143,14 +166,39 @@ interface CreatePayToAddressFromStripePIOptions {
143
166
  * picks `tempo`, falls back to `base`. */
144
167
  preferredNetwork?: string;
145
168
  }
146
- /** Returns the on-chain `pay_to` address the agent should be told to pay
147
- * (in the 402 challenge or the bound MPP credential).
169
+ /** Structured result for `mintMultichainRecipients` exposes the full per-network
170
+ * deposit map plus the PI id, so merchants can stop guessing "is the returned
171
+ * string the tempo address or the solana static". */
172
+ interface MintMultichainRecipientsResult {
173
+ /** Per-network deposit address map (e.g. `{ tempo: '0x...', base: '0x...', solana: 'FR96...' }`).
174
+ * Merges Stripe-minted addresses with any `staticRecipients` overrides. */
175
+ recipients: Record<string, string>;
176
+ /** Stripe PaymentIntent id (when a PI was minted on this call) or undefined
177
+ * if all networks were covered by staticRecipients. */
178
+ paymentIntentId?: string;
179
+ /** True when the settle leg short-circuited to the credential-bound recipient
180
+ * instead of minting a new PI. The merchant's downstream sibling-address
181
+ * lookups (e.g. for the 402 retry body) should fall back to the PI cache. */
182
+ reusedFromCredential: boolean;
183
+ }
184
+ /** Returns the on-chain `pay_to` address the agent should be told to pay.
148
185
  *
149
186
  * On the settle leg, when the inbound `Authorization: Payment` credential
150
187
  * binds a `tempo` or `solana` recipient, the helper returns THAT address
151
- * (after verifying it's still in `piCache`). Otherwise it mints a fresh
152
- * `createMultichainPaymentIntent` and caches the addresses + PI mapping. */
188
+ * (after verifying it's still in `piCache` OR matches a configured
189
+ * `staticRecipients` entry). Otherwise it mints a fresh
190
+ * `createMultichainPaymentIntent` and caches the addresses + PI mapping.
191
+ *
192
+ * When `staticRecipients` is configured, prefer `mintMultichainRecipients`
193
+ * instead — its structured return avoids the "is this string the tempo or
194
+ * the solana static" ambiguity on the settle leg. */
153
195
  declare function createPayToAddressFromStripePI(opts: CreatePayToAddressFromStripePIOptions): Promise<string>;
196
+ /** Structured variant of `createPayToAddressFromStripePI`: returns the full
197
+ * per-rail map plus the PI id. Preferred when the merchant's `mintRecipients`
198
+ * hook needs all rail addresses (typical multi-rail merchant) — saves the
199
+ * pi-cache lookups + sidesteps the "returned-string-is-ambiguous" trap on
200
+ * the settle leg when `staticRecipients` is configured. */
201
+ declare function mintMultichainRecipients(opts: CreatePayToAddressFromStripePIOptions): Promise<MintMultichainRecipientsResult>;
154
202
 
155
203
  /**
156
204
  * Stripe's documented magic test_helpers transaction hash that resolves the
@@ -258,13 +306,8 @@ declare function createMppxStripe({ profileId, secretKey, paymentMethodTypes, }:
258
306
  }): Promise<unknown>;
259
307
 
260
308
  /** Settle-outcome → simulator dispatch. Replaces the 3-branch rail/railKey
261
- * switch + thin `simulateDepositIfTestnet(addr, network)` wrapper that
262
- * consumer codebases (sayer, martin, sandbox) hand-rolled in their own
263
- * `lib/payment.ts` files.
264
- *
265
- * Folding the dispatch into the SDK removes the consumer-wrap anti-pattern
266
- * (`feedback_no_consumer_sdk_rewrapping`): merchants call this directly from
267
- * `onSettled`, no per-merchant payment.ts wrapper needed.
309
+ * switch + thin testnet-deposit wrapper a merchant would otherwise hand-roll
310
+ * in their own payment helpers. Call it directly from `onSettled`.
268
311
  */
269
312
  type SimulateNetwork = 'tempo' | 'base' | 'solana';
270
313
  /** Map a settle outcome (from `Checkout.onSettled` or
@@ -310,4 +353,4 @@ interface SimulateDepositForOutcomeOptions {
310
353
  * `simulateDepositIfTestnet` wrapper pattern. */
311
354
  declare function simulateDepositForOutcome(opts: SimulateDepositForOutcomeOptions): Promise<void>;
312
355
 
313
- export { type CreatePayToAddressFromStripePIOptions, type MultichainPaymentIntentResult, type PiCache, STRIPE_TEST_TX_HASH_FAILED, STRIPE_TEST_TX_HASH_SUCCESS, type SimulateDepositForOutcomeOptions, type SimulateNetwork, type StripeClientLike, type StripePaymentIntent, createMppxStripe, createMultichainPaymentIntent, createPayToAddressFromStripePI, createPiCache, networkForOutcome, simulateCryptoDeposit, simulateDepositForOutcome, simulateDepositIfTestMode };
356
+ export { type CreatePayToAddressFromStripePIOptions, type MintMultichainRecipientsResult, type MultichainPaymentIntentResult, type PiCache, STRIPE_TEST_TX_HASH_FAILED, STRIPE_TEST_TX_HASH_SUCCESS, type SimulateDepositForOutcomeOptions, type SimulateNetwork, type StripeClientLike, type StripePaymentIntent, createMppxStripe, createMultichainPaymentIntent, createPayToAddressFromStripePI, createPiCache, mintMultichainRecipients, networkForOutcome, simulateCryptoDeposit, simulateDepositForOutcome, simulateDepositIfTestMode };
@@ -19654,6 +19654,7 @@ __export(stripe_multichain_exports, {
19654
19654
  createMultichainPaymentIntent: () => createMultichainPaymentIntent,
19655
19655
  createPayToAddressFromStripePI: () => createPayToAddressFromStripePI,
19656
19656
  createPiCache: () => createPiCache,
19657
+ mintMultichainRecipients: () => mintMultichainRecipients,
19657
19658
  networkForOutcome: () => networkForOutcome,
19658
19659
  simulateCryptoDeposit: () => simulateCryptoDeposit,
19659
19660
  simulateDepositForOutcome: () => simulateDepositForOutcome,
@@ -19720,50 +19721,76 @@ async function createMultichainPaymentIntent({
19720
19721
  }
19721
19722
 
19722
19723
  // src/stripe-multichain/pay_to_address.ts
19724
+ var DEFAULT_NETWORKS = ["tempo", "base", "solana"];
19723
19725
  async function createPayToAddressFromStripePI(opts) {
19726
+ const fromCredential = await tryResolveFromCredential(opts);
19727
+ if (fromCredential !== null) return fromCredential;
19728
+ const { preferred } = await mintAndCache(opts);
19729
+ return preferred;
19730
+ }
19731
+ async function mintMultichainRecipients(opts) {
19732
+ const fromCredential = await tryResolveFromCredential(opts);
19733
+ if (fromCredential !== null) {
19734
+ const piId = opts.piCache.getPaymentIntentId(fromCredential);
19735
+ const networkMap = piId ? readNetworkMapFromCache(opts.piCache, piId) : {};
19736
+ const merged2 = { ...networkMap, ...opts.staticRecipients ?? {} };
19737
+ return {
19738
+ recipients: merged2,
19739
+ ...piId !== void 0 && { paymentIntentId: piId },
19740
+ reusedFromCredential: true
19741
+ };
19742
+ }
19743
+ const { merged, paymentIntentId } = await mintAndCache(opts);
19744
+ return { recipients: merged, paymentIntentId, reusedFromCredential: false };
19745
+ }
19746
+ async function tryResolveFromCredential(opts) {
19724
19747
  const authHeader = opts.request.headers.get("authorization");
19725
- if (authHeader) {
19726
- const { Credential } = await Promise.resolve().then(() => (init_dist2(), dist_exports));
19727
- if (Credential.extractPaymentScheme(authHeader)) {
19728
- let credential;
19729
- try {
19730
- credential = Credential.fromRequest(opts.request);
19731
- } catch {
19732
- throw new CheckoutValidationError({
19733
- code: "invalid_credential",
19734
- message: "The Authorization: Payment header is not a valid MPP credential.",
19735
- action: "retry_without_credential",
19736
- status: 401
19737
- });
19738
- }
19739
- const method = credential.challenge.method;
19740
- if (method === "tempo" || method === "solana") {
19741
- const toAddress = credential.challenge.request.recipient;
19742
- if (typeof toAddress !== "string" || !toAddress) {
19743
- throw new CheckoutValidationError({
19744
- code: "invalid_credential",
19745
- message: "The MPP credential is missing its recipient field.",
19746
- action: "retry_without_credential",
19747
- status: 401
19748
- });
19749
- }
19750
- if (!await opts.piCache.hasAddress(toAddress)) {
19751
- throw new CheckoutValidationError({
19752
- code: "invalid_credential",
19753
- message: "The signed-against payTo recipient is not in this merchant's cache (unknown or expired). Retry without the Authorization: Payment header to receive a fresh 402 challenge.",
19754
- action: "retry_without_credential",
19755
- status: 401
19756
- });
19757
- }
19758
- return toAddress;
19759
- }
19760
- }
19748
+ if (!authHeader) return null;
19749
+ const { Credential } = await Promise.resolve().then(() => (init_dist2(), dist_exports));
19750
+ if (!Credential.extractPaymentScheme(authHeader)) return null;
19751
+ let credential;
19752
+ try {
19753
+ credential = Credential.fromRequest(opts.request);
19754
+ } catch {
19755
+ throw new CheckoutValidationError({
19756
+ code: "invalid_credential",
19757
+ message: "The Authorization: Payment header is not a valid MPP credential.",
19758
+ action: "retry_without_credential",
19759
+ status: 401
19760
+ });
19761
+ }
19762
+ const method = credential.challenge.method;
19763
+ if (method !== "tempo" && method !== "solana") return null;
19764
+ const toAddress = credential.challenge.request.recipient;
19765
+ if (typeof toAddress !== "string" || !toAddress) {
19766
+ throw new CheckoutValidationError({
19767
+ code: "invalid_credential",
19768
+ message: "The MPP credential is missing its recipient field.",
19769
+ action: "retry_without_credential",
19770
+ status: 401
19771
+ });
19772
+ }
19773
+ const staticForMethod = opts.staticRecipients?.[method];
19774
+ if (staticForMethod && staticForMethod === toAddress) return toAddress;
19775
+ if (!await opts.piCache.hasAddress(toAddress)) {
19776
+ throw new CheckoutValidationError({
19777
+ code: "invalid_credential",
19778
+ message: "The signed-against payTo recipient is not in this merchant's cache (unknown or expired). Retry without the Authorization: Payment header to receive a fresh 402 challenge.",
19779
+ action: "retry_without_credential",
19780
+ status: 401
19781
+ });
19761
19782
  }
19783
+ return toAddress;
19784
+ }
19785
+ async function mintAndCache(opts) {
19786
+ const staticRecipients = opts.staticRecipients ?? {};
19787
+ const requestedNetworks = opts.networks ?? [...DEFAULT_NETWORKS];
19788
+ const stripeNetworks = requestedNetworks.filter((n) => !(n in staticRecipients));
19762
19789
  const idempotencyKey = opts.orderId ? `pi-${opts.orderId}-${opts.amountCents}` : void 0;
19763
19790
  const { paymentIntentId, depositAddresses } = await createMultichainPaymentIntent({
19764
19791
  stripe: opts.stripe,
19765
19792
  amount: opts.amountCents,
19766
- networks: opts.networks ?? ["tempo", "base", "solana"],
19793
+ networks: stripeNetworks,
19767
19794
  ...opts.metadata ? { metadata: opts.metadata } : {},
19768
19795
  ...idempotencyKey ? { idempotencyKey } : {}
19769
19796
  });
@@ -19771,10 +19798,14 @@ async function createPayToAddressFromStripePI(opts) {
19771
19798
  await opts.piCache.cacheAddress(address2);
19772
19799
  opts.piCache.cachePaymentIntent(address2, paymentIntentId);
19773
19800
  }
19774
- opts.piCache.cacheNetworkAddresses(paymentIntentId, depositAddresses);
19775
- const preferred = opts.preferredNetwork ?? "tempo";
19776
- const payTo = depositAddresses[preferred] ?? depositAddresses.base ?? depositAddresses.tempo;
19777
- if (!payTo) {
19801
+ for (const address2 of Object.values(staticRecipients)) {
19802
+ await opts.piCache.cacheAddress(address2);
19803
+ }
19804
+ const merged = { ...depositAddresses, ...staticRecipients };
19805
+ opts.piCache.cacheNetworkAddresses(paymentIntentId, merged);
19806
+ const preferredKey = opts.preferredNetwork ?? "tempo";
19807
+ const preferred = merged[preferredKey] ?? merged.base ?? merged.tempo;
19808
+ if (!preferred) {
19778
19809
  throw new CheckoutValidationError({
19779
19810
  code: "payment_provider_unavailable",
19780
19811
  message: "Stripe returned deposit addresses but none matched the requested network (tempo / base / solana). The account may have only a subset of multichain networks enabled.",
@@ -19782,7 +19813,15 @@ async function createPayToAddressFromStripePI(opts) {
19782
19813
  status: 503
19783
19814
  });
19784
19815
  }
19785
- return payTo;
19816
+ return { preferred, merged, paymentIntentId };
19817
+ }
19818
+ function readNetworkMapFromCache(piCache, paymentIntentId) {
19819
+ const entries = [];
19820
+ for (const n of DEFAULT_NETWORKS) {
19821
+ const addr = piCache.getNetworkDepositAddress(paymentIntentId, n);
19822
+ if (addr) entries.push([n, addr]);
19823
+ }
19824
+ return Object.fromEntries(entries);
19786
19825
  }
19787
19826
 
19788
19827
  // src/stripe-multichain/simulate_deposit.ts
@@ -20007,6 +20046,7 @@ async function simulateDepositForOutcome(opts) {
20007
20046
  createMultichainPaymentIntent,
20008
20047
  createPayToAddressFromStripePI,
20009
20048
  createPiCache,
20049
+ mintMultichainRecipients,
20010
20050
  networkForOutcome,
20011
20051
  simulateCryptoDeposit,
20012
20052
  simulateDepositForOutcome,