@devlab.group/agent-commerce 1.4.1 → 1.6.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 (44) hide show
  1. package/README.md +168 -183
  2. package/dist/ap2.d.ts +21 -24
  3. package/dist/ap2.js +68 -82
  4. package/dist/ap2.js.map +1 -1
  5. package/dist/authorization-BpbWGGrf.d.ts +115 -0
  6. package/dist/{chunk-NWIQLJNU.js → chunk-74BSEXB5.js} +37 -34
  7. package/dist/chunk-74BSEXB5.js.map +1 -0
  8. package/dist/chunk-AFI2CEZS.js +10 -0
  9. package/dist/chunk-AFI2CEZS.js.map +1 -0
  10. package/dist/chunk-ATTWSFQP.js +680 -0
  11. package/dist/chunk-ATTWSFQP.js.map +1 -0
  12. package/dist/{chunk-ZEGFLRGV.js → chunk-IVJC5YLE.js} +63 -26
  13. package/dist/chunk-IVJC5YLE.js.map +1 -0
  14. package/dist/{chunk-GF6KHHKL.js → chunk-RAJGPGJG.js} +5 -8
  15. package/dist/chunk-RAJGPGJG.js.map +1 -0
  16. package/dist/chunk-V2V2E7HX.js +27 -0
  17. package/dist/chunk-V2V2E7HX.js.map +1 -0
  18. package/dist/cli/index.js +812 -573
  19. package/dist/cli/index.js.map +1 -1
  20. package/dist/constants-Bkq04FRZ.d.ts +48 -0
  21. package/dist/guardrails-71XwtXlT.d.ts +31 -0
  22. package/dist/index.d.ts +245 -265
  23. package/dist/index.js +1222 -626
  24. package/dist/index.js.map +1 -1
  25. package/dist/mcp.d.ts +6 -59
  26. package/dist/mcp.js +64 -53
  27. package/dist/mcp.js.map +1 -1
  28. package/dist/mpp.d.ts +50 -0
  29. package/dist/mpp.js +353 -0
  30. package/dist/mpp.js.map +1 -0
  31. package/dist/protocol-adapter-DTkrXTev.d.ts +238 -0
  32. package/dist/runtime-CiYbgGpi.d.ts +303 -0
  33. package/dist/{types-CJtwLu1c.d.ts → types-O6lg3Q5V.d.ts} +17 -23
  34. package/dist/x402.d.ts +43 -75
  35. package/dist/x402.js +13 -693
  36. package/dist/x402.js.map +1 -1
  37. package/package.json +13 -2
  38. package/dist/authorization-CPDcpJVa.d.ts +0 -123
  39. package/dist/chunk-GF6KHHKL.js.map +0 -1
  40. package/dist/chunk-NWIQLJNU.js.map +0 -1
  41. package/dist/chunk-ZEGFLRGV.js.map +0 -1
  42. package/dist/guardrails-Dmwi63KB.d.ts +0 -38
  43. package/dist/protocol-adapter-Bebmggf_.d.ts +0 -273
  44. package/dist/runtime-CKq3d_3K.d.ts +0 -340
package/dist/index.d.ts CHANGED
@@ -1,48 +1,40 @@
1
- import { f as Ap2AuthorizationConfig } from './types-CJtwLu1c.js';
2
- import { I as IsoTimestamp, D as DecimalAmount, P as PaymentMethodName, a as CommerceResource, b as PaymentSubmission, B as BackendHandler, A as AdapterDescriptor, c as AdapterHealth, R as ResourceRegistry, d as PaymentProvider, L as Logger, C as Clock, e as IdGenerator } from './runtime-CKq3d_3K.js';
3
- export { f as AuthorizationMethodName, g as BackendMethod, h as DEFAULT_BACKEND_TIMEOUT_MS, J as JsonSchema, N as NOOP_LOGGER, i as PROTOCOL_NAMES, j as PaymentChallenge, k as PaymentContext, l as PaymentRequirement, m as PaymentResult, n as PaymentSettlementContext, o as PaymentVerificationContext, p as Pricing, q as ProtocolName, s as systemClock } from './runtime-CKq3d_3K.js';
4
- import { X as X402FacilitatorConfig } from './guardrails-Dmwi63KB.js';
5
- import { a as AuthorizationRequirement, b as AuthorizationSubmission, A as AuthorizationProvider } from './authorization-CPDcpJVa.js';
6
- export { c as AuthorizationFinalizeContext, d as AuthorizationRecord, e as AuthorizationVerification, f as AuthorizationVerificationContext } from './authorization-CPDcpJVa.js';
7
- import { D as DeliveredOutcome, P as PaymentRequiredOutcome, C as CommerceEvent, a as PaymentAttempt, b as CommerceReceipt, E as ExecutionPipeline, c as ProtocolAdapter, H as HttpProtocolAdapter, A as AdapterHttpRoute, d as ProtocolAdapterContext } from './protocol-adapter-Bebmggf_.js';
8
- export { e as COMMERCE_EVENT_TYPES, f as CanonicalRequest, g as CommerceEventType, h as EventSink, i as ExecutionOutcome, j as isHttpProtocolAdapter } from './protocol-adapter-Bebmggf_.js';
1
+ import { f as Ap2AuthorizationConfig } from './types-O6lg3Q5V.js';
2
+ import { I as IsoTimestamp, D as DecimalAmount, P as PaymentMethodName, a as CommerceResource, b as PaymentSubmission, B as BackendHandler, A as AdapterDescriptor, c as AdapterHealth, R as ResourceRegistry, d as PaymentProvider, L as Logger, C as Clock, e as IdGenerator } from './runtime-CiYbgGpi.js';
3
+ export { f as AuthorizationMethodName, g as BackendMethod, h as DEFAULT_BACKEND_TIMEOUT_MS, J as JsonSchema, N as NOOP_LOGGER, i as PAYMENT_METHOD_NAMES, j as PROTOCOL_NAMES, k as PaymentChallenge, l as PaymentContext, m as PaymentRequirement, n as PaymentResult, o as PaymentSettlementContext, p as PaymentVerificationContext, q as Pricing, r as ProtocolName, s as systemClock } from './runtime-CiYbgGpi.js';
4
+ import { M as MppNetwork } from './constants-Bkq04FRZ.js';
5
+ import { X as X402FacilitatorConfig } from './guardrails-71XwtXlT.js';
6
+ import { a as AuthorizationRequirement, b as AuthorizationSubmission, A as AuthorizationProvider } from './authorization-BpbWGGrf.js';
7
+ export { c as AuthorizationFinalizeContext, d as AuthorizationRecord, e as AuthorizationVerification, f as AuthorizationVerificationContext } from './authorization-BpbWGGrf.js';
8
+ import { D as DeliveredOutcome, P as PaymentRequiredOutcome, C as CommerceEvent, a as PaymentAttempt, b as CommerceReceipt, E as ExecutionPipeline, c as ProtocolAdapter, H as HttpProtocolAdapter, A as AdapterHttpRoute, d as ProtocolAdapterContext } from './protocol-adapter-DTkrXTev.js';
9
+ export { e as COMMERCE_EVENT_TYPES, f as CanonicalRequest, g as CommerceEventType, h as EventSink, i as ExecutionOutcome, j as isHttpProtocolAdapter } from './protocol-adapter-DTkrXTev.js';
9
10
  import { FastifyInstance } from 'fastify';
10
11
  import { IncomingMessage, ServerResponse } from 'node:http';
11
12
 
12
13
  /**
13
- * Typed domain error codes.
14
- *
15
- * FROZEN CONTRACT. Protocol adapters map these codes into their own response
16
- * format. Never throw a bare string or untyped Error across a package boundary.
14
+ * Typed domain error codes. FROZEN CONTRACT. Protocol adapters map them into
15
+ * their own response format. Never throw a bare string or untyped Error across
16
+ * an area boundary.
17
17
  */
18
18
  declare const COMMERCE_ERROR_CODES: readonly ["CONFIG_INVALID", "RESOURCE_NOT_FOUND", "INPUT_INVALID", "PAYMENT_REQUIRED", "PAYMENT_INVALID", "PAYMENT_REPLAYED", "PAYMENT_PROVIDER_UNAVAILABLE", "PAYMENT_SETTLEMENT_FAILED", "AUTHORIZATION_REQUIRED", "AUTHORIZATION_INVALID", "AUTHORIZATION_REPLAYED", "AUTHORIZATION_PROVIDER_UNAVAILABLE", "BACKEND_TIMEOUT", "BACKEND_ERROR", "PROTOCOL_UNSUPPORTED", "GATEWAY_BUSY", "STORAGE_ERROR", "INTERNAL_ERROR"];
19
19
  type CommerceErrorCode = (typeof COMMERCE_ERROR_CODES)[number];
20
20
  /**
21
- * Canonical HTTP status for each error code.
22
- *
23
- * Paid resources fail closed: every payment failure maps to a 4xx/5xx status
24
- * and never to a successful delivery.
21
+ * Canonical HTTP status for each error code. Every payment failure maps to a
22
+ * 4xx or 5xx status, never to a delivery.
25
23
  */
26
24
  declare const COMMERCE_ERROR_HTTP_STATUS: Readonly<Record<CommerceErrorCode, number>>;
27
- /** Codes for which a client may reasonably retry the same request. */
25
+ /** Codes for which a client may reasonably retry the same request */
28
26
  declare const RETRYABLE_ERROR_CODES: ReadonlySet<CommerceErrorCode>;
29
27
 
30
- /**
31
- * The single error type crossing package boundaries.
32
- *
33
- * FROZEN CONTRACT.
34
- */
35
-
36
28
  interface CommerceErrorOptions {
37
- /** Structured, non-secret detail safe to return to a client. */
29
+ /** Structured, non-secret detail safe to return to a client */
38
30
  readonly details?: Readonly<Record<string, unknown>>;
39
31
  readonly cause?: unknown;
40
32
  readonly requestId?: string;
41
33
  readonly resourceId?: string;
42
- /** Override the default HTTP status for this code. */
34
+ /** Override the default HTTP status for this code */
43
35
  readonly httpStatus?: number;
44
36
  }
45
- /** Serialisable wire form of a CommerceError. */
37
+ /** Serializable wire form of a CommerceError */
46
38
  interface CommerceErrorInfo {
47
39
  readonly code: CommerceErrorCode;
48
40
  readonly message: string;
@@ -60,118 +52,93 @@ declare class CommerceError extends Error {
60
52
  readonly requestId?: string;
61
53
  readonly resourceId?: string;
62
54
  constructor(code: CommerceErrorCode, message: string, options?: CommerceErrorOptions);
63
- /** Non-secret, client-safe representation. */
55
+ /** Non-secret, client-safe representation. `cause` is never included */
64
56
  toInfo(): CommerceErrorInfo;
65
57
  }
66
58
  declare function isCommerceError(value: unknown): value is CommerceError;
67
59
  /**
68
- * Normalise any thrown value into a CommerceError.
69
- *
70
- * Used at package boundaries so an unexpected failure never escapes untyped.
71
- *
72
- * SECURITY — do not "improve" this by propagating `value.message`.
73
- * `CommerceError.message` is client-visible: it is serialised by `toInfo()`
74
- * and `toErrorEnvelope()` and returned over HTTP and MCP. An arbitrary thrown
75
- * Error's message routinely carries internal detail — database connection
76
- * strings, internal hostnames, filesystem paths, backend URLs. Copying it into
77
- * a client-facing field turns every unexpected exception into an information
78
- * disclosure.
79
- *
80
- * The original value is preserved on `cause`, which is never serialised, so
81
- * logs and diagnostics keep the full detail while clients get only the
82
- * caller's deliberate, reviewed `fallbackMessage`.
60
+ * Passes an existing CommerceError through. Other thrown values become a
61
+ * CommerceError with a caller-chosen message, for example
62
+ * `toCommerceError(err, 'BACKEND_ERROR', 'Backend call failed')`.
83
63
  *
84
- * A caller that *wants* a specific client-facing message passes one:
85
- * toCommerceError(err, 'BACKEND_ERROR', 'Backend call failed')
64
+ * Arbitrary Error messages may contain internal URLs, hostnames or file paths.
65
+ * The original value remains on `cause` for internal logging; `toInfo()` and
66
+ * `toErrorEnvelope()` do not serialize it.
86
67
  */
87
68
  declare function toCommerceError(value: unknown, fallbackCode?: CommerceErrorCode, fallbackMessage?: string): CommerceError;
88
69
 
89
70
  /**
90
- * Gateway-defined wire envelopes.
71
+ * Gateway-defined wire envelopes and carriers. FROZEN CONTRACT.
91
72
  *
92
- * FROZEN CONTRACT. These are the *only* representations of "payment required"
93
- * and "error" that leave the gateway, whichever protocol carries them. The HTTP
94
- * routes, the MCP adapter and the demo buyer agent all use these helpers so the
95
- * three can never drift apart.
73
+ * The HTTP routes and the MCP and A2A adapters build their "payment required"
74
+ * and "error" bodies with these helpers, so those surfaces send the same
75
+ * shapes. The ACP adapter maps errors to ACP's own error format instead.
96
76
  */
97
77
 
98
78
  /**
99
- * Reserved input property carrying a payment proof on protocols that have no
100
- * header channel (MCP tool calls). Over HTTP the `PAYMENT-SIGNATURE` header is
101
- * used.
79
+ * Reserved input property carrying a payment proof on protocols with no header
80
+ * channel (MCP tool calls, A2A message data). HTTP uses a header instead.
102
81
  */
103
82
  declare const PAYMENT_INPUT_FIELD = "_payment";
104
83
  /**
105
- * HTTP request header carrying the payment proof.
84
+ * HTTP request header carrying an x402 payment proof. MPP proofs use
85
+ * `Authorization: Payment ...` instead.
106
86
  *
107
- * x402 v2 header names, lowercased because that is how Node presents incoming
108
- * headers. v1's `X-PAYMENT` / `X-PAYMENT-RESPONSE` pair is not accepted: this
109
- * gateway speaks one protocol version, and quietly honouring both would mean
110
- * two verification paths for the same money.
87
+ * The x402 v2 header names, lowercased as Node presents incoming headers. v1's
88
+ * `X-PAYMENT` / `X-PAYMENT-RESPONSE` pair is not accepted: honoring both
89
+ * versions would mean two verification paths for the same money.
111
90
  */
112
91
  declare const PAYMENT_HEADER = "payment-signature";
113
- /** HTTP response header carrying the settlement result. */
92
+ /** HTTP response header carrying the settlement result */
114
93
  declare const PAYMENT_RESPONSE_HEADER = "payment-response";
115
94
  /**
116
- * Reserved input property carrying an authorization proof, the authorization
117
- * counterpart of {@link PAYMENT_INPUT_FIELD}.
95
+ * Reserved input property carrying an authorization proof, the counterpart of
96
+ * {@link PAYMENT_INPUT_FIELD}.
118
97
  *
119
- * Unlike `_payment`, which is a bare string, this one carries an object:
120
- * `{ method, payload }`. There is exactly one payment rail per resource, so a
121
- * payment proof's method can be inferred from the resource; an authorization
122
- * proof cannot lean on that, and guessing the method of a security control is
123
- * not a thing to do implicitly.
98
+ * `_payment` is a bare string whose method is taken from the resource's first
99
+ * payment method. This field is a `{ method, payload }` object, because the
100
+ * method of a security control should be stated, not inferred.
124
101
  */
125
102
  declare const AUTHORIZATION_INPUT_FIELD = "_authorization";
126
103
  /**
127
- * Every input property name the gateway claims for itself.
128
- *
129
- * One list, read by the config loader (which rejects a resource declaring any
130
- * of them), by the protocol adapters that lift them out of client input, and
131
- * by the pipeline that strips them again as defence in depth. Those three
132
- * agree by construction instead of by three copies of two strings.
104
+ * Every input property name the gateway claims for itself. The config loader
105
+ * rejects a resource declaring one, protocol adapters lift them out of client
106
+ * input, and the pipeline strips them again as defense in depth.
133
107
  */
134
108
  declare const RESERVED_INPUT_FIELDS: readonly string[];
135
109
  /**
136
- * HTTP request header carrying the authorization proof, base64url-encoded
137
- * JSON of the same `{ method, payload }` envelope the reserved input field
138
- * carries.
110
+ * HTTP request header carrying the authorization proof: base64url-encoded JSON
111
+ * of the same `{ method, payload }` object the reserved input field carries.
139
112
  *
140
- * This is an Agent Commerce transport carrier, not a header defined by any
141
- * authorization specification, so it is namespaced rather than borrowing
142
- * `Authorization`, which already means something else on every one of these
143
- * routes.
113
+ * An Agent Commerce carrier, not a header from any authorization
114
+ * specification. It is namespaced rather than reusing `Authorization`, which
115
+ * already carries other credentials, including MPP payment proofs.
144
116
  */
145
117
  declare const AUTHORIZATION_HEADER = "agent-authorization";
146
118
  /**
147
119
  * Hard cap on the encoded `Agent-Authorization` header.
148
120
  *
149
- * Node's own limit is ~16 KiB across *all* request headers, so an
150
- * authorization near that size would start evicting everything else and fail
151
- * as an unreadable transport error rather than a legible one. Capping well
152
- * below it means an oversized proof gets a deterministic
153
- * AUTHORIZATION_INVALID naming the limit.
121
+ * Node's default limit is 16 KiB across all request headers, and a request over
122
+ * it is refused before the gateway sees it. Capping well below that gives an
123
+ * oversized proof a deterministic `AUTHORIZATION_INVALID` naming the limit.
154
124
  */
155
125
  declare const MAX_AUTHORIZATION_HEADER_BYTES = 8192;
156
126
  /**
157
- * HTTP response header carrying the base64 payment challenge on a 402.
127
+ * HTTP response header carrying the base64 x402 challenge on a 402.
158
128
  *
159
- * The 402 body still carries {@link PaymentRequiredEnvelope} — richer, and the
160
- * only channel MCP has — but an x402 v2 client reads the challenge from this
161
- * header and ignores the body, so both are sent.
129
+ * The body still carries the richer {@link PaymentRequiredEnvelope}, the only
130
+ * channel MCP has, but an x402 v2 client reads the challenge from this header
131
+ * and ignores the body, so both are sent.
162
132
  */
163
133
  declare const PAYMENT_REQUIRED_HEADER = "payment-required";
164
134
  /**
165
135
  * Key under which a protocol adapter attaches a {@link DeliverySummary} to its
166
- * result metadata — MCP's `CallToolResult._meta`, and anywhere else a protocol
167
- * offers an out-of-band metadata channel.
168
- *
169
- * Frozen deliberately. The bug this whole mechanism exists to fix was two
170
- * surfaces disagreeing about what a payer gets back; a key name enforced only
171
- * by one side's tests would reintroduce exactly that drift. Producer and
172
- * consumer both import this constant.
136
+ * result metadata: MCP's `CallToolResult._meta` and the A2A task artifact's
137
+ * metadata.
173
138
  *
174
- * Follows MCP's `<namespace>/<name>` convention for `_meta` keys.
139
+ * Part of the frozen contract because producer and consumer must agree on it;
140
+ * both import this constant. Follows MCP's `<namespace>/<name>` convention for
141
+ * `_meta` keys.
175
142
  */
176
143
  declare const DELIVERY_SUMMARY_META_KEY = "agent-commerce/delivery";
177
144
  interface PaymentRequiredEnvelope {
@@ -189,24 +156,21 @@ interface PaymentRequiredEnvelope {
189
156
  readonly network?: string;
190
157
  readonly asset?: string;
191
158
  readonly expiresAt?: IsoTimestamp;
192
- /** Provider-native requirement objects, passed through verbatim. */
159
+ /** Provider-native requirement objects, passed through verbatim */
193
160
  readonly accepts: readonly Readonly<Record<string, unknown>>[];
194
161
  /**
195
- * The provider's own challenge document, verbatim — see
196
- * {@link PaymentChallenge.envelope}. Present for providers that have one;
197
- * a buyer's protocol client can hand this straight to its SDK.
162
+ * The provider's own challenge document, verbatim (see
163
+ * {@link PaymentChallenge.envelope}). Present for providers that have one;
164
+ * a buyer's protocol client can hand it straight to its SDK.
198
165
  */
199
166
  readonly envelope?: Readonly<Record<string, unknown>>;
200
167
  };
201
168
  /**
202
- * Present only when the resource requires an authorization proof as well.
203
- *
204
- * Additive: a client that does not understand the field sees exactly the
205
- * envelope it saw before. A client that does learns, before it spends
206
- * anything, that paying alone will not get the resource delivered.
207
- *
208
- * This advertises a requirement; it does not issue anything. The proof is
209
- * obtained from the merchant's own approval flow, outside the gateway.
169
+ * Present only when the resource also requires an authorization proof, so a
170
+ * client learns before it spends anything that paying alone will not get the
171
+ * resource delivered. A client that ignores the field sees the plain
172
+ * envelope. The proof comes from the merchant's own approval flow, outside
173
+ * the gateway.
210
174
  */
211
175
  readonly authorization?: {
212
176
  readonly required: readonly AuthorizationRequirement[];
@@ -222,17 +186,10 @@ interface ErrorEnvelope {
222
186
  readonly details?: Readonly<Record<string, unknown>>;
223
187
  }
224
188
  /**
225
- * What a buyer learns about their own completed purchase.
226
- *
227
- * A payer is entitled to the record of their own transaction — the request it
228
- * belonged to, whether it settled, and the settlement reference they can check
229
- * on-chain. They are NOT entitled to the merchant's ledger, which is why
230
- * `/api/receipts` is an operator route behind `server.adminToken`.
231
- *
232
- * Before this existed the two surfaces disagreed: HTTP callers received a
233
- * settlement summary in the payment-response header while MCP callers received
234
- * nothing, so an MCP buyer's only route to their own receipt was the merchant's
235
- * ledger. Both surfaces now emit this same shape.
189
+ * What a buyer learns about their own completed purchase: the request, whether
190
+ * it settled, and the settlement reference they can check on-chain. The
191
+ * merchant's ledger is not theirs to read, which is why `/api/receipts` is an
192
+ * operator route behind `server.adminToken`.
236
193
  */
237
194
  interface DeliverySummary {
238
195
  readonly requestId: string;
@@ -243,46 +200,42 @@ interface DeliverySummary {
243
200
  readonly status: 'verified' | 'settled' | 'rejected';
244
201
  readonly amount: DecimalAmount;
245
202
  readonly currency: string;
246
- /** Settlement reference, e.g. an on-chain transaction hash. */
203
+ /** Settlement reference, e.g. an on-chain transaction hash */
247
204
  readonly externalReference?: string;
248
205
  readonly network?: string;
249
206
  };
250
207
  }
251
- /** Build the payer-facing summary of a delivered outcome. */
208
+ /** Build the payer-facing summary of a delivered outcome */
252
209
  declare function toDeliverySummary(outcome: DeliveredOutcome): DeliverySummary;
253
210
  declare function toPaymentRequiredEnvelope(outcome: PaymentRequiredOutcome): PaymentRequiredEnvelope;
254
211
  declare function toErrorEnvelope(error: CommerceError): ErrorEnvelope;
255
212
  declare function isPaymentRequiredEnvelope(value: unknown): value is PaymentRequiredEnvelope;
256
213
  /**
257
- * Parses the `{ method, payload }` authorization envelope, whichever carrier
258
- * brought it.
214
+ * Parses the `{ method, payload }` authorization object, whichever carrier
215
+ * brought it. Absent returns `undefined`; malformed throws
216
+ * `AUTHORIZATION_INVALID`.
259
217
  *
260
- * Absent is `undefined`. Present but malformed throws, rather than being
261
- * dropped the way an unusable `_payment` is. A dropped payment leaves the
262
- * buyer holding a 402 they can act on. A silently dropped authorization would
263
- * come back as "not authorized" for a proof the client believes it sent, with
264
- * no way to tell a rejected mandate from a typo in the envelope around it.
218
+ * An unusable `_payment` is dropped, which leaves the buyer a 402 to act on. A
219
+ * dropped authorization would instead come back as "not authorized", with no
220
+ * way to tell a rejected mandate from a typo in the object around it.
265
221
  */
266
222
  declare function parseAuthorizationSubmission(value: unknown, requestId?: string): AuthorizationSubmission | undefined;
267
223
  /**
268
- * Decodes the base64url-JSON `Agent-Authorization` header.
269
- *
270
- * The size check runs on the encoded value before any decoding, so an
271
- * oversized header costs a length comparison rather than a base64 decode and
272
- * a JSON parse of whatever a caller chose to send.
224
+ * Decodes the base64url JSON `Agent-Authorization` header. The size check runs
225
+ * on the encoded value, so an oversized header costs a length comparison rather
226
+ * than a decode and a JSON parse.
273
227
  */
274
228
  declare function parseAuthorizationHeader(raw: string | readonly string[] | undefined, requestId?: string): AuthorizationSubmission | undefined;
275
229
  /**
276
- * Splits raw client input into resource input plus the reserved fields the
277
- * gateway claims, for every protocol that carries them in the input object
278
- * (MCP tool arguments, A2A message data). HTTP carries both in headers and
279
- * uses the two parse helpers directly.
230
+ * Splits raw client input into resource input plus the reserved fields, for
231
+ * protocols that carry them in the input object (MCP tool arguments, A2A
232
+ * message data). HTTP carries both in headers.
280
233
  *
281
- * The payment method comes from the resource's own declaration. This is not
282
- * the place that decides which rail a resource uses, so a proof for a
283
- * resource with no configured rail is dropped rather than forwarded under an
284
- * invented method. The pipeline then treats the request as unpaid and decides
285
- * on its own terms.
234
+ * A payment proof is labeled with the resource's first payment method.
235
+ * `createGateway` puts provider-backed methods first so the label matches the
236
+ * pipeline's selection; a custom registry must keep that order. A resource with
237
+ * no payment method gets no payment proof, so the request reaches the pipeline
238
+ * unpaid.
286
239
  */
287
240
  declare function extractReservedInputFields(rawInput: Record<string, unknown>, resource: CommerceResource | undefined, requestId?: string): {
288
241
  input: Record<string, unknown>;
@@ -291,26 +244,25 @@ declare function extractReservedInputFields(rawInput: Record<string, unknown>, r
291
244
  };
292
245
 
293
246
  /**
294
- * Merchant backend execution boundary.
295
- *
296
- * The only place in the system allowed to make an outbound HTTP call to a
297
- * merchant backend. Every call is bounded by a timeout; redirects are not
298
- * followed (see docs/security.md).
247
+ * The gateway's only boundary for calling a merchant backend. An
248
+ * implementation must bound every call with a timeout and must not follow
249
+ * redirects; the built-in HTTP executor does both (docs/security.md).
299
250
  */
300
251
 
301
252
  interface BackendRequest {
302
253
  readonly requestId: string;
303
254
  readonly resourceId: string;
304
- /** Validated resource input. */
255
+ /** Validated resource input */
305
256
  readonly input: unknown;
306
257
  /**
307
- * Names the *operation*, so the merchant can recognise a repeat of it.
258
+ * Names the operation, so the merchant can recognize a repeat of it. Not
259
+ * `requestId`, which is fresh per call and would make every retry look like
260
+ * new work.
308
261
  *
309
- * Not `requestId`, which is fresh per call and would make every retry look
310
- * like new work. An adapter sets this only when it can derive a value that
311
- * survives a client retry, a reconnect and a gateway restart; the HTTP
312
- * executor forwards it as the `Idempotency-Key` request header. Absent
313
- * means the protocol has no such notion, and the merchant sees no header.
262
+ * An adapter sets it only when the value survives a client retry, a
263
+ * reconnect and a gateway restart. The HTTP executor sends it as the
264
+ * `Idempotency-Key` header, replacing one set in `BackendHandler.headers`;
265
+ * when absent, the executor adds none.
314
266
  */
315
267
  readonly idempotencyKey?: string;
316
268
  }
@@ -332,17 +284,16 @@ interface BackendExecutor {
332
284
  }
333
285
 
334
286
  /**
335
- * Persistence boundary for receipts, events and payment attempts.
336
- *
337
- * Implemented by src/storage/receipts. Core depends only on this
338
- * interface, never on SQLite.
287
+ * Persistence boundary for receipts, events and payment attempts, implemented
288
+ * by src/storage/receipts. Core depends only on this interface, never on
289
+ * SQLite.
339
290
  */
340
291
 
341
292
  interface PaymentAttemptReservation {
342
293
  readonly requestId: string;
343
294
  readonly resourceId: string;
344
295
  readonly provider: string;
345
- /** Must be unique across the store — see PaymentResult.replayKey. */
296
+ /** Must be unique across the store; see `PaymentResult.replayKey` */
346
297
  readonly replayKey: string;
347
298
  readonly amount: string;
348
299
  readonly currency: string;
@@ -361,14 +312,12 @@ interface ListOptions {
361
312
  }
362
313
  interface ReceiptStore {
363
314
  init(): Promise<void>;
364
- /** Append a canonical event. Must not throw into the caller's flow. */
315
+ /** Append a canonical event. Must not throw into the caller's flow */
365
316
  appendEvent(event: CommerceEvent): Promise<void>;
366
317
  /**
367
- * Atomically claim a payment authorisation before settlement.
368
- *
369
- * Throws `CommerceError('PAYMENT_REPLAYED')` if `replayKey` was already
370
- * reserved. This is the gateway's replay defence and is required for every
371
- * paid request.
318
+ * Atomically claim a payment authorization before settlement: the gateway's
319
+ * replay defense, run for every paid request. Throws
320
+ * `CommerceError('PAYMENT_REPLAYED')` if `replayKey` was already reserved.
372
321
  */
373
322
  reservePaymentAttempt(reservation: PaymentAttemptReservation): Promise<PaymentAttempt>;
374
323
  updatePaymentAttempt(update: PaymentAttemptUpdate): Promise<void>;
@@ -376,33 +325,19 @@ interface ReceiptStore {
376
325
  getReceipt(id: string): Promise<CommerceReceipt | undefined>;
377
326
  listReceipts(options?: ListOptions): Promise<readonly CommerceReceipt[]>;
378
327
  /**
379
- * Total receipts held, ignoring any list limit.
380
- *
381
- * `listReceipts` clamps to a bounded page (a store-level invariant, so an
382
- * unbounded `limit` cannot dump the ledger). Counting by measuring the length
383
- * of a list therefore silently saturates at the clamp — `doctor` reported
384
- * "receipts=500" forever once 500 was passed. A diagnostic that quietly stops
385
- * counting is worse than one that admits it cannot.
328
+ * Total receipts held. `listReceipts` clamps every page, so counting a list's
329
+ * length would stop at the clamp.
386
330
  */
387
331
  countReceipts(): Promise<number>;
388
332
  /**
389
- * Receipts whose delivery did not succeed — `backendStatus` outside 2xx.
333
+ * Receipts whose delivery failed: `backendStatus` outside 2xx, including 0
334
+ * when no status is known. Counted rather than listed for the same reason as
335
+ * {@link countReceipts}.
390
336
  *
391
- * A paid-but-undelivered purchase is the one row a merchant must notice:
392
- * settlement is final and this release has no refunds, so *seeing* it is the only
393
- * remedy available. Counted rather than listed for the same reason as
394
- * {@link countReceipts} — `listReceipts` is clamped, so counting by list
395
- * length silently saturates.
396
- *
397
- * In practice this is exactly "paid but undelivered", not "any failed
398
- * delivery": the pipeline only ever persists a receipt when a payment was
399
- * attempted (`paymentResult !== undefined`), so a free resource whose
400
- * backend call fails throws without writing a receipt at all — there is no
401
- * row for `countUndeliveredReceipts` to see. Free-resource failures are
402
- * therefore *not* counted here, however natural it is to read the name as
403
- * saying they are. Writing a receipt for a failed free delivery too would be
404
- * a more complete ledger, but it changes what this count means — that is
405
- * a product decision for after the alpha, not something to do here.
337
+ * In practice this is "paid but undelivered": the pipeline writes a receipt
338
+ * for a failed delivery only after a settled payment, so a free resource
339
+ * whose backend fails leaves no row here. It is the row a merchant must
340
+ * notice, because settlement is final and the gateway issues no refunds.
406
341
  */
407
342
  countUndeliveredReceipts(): Promise<number>;
408
343
  listEvents(options?: ListOptions): Promise<readonly CommerceEvent[]>;
@@ -429,7 +364,7 @@ interface ReceiptStore {
429
364
  */
430
365
  declare const ACP_SPEC_VERSION = "2026-04-17";
431
366
  declare const ACP_API_VERSION = "2026-04-17";
432
- /** Discovery path fixed by the ACP specification - never a configurable mount. */
367
+ /** Discovery path fixed by the ACP specification, never a configurable mount */
433
368
  declare const ACP_WELL_KNOWN_PATH = "/.well-known/acp.json";
434
369
  /**
435
370
  * The stable checkout operations, by ACP operation id. All five are required
@@ -440,32 +375,25 @@ declare const ACP_CHECKOUT_OPERATIONS: readonly ["createCheckoutSession", "updat
440
375
  type AcpCheckoutOperation = (typeof ACP_CHECKOUT_OPERATIONS)[number];
441
376
 
442
377
  /**
443
- * `config.yaml` schema, validation and normalisation into the
444
- * canonical `GatewayConfig` (docs/contracts.md).
378
+ * `config.yaml` schema, validation and normalization into the canonical
379
+ * `GatewayConfig` (docs/contracts.md).
445
380
  *
446
- * Two-phase validation:
447
- * 1. Zod validates *shape* (types, required fields, unknown-key rejection).
448
- * Numeric/boolean leaves accept either their native type or a string
449
- * (env substitution always produces a string), and are left as-is here -
450
- * Zod's typed transforms have surprising inference interactions with
451
- * `.strict()` objects, so numeric/boolean coercion is done explicitly,
452
- * in plain TypeScript, in the normalisation pass below.
453
- * 2. A manual business-rule pass validates cross-references that need a
454
- * specific, actionable message (duplicate ids, disabled protocols/payment
455
- * methods, dynamic pricing, destination-address plausibility) and
456
- * performs the numeric/boolean coercion.
381
+ * 1. Zod validates shape: types, required fields, unknown keys. Numeric and
382
+ * boolean leaves accept their native type or a string, because env
383
+ * substitution produces strings. Zod transforms interact badly with
384
+ * `.strict()` inference, so coercion happens in plain TypeScript in step 2.
385
+ * 2. A business-rule pass coerces those leaves and checks what needs a
386
+ * specific message: cross-references, disabled protocols and payment
387
+ * methods, dynamic pricing, addresses, duplicate trust entries.
457
388
  *
458
- * Env substitution (`${VAR}` / `${VAR:-default}`) runs over the raw parsed
459
- * value *before* either phase, so numeric/boolean fields can be templated too.
460
- * One exception, deliberate: `checkVersion` runs **before** substitution, so
461
- * `version:` cannot itself be templated. It is the compatibility gate that
462
- * decides whether this parser understands the document at all; resolving
463
- * environment variables to find out which schema version to expect would be
464
- * backwards. The order is intended; `version:` is the one exception to the
465
- * substitution rule, which this sentence exists to record.
389
+ * Env substitution (`${VAR}` / `${VAR:-default}`) runs over the raw value
390
+ * before both steps, so numeric and boolean fields can be templated. The one
391
+ * exception is `version:`, checked before substitution: it decides whether this
392
+ * parser understands the document at all, so it cannot depend on the
393
+ * environment.
466
394
  */
467
395
 
468
- /** Optional ACP discovery metadata. Absent fields are omitted from the document. */
396
+ /** Optional ACP discovery metadata. Absent fields are omitted from the document */
469
397
  interface AcpDiscoveryConfig {
470
398
  readonly documentationUrl?: string;
471
399
  readonly supportedCurrencies?: readonly string[];
@@ -473,9 +401,8 @@ interface AcpDiscoveryConfig {
473
401
  readonly interventionTypes?: readonly string[];
474
402
  }
475
403
  /**
476
- * Discriminated on `enabled` so an enabled ACP config carries everything the
477
- * adapter needs, with no optional-field assertions at the mount point: a
478
- * half-configured checkout lifecycle is rejected at load instead.
404
+ * Discriminated on `enabled`, so an enabled ACP config carries everything the
405
+ * adapter needs; a half-configured checkout is rejected at load
479
406
  */
480
407
  type AcpProtocolConfig = {
481
408
  readonly enabled: false;
@@ -529,7 +456,7 @@ interface GatewayConfig {
529
456
  };
530
457
  readonly acp: AcpProtocolConfig;
531
458
  };
532
- /** Canonical resources, already normalised. */
459
+ /** Canonical resources, already normalized */
533
460
  readonly resources: readonly CommerceResource[];
534
461
  readonly payments: {
535
462
  readonly x402?: {
@@ -546,11 +473,23 @@ interface GatewayConfig {
546
473
  readonly allowMainnet?: boolean;
547
474
  readonly allowUnauthenticatedFacilitator?: boolean;
548
475
  };
476
+ readonly mpp?: {
477
+ readonly enabled: boolean;
478
+ readonly network: MppNetwork;
479
+ readonly rpcUrl: string;
480
+ readonly asset: string;
481
+ readonly assetName: string;
482
+ readonly assetVersion: string;
483
+ readonly recipient: string;
484
+ readonly realm: string;
485
+ readonly challengeSecret: string;
486
+ readonly challengeTtlSeconds?: number;
487
+ readonly facilitator: X402FacilitatorConfig;
488
+ readonly allowMainnet?: boolean;
489
+ readonly allowUnauthenticatedFacilitator?: boolean;
490
+ };
549
491
  };
550
- /**
551
- * Absent when no `authorization:` block is configured, which is how every
552
- * config written before AP2 existed reads.
553
- */
492
+ /** Absent when no `authorization:` block is configured */
554
493
  readonly authorization?: {
555
494
  readonly ap2: Ap2AuthorizationConfig;
556
495
  };
@@ -564,22 +503,17 @@ interface LoadConfigOptions {
564
503
  }
565
504
  declare function loadConfig(options?: LoadConfigOptions): Promise<GatewayConfig>;
566
505
 
567
- /**
568
- * `createGateway()` — the Fastify server. Fully usable (and tested) with
569
- * fakes, without `main.ts` (docs/contracts.md "Composition root").
570
- */
571
-
572
506
  interface GatewayOptions {
573
507
  readonly config: GatewayConfig;
574
508
  readonly store: ReceiptStore;
575
509
  readonly paymentProviders: readonly PaymentProvider[];
576
- /** Absent means no resource requires authorization, which is the default */
510
+ /** Defaults to none; each resource declares the methods it requires */
577
511
  readonly authorizationProviders?: readonly AuthorizationProvider[];
578
512
  readonly protocolAdapters: readonly ProtocolAdapter[];
579
513
  readonly logger?: Logger;
580
514
  readonly clock?: Clock;
581
515
  readonly ids?: IdGenerator;
582
- /** Override for tests. */
516
+ /** Override for tests */
583
517
  readonly backend?: BackendExecutor;
584
518
  }
585
519
  interface GatewayInstance {
@@ -589,12 +523,79 @@ interface GatewayInstance {
589
523
  url: string;
590
524
  }>;
591
525
  close(): Promise<void>;
592
- /** Fastify instance, for `.inject()` in tests. */
526
+ /** Fastify instance, for `.inject()` in tests */
593
527
  readonly server: FastifyInstance;
594
528
  }
595
529
  declare function createGateway(options: GatewayOptions): Promise<GatewayInstance>;
596
530
 
597
- /** Discovery metadata an operator may configure. Absent fields are omitted, never guessed. */
531
+ /**
532
+ * A2A (Agent2Agent) protocol adapter, experimental.
533
+ *
534
+ * Serves two paths: the configured mount (`/a2a`), where the JSON-RPC endpoint
535
+ * lives, and the specification-fixed `/.well-known/agent-card.json`, declared
536
+ * through `additionalHttpRoutes` so the gateway needs no A2A-specific routing.
537
+ *
538
+ * Only the synchronous `SendMessage` path is in scope; every other A2A method
539
+ * is listed in `descriptor.unsupported` rather than half-served. This file
540
+ * never calls a merchant backend and never inspects a payment object.
541
+ */
542
+
543
+ interface A2aAdapterOptions {
544
+ readonly mountPath?: string;
545
+ /** Agent name published on the card */
546
+ readonly agentName?: string;
547
+ readonly agentDescription?: string;
548
+ /** Version published on the card. Defaults to this package's version */
549
+ readonly agentVersion?: string;
550
+ }
551
+ declare class A2aProtocolAdapter implements HttpProtocolAdapter {
552
+ readonly name: "a2a";
553
+ readonly mountPath: string;
554
+ readonly descriptor: AdapterDescriptor;
555
+ readonly additionalHttpRoutes: readonly AdapterHttpRoute[];
556
+ private readonly agentName;
557
+ private readonly agentDescription;
558
+ private readonly agentVersion;
559
+ private context;
560
+ private started;
561
+ private skillsById;
562
+ private card;
563
+ constructor(options?: A2aAdapterOptions);
564
+ start(context: ProtocolAdapterContext): Promise<void>;
565
+ /** `GET /.well-known/agent-card.json` */
566
+ handleAgentCard(req: IncomingMessage, res: ServerResponse): Promise<void>;
567
+ /** `POST <mountPath>`: the A2A JSON-RPC endpoint */
568
+ handleHttp(req: IncomingMessage, res: ServerResponse): Promise<void>;
569
+ private dispatch;
570
+ private execute;
571
+ private taskIdentity;
572
+ private taskResult;
573
+ health(): Promise<AdapterHealth>;
574
+ stop(): Promise<void>;
575
+ private writeJson;
576
+ }
577
+ declare function createA2aAdapter(options?: A2aAdapterOptions): A2aProtocolAdapter;
578
+
579
+ /**
580
+ * A2A pins, kept in one place so nothing infers one version from another.
581
+ *
582
+ * The specification revision and the negotiation version look alike but
583
+ * differ: `1.0.0` names the document this adapter was written against, `1.0`
584
+ * is what a client negotiates on the wire. Neither is this package's version
585
+ * (`PACKAGE_VERSION`).
586
+ */
587
+ /** A2A specification revision this adapter targets */
588
+ declare const A2A_SPEC_VERSION = "1.0.0";
589
+ /** Protocol negotiation version carried on the wire */
590
+ declare const A2A_PROTOCOL_VERSION = "1.0";
591
+ /**
592
+ * Fixed by the A2A specification: a client fetches the card from this exact
593
+ * path, so it is not configurable. `src/config` reserves it against adapter
594
+ * mounts for the same reason.
595
+ */
596
+ declare const A2A_AGENT_CARD_PATH = "/.well-known/agent-card.json";
597
+
598
+ /** Discovery metadata an operator may configure. Absent fields are omitted, never guessed */
598
599
  interface AcpDiscoveryMetadata {
599
600
  readonly documentationUrl?: string;
600
601
  readonly supportedCurrencies?: readonly string[];
@@ -603,29 +604,25 @@ interface AcpDiscoveryMetadata {
603
604
  }
604
605
 
605
606
  /**
606
- * ACP (Agentic Commerce Protocol) adapter - experimental.
607
+ * ACP (Agentic Commerce Protocol) adapter, experimental.
607
608
  *
608
609
  * Serves two paths: the configured mount (`/acp`), where the five stable
609
610
  * checkout routes live, and the specification-fixed `/.well-known/acp.json`,
610
611
  * declared through `additionalHttpRoutes` so the gateway needs no ACP-specific
611
612
  * routing.
612
613
  *
613
- * Discovery and every protocol guard that must hold before canonical execution
614
- * are implemented. A guarded request is not executed yet: until checkout
615
- * operations reach the pipeline, a fully-valid request is answered with an
616
- * honest "not implemented" rather than a fabricated session.
617
- *
618
- * This file never calls a merchant backend and never inspects a payment
619
- * object.
614
+ * A request that passes every protocol guard runs its mapped resource through
615
+ * the pipeline, under an idempotency claim when it carries a key. This file
616
+ * never calls a merchant backend and never inspects a payment object.
620
617
  */
621
618
 
622
619
  interface AcpAdapterOptions {
623
620
  readonly mountPath: string;
624
- /** The configured bearer token. Never logged, never echoed, never published. */
621
+ /** The configured bearer token. Never logged, never echoed, never published */
625
622
  readonly token: string;
626
- /** Which canonical resource implements each ACP checkout operation. */
623
+ /** Which canonical resource implements each ACP checkout operation */
627
624
  readonly operations: Readonly<Record<AcpCheckoutOperation, string>>;
628
- /** Where checkout idempotency records live, and how long they are kept. */
625
+ /** Where checkout idempotency records live, and how long they are kept */
629
626
  readonly idempotency: {
630
627
  readonly path: string;
631
628
  readonly retentionHours: number;
@@ -637,15 +634,12 @@ declare class AcpProtocolAdapter implements HttpProtocolAdapter {
637
634
  readonly mountPath: string;
638
635
  readonly descriptor: AdapterDescriptor;
639
636
  readonly additionalHttpRoutes: readonly AdapterHttpRoute[];
640
- private readonly token;
637
+ private readonly isAuthorized;
641
638
  private readonly operations;
642
639
  private readonly idempotencyOptions;
643
640
  /**
644
- * What an idempotency claim is scoped to, from `context.publicBaseUrl`.
645
- *
646
- * Not readonly because, unlike the token, it is known only once the adapter
647
- * starts. Worth that: scoping by the credential meant a rotation freed
648
- * every outstanding claim.
641
+ * The deployment an idempotency claim is scoped to, `context.publicBaseUrl`.
642
+ * Not readonly because it is known only once the adapter starts.
649
643
  */
650
644
  private deployment;
651
645
  private readonly discoveryMetadata;
@@ -656,31 +650,17 @@ declare class AcpProtocolAdapter implements HttpProtocolAdapter {
656
650
  private discovery;
657
651
  constructor(options: AcpAdapterOptions);
658
652
  start(context: ProtocolAdapterContext): Promise<void>;
659
- /** `GET /.well-known/acp.json` - public, unauthenticated, cacheable. */
653
+ /** `GET /.well-known/acp.json`: public, unauthenticated, cacheable */
660
654
  handleDiscovery(req: IncomingMessage, res: ServerResponse): Promise<void>;
661
- /** `<mountPath>/checkout_sessions...` - the five stable checkout routes. */
655
+ /** `<mountPath>/checkout_sessions...`: the five stable checkout routes */
662
656
  handleHttp(req: IncomingMessage, res: ServerResponse): Promise<void>;
663
657
  /**
664
- * One request, at most one execution.
665
- *
666
- * A body-bearing route claims its idempotency key *before* the work starts,
667
- * so a retry that arrives while the first one is still running finds the
668
- * claim instead of starting a second checkout. A route with no key (the GET)
669
- * is read-only and needs none.
658
+ * One request, at most one execution. A body-bearing route claims its
659
+ * idempotency key before the work starts, so a retry arriving meanwhile finds
660
+ * the claim; the read-only GET carries no key.
670
661
  */
671
662
  private dispatch;
672
- /**
673
- * One accepted request, one `pipeline.execute()`.
674
- *
675
- * Nothing here prices a resource, inspects a payment proof or calls a
676
- * merchant backend: the adapter builds a canonical request and reads back
677
- * what the pipeline decided.
678
- */
679
663
  private runCheckout;
680
- /**
681
- * Protocol-owned headers only. A merchant backend's own headers are never
682
- * proxied onto an ACP response.
683
- */
684
664
  private responseHeaders;
685
665
  private fail;
686
666
  health(): Promise<AdapterHealth>;
@@ -689,7 +669,7 @@ declare class AcpProtocolAdapter implements HttpProtocolAdapter {
689
669
  declare function createAcpAdapter(options: AcpAdapterOptions): AcpProtocolAdapter;
690
670
 
691
671
  interface SqliteReceiptStoreOptions {
692
- /** File path, or ':memory:' for tests. Parent directory is created if missing. */
672
+ /** File path, or ':memory:' for tests. Parent directory is created if missing */
693
673
  readonly path: string;
694
674
  readonly logger?: Logger;
695
675
  readonly clock?: Clock;
@@ -697,4 +677,4 @@ interface SqliteReceiptStoreOptions {
697
677
  }
698
678
  declare function createSqliteReceiptStore(options: SqliteReceiptStoreOptions): ReceiptStore;
699
679
 
700
- export { ACP_API_VERSION, ACP_SPEC_VERSION, ACP_WELL_KNOWN_PATH, AUTHORIZATION_HEADER, AUTHORIZATION_INPUT_FIELD, type AcpAdapterOptions, AdapterDescriptor, AdapterHealth, AdapterHttpRoute, AuthorizationProvider, AuthorizationRequirement, AuthorizationSubmission, type BackendExecutor, BackendHandler, type BackendRequest, type BackendResponse, COMMERCE_ERROR_CODES, COMMERCE_ERROR_HTTP_STATUS, Clock, CommerceError, type CommerceErrorCode, type CommerceErrorInfo, type CommerceErrorOptions, CommerceEvent, CommerceReceipt, CommerceResource, DELIVERY_SUMMARY_META_KEY, DecimalAmount, DeliveredOutcome, type DeliverySummary, type ErrorEnvelope, ExecutionPipeline, type GatewayConfig, type GatewayInstance, type GatewayOptions, HttpProtocolAdapter, IdGenerator, IsoTimestamp, type ListOptions, Logger, MAX_AUTHORIZATION_HEADER_BYTES, PAYMENT_HEADER, PAYMENT_INPUT_FIELD, PAYMENT_REQUIRED_HEADER, PAYMENT_RESPONSE_HEADER, PaymentAttempt, type PaymentAttemptReservation, type PaymentAttemptUpdate, PaymentMethodName, PaymentProvider, type PaymentRequiredEnvelope, PaymentRequiredOutcome, PaymentSubmission, ProtocolAdapter, ProtocolAdapterContext, RESERVED_INPUT_FIELDS, RETRYABLE_ERROR_CODES, type ReceiptStore, ResourceRegistry, createAcpAdapter, createGateway, createSqliteReceiptStore, extractReservedInputFields, isCommerceError, isPaymentRequiredEnvelope, loadConfig, parseAuthorizationHeader, parseAuthorizationSubmission, parseConfig, createSqliteReceiptStore as receipts, toCommerceError, toDeliverySummary, toErrorEnvelope, toPaymentRequiredEnvelope };
680
+ export { A2A_AGENT_CARD_PATH, A2A_PROTOCOL_VERSION, A2A_SPEC_VERSION, type A2aAdapterOptions, ACP_API_VERSION, ACP_SPEC_VERSION, ACP_WELL_KNOWN_PATH, AUTHORIZATION_HEADER, AUTHORIZATION_INPUT_FIELD, type AcpAdapterOptions, AdapterDescriptor, AdapterHealth, AdapterHttpRoute, AuthorizationProvider, AuthorizationRequirement, AuthorizationSubmission, type BackendExecutor, BackendHandler, type BackendRequest, type BackendResponse, COMMERCE_ERROR_CODES, COMMERCE_ERROR_HTTP_STATUS, Clock, CommerceError, type CommerceErrorCode, type CommerceErrorInfo, type CommerceErrorOptions, CommerceEvent, CommerceReceipt, CommerceResource, DELIVERY_SUMMARY_META_KEY, DecimalAmount, DeliveredOutcome, type DeliverySummary, type ErrorEnvelope, ExecutionPipeline, type GatewayConfig, type GatewayInstance, type GatewayOptions, HttpProtocolAdapter, IdGenerator, IsoTimestamp, type ListOptions, Logger, MAX_AUTHORIZATION_HEADER_BYTES, PAYMENT_HEADER, PAYMENT_INPUT_FIELD, PAYMENT_REQUIRED_HEADER, PAYMENT_RESPONSE_HEADER, PaymentAttempt, type PaymentAttemptReservation, type PaymentAttemptUpdate, PaymentMethodName, PaymentProvider, type PaymentRequiredEnvelope, PaymentRequiredOutcome, PaymentSubmission, ProtocolAdapter, ProtocolAdapterContext, RESERVED_INPUT_FIELDS, RETRYABLE_ERROR_CODES, type ReceiptStore, ResourceRegistry, createA2aAdapter, createAcpAdapter, createGateway, createSqliteReceiptStore, extractReservedInputFields, isCommerceError, isPaymentRequiredEnvelope, loadConfig, parseAuthorizationHeader, parseAuthorizationSubmission, parseConfig, createSqliteReceiptStore as receipts, toCommerceError, toDeliverySummary, toErrorEnvelope, toPaymentRequiredEnvelope };