@atumlabs/payment-gateway-client 2.2.0 → 3.0.1

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.
@@ -0,0 +1,2013 @@
1
+ /**
2
+ * The result of a counterparty authorization request. Contains either
3
+ * the PSP's authorization decision (authorized/declined with proof) or
4
+ * an error indicating why authorization could not be completed.
5
+ *
6
+ */
7
+ type AuthorizationResult = {
8
+ /**
9
+ * Correlation key for this authorization
10
+ */
11
+ payment_id: string;
12
+ /**
13
+ * The beneficiary PSP's DID
14
+ */
15
+ counterparty_did: string;
16
+ /**
17
+ * Authorization outcome. "authorized" or "declined" when the PSP responded.
18
+ * "error" or "timeout" when the authorization could not be completed.
19
+ *
20
+ */
21
+ status: 'authorized' | 'declined' | 'error' | 'timeout';
22
+ /**
23
+ * The PSP's raw authorization response (present when status is authorized or declined)
24
+ */
25
+ authorization_response?: {
26
+ [key: string]: unknown;
27
+ };
28
+ /**
29
+ * Machine-readable error code (present when status is error or timeout).
30
+ * Counterparty-sourced codes are derived from the error code the
31
+ * Counterparty Gateway publishes. GATEWAY_TIMEOUT, PROOF_INVALID, and
32
+ * PROOF_STALE are raised by this gateway itself (no counterparty envelope corresponds).
33
+ *
34
+ */
35
+ error_code?: 'COUNTERPARTY_NOT_FOUND' | 'COUNTERPARTY_TIMEOUT' | 'WEBHOOK_ERROR' | 'WEBHOOK_CONNECTION_ERROR' | 'INTERNAL_ERROR' | 'GATEWAY_TIMEOUT' | 'PROOF_INVALID' | 'PROOF_STALE';
36
+ /**
37
+ * Human-readable error description
38
+ */
39
+ error_message?: string;
40
+ /**
41
+ * HTTP status code from the PSP webhook (only for WEBHOOK_ERROR)
42
+ */
43
+ webhook_http_status?: number;
44
+ };
45
+ /**
46
+ * Authorization outcome. "authorized" or "declined" when the PSP responded.
47
+ * "error" or "timeout" when the authorization could not be completed.
48
+ *
49
+ */
50
+ type status = 'authorized' | 'declined' | 'error' | 'timeout';
51
+ /**
52
+ * Machine-readable error code (present when status is error or timeout).
53
+ * Counterparty-sourced codes are derived from the error code the
54
+ * Counterparty Gateway publishes. GATEWAY_TIMEOUT, PROOF_INVALID, and
55
+ * PROOF_STALE are raised by this gateway itself (no counterparty envelope corresponds).
56
+ *
57
+ */
58
+ type error_code = 'COUNTERPARTY_NOT_FOUND' | 'COUNTERPARTY_TIMEOUT' | 'WEBHOOK_ERROR' | 'WEBHOOK_CONNECTION_ERROR' | 'INTERNAL_ERROR' | 'GATEWAY_TIMEOUT' | 'PROOF_INVALID' | 'PROOF_STALE';
59
+ /**
60
+ * Structured payment request with sender authorization and optional W3C Verifiable Credentials
61
+ */
62
+ type PaymentRequest = {
63
+ /**
64
+ * Semver-shaped declaration version (MAJOR.MINOR). The major component is locked to this schema's parent directory (v1 → major must be 1). Producers MUST emit the canonical value exported by the bindings' Version constant; the canonical bumps on each additive minor evolution.
65
+ */
66
+ version: string;
67
+ /**
68
+ * Unique identifier for this payment request (used for idempotency)
69
+ */
70
+ request_id: string;
71
+ source: OwnedAsset;
72
+ /**
73
+ * Array of destination assets for the settlement agent to choose from (at least one required, at most 16).
74
+ * The ceiling bounds the fan-out one request can buy: every consumer iterates this list.
75
+ */
76
+ destination: Array<OwnedAsset>;
77
+ /**
78
+ * The exact amount to be received at the destination (in the smallest unit, e.g., wei for ETH, cents for USD).
79
+ */
80
+ fulfillment_amount: string;
81
+ /**
82
+ * The maximum amount willing to be spent from the source (in the smallest unit).
83
+ */
84
+ max_source_amount?: string;
85
+ /**
86
+ * Required. The deadline for receiving price quotes from settlement providers. After this
87
+ * point no new quotes are accepted. The gateway injects no default and validates the value
88
+ * is in the future. The originator must supply it, and a request that omits it or supplies
89
+ * a past value is rejected with 400.
90
+ */
91
+ quote_deadline: string;
92
+ /**
93
+ * Required. The final deadline for completing the payment. If not completed by this time the
94
+ * payment fails and is eligible for a refund. The gateway injects no default and validates
95
+ * the value is in the future. The originator must supply it, and a request that omits it or
96
+ * supplies a past value is rejected with 400.
97
+ */
98
+ fulfillment_deadline: string;
99
+ /**
100
+ * Policy requirements for settler authentication. Keys are policy names, values indicate if the policy is required.
101
+ */
102
+ settler_auth_required?: {
103
+ [key: string]: (boolean);
104
+ };
105
+ sender_auth: SenderAuth;
106
+ originator_auth?: VerifiableCredentialAuth;
107
+ /**
108
+ * Wallet address or public key of a trusted service that will automatically select
109
+ * the best exchange rate for your payment. Leave empty to use the default selector.
110
+ */
111
+ quote_selector?: string;
112
+ /**
113
+ * Third-party service that will independently verify your payment was delivered.
114
+ * Leave empty to use the default verifier.
115
+ */
116
+ fulfillment_verifier?: {
117
+ /**
118
+ * The wallet address or public key of the verification service
119
+ */
120
+ account: string;
121
+ /**
122
+ * Origin of the fulfillment verifier service, with no path — the caller
123
+ * appends the verifier's own API paths. The gateway's `/v1/defaults` response
124
+ * supplies the default fulfillment verifier for each chain.
125
+ */
126
+ endpoint: string;
127
+ };
128
+ /**
129
+ * Escrow contract address, used to protect source funds until proof of fulfillment has been verified. Leave empty to use the default.
130
+ */
131
+ escrow_contract_address?: string;
132
+ /**
133
+ * Fulfillment Proxy contract address, used to emit proof of fulfillment on the destination chain. Leave empty to use the default.
134
+ */
135
+ fulfillment_proxy?: string;
136
+ /**
137
+ * Optional settler filtering requirements. If whitelist is present, only whitelisted settlers may win. If blacklist is present, blacklisted settlers are excluded. Both can be specified; blacklist takes precedence (a settler in both lists is rejected).
138
+ */
139
+ settler_requirements?: {
140
+ /**
141
+ * List of settler DIDs permitted to fulfill this request. If present and non-empty, only these settlers may win. Use W3C DID format (e.g., did:pkh:eip155:1:0xABC...).
142
+ */
143
+ whitelist?: Array<(string)>;
144
+ /**
145
+ * List of settler DIDs excluded from fulfilling this request. If present and non-empty, these settlers are rejected. Use W3C DID format (e.g., did:pkh:eip155:1:0xABC...).
146
+ */
147
+ blacklist?: Array<(string)>;
148
+ };
149
+ };
150
+ /**
151
+ * Confirmation details after a payment has been successfully delivered.
152
+ * Contains proof of delivery and transaction details for both source and destination chains.
153
+ *
154
+ */
155
+ type FulfillmentConfirmation = {
156
+ /**
157
+ * Unique identifier for this payment transaction.
158
+ * Use this to track the payment across all systems.
159
+ *
160
+ */
161
+ payment_id: string;
162
+ /**
163
+ * Your original request ID that was provided when creating the payment.
164
+ * Helps match confirmations to your internal systems.
165
+ *
166
+ */
167
+ request_id: string;
168
+ /**
169
+ * Timestamp when the fulfillment was completed
170
+ */
171
+ fulfillment_timestamp: string;
172
+ /**
173
+ * The blockchain where funds were locked in escrow, using CAIP-2 format.
174
+ * CAIP-2 is a standard way to identify blockchains: {namespace}:{reference}
175
+ * Examples:
176
+ * - "eip155:1" for Ethereum mainnet
177
+ * - "eip155:42161" for Arbitrum
178
+ * - "solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp" for Solana
179
+ * - "tron:mainnet" for Tron
180
+ *
181
+ */
182
+ source_chain_id: string;
183
+ /**
184
+ * The blockchain where the payment was delivered, using CAIP-2 format.
185
+ * CAIP-2 is a standard way to identify blockchains: {namespace}:{reference}
186
+ * Examples:
187
+ * - "eip155:1" for Ethereum mainnet
188
+ * - "eip155:42161" for Arbitrum
189
+ * - "solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp" for Solana
190
+ * - "tron:mainnet" for Tron
191
+ *
192
+ */
193
+ destination_chain_id: string;
194
+ /**
195
+ * Transaction hash of the escrow reservation on the source chain
196
+ */
197
+ source_tx_hash?: string;
198
+ /**
199
+ * Transaction hash of the fulfillment on the destination chain
200
+ */
201
+ destination_tx_hash?: string;
202
+ /**
203
+ * Block number where the source transaction was confirmed
204
+ */
205
+ source_block_number?: number;
206
+ /**
207
+ * Block number where the destination transaction was confirmed
208
+ */
209
+ destination_block_number?: number;
210
+ };
211
+ /**
212
+ * Represents a cryptocurrency or token in a specific wallet. This tells the system what asset you're sending/receiving and which wallet to use.
213
+ */
214
+ type OwnedAsset = {
215
+ /**
216
+ * A unique identifier for the asset using CAIP-19 format.
217
+ * CAIP-19 is a standard way to identify blockchain assets: {chain_id}/{asset_namespace}:{asset_reference}
218
+ * Examples:
219
+ * - Ethereum USDC: "eip155:1/erc20:0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48"
220
+ * - Arbitrum USDC: "eip155:42161/erc20:0xaf88d065e77c8cC2239327C5EDb3A432268e5831"
221
+ * - Solana USDC: "solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp/token:EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v"
222
+ * - Tron USDT: "tron:mainnet/trc20:TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t"
223
+ */
224
+ asset_identifier: string;
225
+ /**
226
+ * The wallet address that owns this asset.
227
+ * Format depends on the blockchain:
228
+ * - Ethereum/EVM: 0x-prefixed hex address (42 characters)
229
+ * - Solana: Base58 encoded address
230
+ * - Tron: T-prefixed Base58 address
231
+ *
232
+ * A destination account is checked at ingress and must be payable on the chain named by
233
+ * its `asset_identifier`: it parses for that chain, carries a valid EIP-55 checksum when
234
+ * mixed-case, has no surrounding whitespace, and is not the zero address. A receiver that
235
+ * fails any of these is refused with `INVALID_DESTINATION_ACCOUNT`, before any funds move.
236
+ */
237
+ account: string;
238
+ };
239
+ /**
240
+ * Authorization from the asset owner to execute the payment. The exact format depends on the source blockchain's authorization mechanism.
241
+ */
242
+ type SenderAuth = {
243
+ /**
244
+ * DEPRECATED: inner-document credential carrier. Credentials MUST ride ONLY in the holder-signed PaymentRequestEnvelope (PRE); the inner PaymentRequest carries no credential and its Data Integrity signature EXCLUDES this field (stripped before canonicalization on both producer and verifier). Populated only for one back-compat rollout cycle, then removed.
245
+ * @deprecated
246
+ */
247
+ verifiable_credential?: VerifiableCredentialAuth;
248
+ message_scheme: SenderAuthMessageScheme;
249
+ /**
250
+ * Array of signed messages (at least one required)
251
+ */
252
+ signed_messages: Array<SignedMessage>;
253
+ };
254
+ /**
255
+ * The signature method used for authorizing this payment:
256
+ * - `EVM_PERMIT2`: Gasless token approvals for Ethereum/EVM chains
257
+ * - `EVM_PERMIT2_ESCROW`: Gasless approvals with escrow support
258
+ * - `SOLANA`: Standard Solana transaction signatures
259
+ * - `TRON`: Tron transaction signatures
260
+ */
261
+ type SenderAuthMessageScheme = 'EVM_PERMIT2' | 'EVM_PERMIT2_ESCROW' | 'SOLANA' | 'TRON';
262
+ /**
263
+ * A message that has been cryptographically signed to prove authorization. The signature proves you control the wallet that's sending funds.
264
+ */
265
+ type SignedMessage = {
266
+ /**
267
+ * The data that was signed. Format depends on the blockchain:
268
+ * - EVM: Hex-encoded message hash (with 0x prefix)
269
+ * - Solana: Hex-encoded message hash (with 0x prefix)
270
+ * - Tron: Hex-encoded message hash (possibly without 0x prefix)
271
+ */
272
+ message: string;
273
+ /**
274
+ * Optional: If 'message' contains a hash, this field contains the original data before it was hashed. Useful for verification and debugging.
275
+ */
276
+ message_prehash?: string;
277
+ /**
278
+ * The cryptographic signature proving you authorized this message. Hex-encoded with a 0x prefix on every supported chain. The signer's own public key is base58 on Solana, but the signature itself is not.
279
+ */
280
+ signature: string;
281
+ /**
282
+ * Optional chain-specific payload containing additional signing context (e.g., delegate_signer for Solana). Preserved through the pipeline for downstream consumers.
283
+ */
284
+ payload?: {
285
+ [key: string]: unknown;
286
+ };
287
+ };
288
+ /**
289
+ * Optional identity verification using cryptographic credentials.
290
+ *
291
+ * DEPRECATED. Credentials are moving to a holder-signed W3C VerifiablePresentation that
292
+ * travels alongside a request rather than inside it. That envelope is not part of this
293
+ * HTTP contract, so there is nothing here to move them to yet: treat this as a legacy
294
+ * carrier, and do not build a new integration on it.
295
+ */
296
+ type VerifiableCredentialAuth = {
297
+ verifiable_credential: VerifiableCredential;
298
+ /**
299
+ * Reference to verification method from the DID Document
300
+ */
301
+ verification_method_id: string;
302
+ /**
303
+ * Cryptographic signature matching the verification method type
304
+ */
305
+ signature: string;
306
+ };
307
+ /**
308
+ * W3C Verifiable Credential structure conforming to the W3C Verifiable Credentials Data Model v1.1
309
+ */
310
+ type VerifiableCredential = {
311
+ /**
312
+ * JSON-LD context array, must include 'https://www.w3.org/2018/credentials/v1'
313
+ */
314
+ '@context': Array<(string)>;
315
+ /**
316
+ * Unique identifier for this credential
317
+ */
318
+ id: string;
319
+ /**
320
+ * Credential types, must include 'VerifiableCredential'
321
+ */
322
+ type: Array<(string)>;
323
+ /**
324
+ * DID or issuer object of the credential issuer
325
+ */
326
+ issuer: string | {
327
+ [key: string]: unknown;
328
+ };
329
+ /**
330
+ * When the credential was issued
331
+ */
332
+ issuanceDate: string;
333
+ /**
334
+ * When the credential expires
335
+ */
336
+ expirationDate?: string;
337
+ /**
338
+ * Claims about the credential subject (structure varies by issuer)
339
+ */
340
+ credentialSubject: {
341
+ [key: string]: unknown;
342
+ };
343
+ /**
344
+ * Information for credential revocation checking. Not consulted by the verifier today.
345
+ */
346
+ credentialStatus?: {
347
+ [key: string]: unknown;
348
+ };
349
+ /**
350
+ * Cryptographic proof of credential integrity
351
+ */
352
+ proof: {
353
+ [key: string]: unknown;
354
+ };
355
+ };
356
+ /**
357
+ * Where your payment is in its lifecycle. One payment reads the same however you ask
358
+ * about it.
359
+ *
360
+ * - `pending`: accepted and in progress. Nothing has reached the recipient yet.
361
+ * - `finalizing`: the transaction paying your recipient is on chain and is accruing
362
+ * the confirmations its chain requires. NOT FINAL, see below.
363
+ * - `completed`: delivered, with the required confirmations behind it.
364
+ * - `failed`: did not complete. Any funds held in escrow are returned, and `error`
365
+ * describes what went wrong.
366
+ *
367
+ * `completed` and `failed` are final and will not change afterwards. `pending` and
368
+ * `finalizing` will.
369
+ *
370
+ * **Do not treat `finalizing` as delivered.** It says the payment has been made on
371
+ * chain but is not yet irreversible, much as a card authorization is not yet a
372
+ * settlement. It normally becomes `completed`, and it can still become `failed` if
373
+ * the transaction never reaches the confirmation depth its chain requires. Acting on
374
+ * `finalizing` — releasing goods, crediting an account — means accepting that risk
375
+ * deliberately, at whatever threshold suits you rather than the one we wait for.
376
+ *
377
+ * `finalizing` is about paying the recipient. While your own funds are still being
378
+ * committed on the source chain the payment is `pending`, because nothing has reached
379
+ * the recipient yet.
380
+ *
381
+ */
382
+ type PaymentStatus = 'pending' | 'finalizing' | 'completed' | 'failed';
383
+ /**
384
+ * One on-chain transaction belonging to a payment: which chain, which transaction, and
385
+ * which block it landed in.
386
+ *
387
+ * Whether the payment has actually happened is answered by `status`, not here. Read this
388
+ * to look the transaction up on chain and to verify it yourself.
389
+ *
390
+ */
391
+ type PaymentTransaction = {
392
+ /**
393
+ * The transaction's hash on its chain. Hex hashes carry the `0x` prefix, including on
394
+ * Tron, whose own tooling omits it.
395
+ *
396
+ */
397
+ transaction_hash: string;
398
+ /**
399
+ * CAIP-2 identifier of the chain the transaction is on.
400
+ */
401
+ chain_id: string;
402
+ /**
403
+ * The block the transaction landed in. Absent until it has been mined.
404
+ *
405
+ * Provisional while `status` is `finalizing`: on a chain that settles against another,
406
+ * a reorganization there can move the transaction to a different block. Settled once
407
+ * `status` is `completed` — keep it as a final record only from then.
408
+ *
409
+ */
410
+ block_number?: number;
411
+ };
412
+ /**
413
+ * The transactions a payment has produced, one entry per stage, added as each becomes
414
+ * known. A stage absent here has produced no transaction yet.
415
+ *
416
+ * These are the two movements that decide whether your payment happened: your funds
417
+ * being committed, and your recipient being paid. Present on every outcome, so a
418
+ * payment that did not complete can still be traced on chain.
419
+ * `fulfillment_confirmation` is not a substitute: it is written only once a payment
420
+ * completes, and describes the finished delivery rather than progress towards it.
421
+ *
422
+ * Where a stage is attempted more than once, the entry describes the attempt that
423
+ * counts — the one that succeeded, or the last one if none did.
424
+ *
425
+ */
426
+ type PaymentTransactions = {
427
+ /**
428
+ * Committing your funds on the source chain.
429
+ */
430
+ deposit?: PaymentTransaction;
431
+ /**
432
+ * Paying your recipient on the destination chain.
433
+ */
434
+ fulfillment?: PaymentTransaction;
435
+ };
436
+ /**
437
+ * Response from submitting a payment request. If settlement completes inside the
438
+ * gateway's synchronous window, the response includes a fulfillment_confirmation with
439
+ * full settlement details. Otherwise you receive a payment_id plus the payment's
440
+ * current `status`, and can poll /v1/payments/{paymentId}/status for updates.
441
+ *
442
+ * Read `status` before deciding what to do next: a `pending` or `finalizing` payment is
443
+ * in flight and must NOT be re-submitted under a new request_id (that would be a second
444
+ * payment), whereas a `failed` one is terminal — re-submitting it under the SAME
445
+ * request_id resolves to the same terminal payment, so a genuine re-attempt needs a
446
+ * new request_id.
447
+ *
448
+ * **A synchronously-completed payment carries proof of QUOTE as well as of delivery.** When
449
+ * settlement lands inside the window you get `status: completed`, a full
450
+ * `fulfillment_confirmation`, and — since a quote necessarily was awarded to get there —
451
+ * `quote_id` and `fulfillment_quote`. The fast path therefore needs no follow-up call to
452
+ * verify: recompute `quote_hash` over the returned quote and compare it against the on-chain
453
+ * commitment from this response alone.
454
+ *
455
+ * `status` is present on every response. `completed` is always accompanied by
456
+ * fulfillment_confirmation; `failed` is accompanied by `error` where a reason has been
457
+ * recorded.
458
+ *
459
+ */
460
+ type PaymentResponse = {
461
+ /**
462
+ * Unique ID for tracking this payment. Save this to check status later.
463
+ *
464
+ */
465
+ payment_id: string;
466
+ status: PaymentStatus;
467
+ transactions?: PaymentTransactions;
468
+ /**
469
+ * Whether this response describes a payment that already existed, rather than one
470
+ * created by this request. `true` means the request_id had been used before and you
471
+ * are being handed the ORIGINAL payment — no second payment was created and nothing
472
+ * additional was charged.
473
+ *
474
+ * **Re-attempting a payment.** Re-submit the same request and you get the same payment
475
+ * back. You may re-send the original bytes unchanged: the deadlines will have expired by
476
+ * then — `quote_deadline` bounds the auction and is short, while this endpoint may hold a
477
+ * submission for up to 30 seconds — and an expired deadline on a re-submission is not an
478
+ * error, because the request is resolved onto the payment that already exists rather than
479
+ * used to create one.
480
+ *
481
+ * Re-signing with fresh deadlines is equally fine and returns the same payment. What you
482
+ * must NOT change is the request_id, and what you must not change under it is the
483
+ * payment's economics — source, destination, fulfillment_amount, max_source_amount — which
484
+ * are rejected with 409 IDEMPOTENCY_TERMS_MISMATCH. Deadlines and the signature are
485
+ * exempt precisely so that a re-attempt is possible.
486
+ *
487
+ * A genuinely new payment needs a NEW request_id. In particular a `failed` payment is
488
+ * terminal: re-submitting its request_id keeps returning that dead payment, so recovering
489
+ * means starting a new one under a new key.
490
+ *
491
+ * Present on every response, `false` for a newly created payment. A response without
492
+ * the field is from a gateway predating it, not a newly created payment.
493
+ *
494
+ * This is the field to read when reconciling a suspected double charge: two
495
+ * submissions where the second reports `true` are one payment, whereas two both
496
+ * reporting `false` are two. It says nothing about how far the payment has got —
497
+ * read `status` for that.
498
+ *
499
+ */
500
+ idempotent_replay: boolean;
501
+ /**
502
+ * The winning quote's ID. Present when `status` is `completed` — a payment cannot settle
503
+ * without an award — and absent on a `pending` response, where no quote has been selected
504
+ * yet. Same value and meaning as on GET /v1/payments/{paymentId}/status.
505
+ *
506
+ */
507
+ quote_id?: string;
508
+ /**
509
+ * The settler-signed FulfillmentQuote for the winning quote, returned verbatim as an
510
+ * opaque signed document — the PREIMAGE of the `quote_hash` committed on-chain. Same
511
+ * value, semantics and canonicalization caveats as on
512
+ * GET /v1/payments/{paymentId}/status; see that field for how to verify it.
513
+ *
514
+ * Present when `status` is `completed`. It may be absent even then, if the stored quote
515
+ * is unreadable: the award is reported through `quote_id` regardless, so a present
516
+ * `quote_id` with no `fulfillment_quote` means "verification preimage unavailable" and
517
+ * never "no quote was awarded". A consumer that requires the preimage should fall back to
518
+ * the status endpoint rather than treat the payment as unverified.
519
+ *
520
+ */
521
+ fulfillment_quote?: {
522
+ [key: string]: unknown;
523
+ };
524
+ fulfillment_confirmation?: FulfillmentConfirmation;
525
+ error?: PaymentFailure;
526
+ };
527
+ type GetPaymentStatusResponse = {
528
+ /**
529
+ * The payment ID you're checking status for.
530
+ *
531
+ */
532
+ payment_id?: string;
533
+ status?: PaymentStatus;
534
+ transactions?: PaymentTransactions;
535
+ /**
536
+ * When the status was last updated
537
+ */
538
+ updated_at?: string;
539
+ /**
540
+ * The winning quote's ID. Present once a quote has been awarded for this payment;
541
+ * absent while the payment is still collecting or awarding. Cross-references the
542
+ * `quote_id` returned by GET /v1/payments/quote-requests/{quoteRequestId}.
543
+ *
544
+ */
545
+ quote_id?: string;
546
+ /**
547
+ * The settler-signed FulfillmentQuote for the winning quote, returned verbatim as an
548
+ * opaque signed document (structurally the canonical FulfillmentQuote/v1 declaration at
549
+ * https://schemas.atum.xyz/declarations/FulfillmentQuote/v1). Present once a quote has
550
+ * been awarded — including after the payment completes and `fulfillment_confirmation` is
551
+ * populated, since that is precisely when a consumer verifies.
552
+ *
553
+ * This is the PREIMAGE of the `quote_hash` committed on-chain in the escrow deposit and
554
+ * reserve witnesses. On-chain we commit only the hash, so a quote-selector consumer
555
+ * recomputes quote_hash over these bytes and compares it against the on-chain commitment
556
+ * to confirm the payment settled against the quote it selected ("trust but verify"), and
557
+ * verifies the settler signature over the same bytes.
558
+ *
559
+ * quote_hash is canonicalization-based (URDNA2015), so it is stable across JSON
560
+ * key-order/whitespace normalization and across JSON string-escaping differences. The
561
+ * returned bytes are hash-equivalent to, but not necessarily byte-identical with, what
562
+ * the settler emitted (quotes are stored as JSONB, which normalizes on write). The
563
+ * gateway still never re-serializes the quote through a typed struct (that renormalizes
564
+ * timestamp values and WOULD change quote_hash), so the Go binding exposes it as a raw
565
+ * JSON passthrough.
566
+ *
567
+ */
568
+ fulfillment_quote?: {
569
+ [key: string]: unknown;
570
+ };
571
+ fulfillment_confirmation?: FulfillmentConfirmation;
572
+ error?: PaymentFailure;
573
+ /**
574
+ * How many settler agents this payment's auction was broadcast to. Absent means
575
+ * unknown, never zero.
576
+ *
577
+ */
578
+ requested_count?: number;
579
+ /**
580
+ * Why the payment drew few or no quotes. Read from the same settler reports as the
581
+ * quote-request endpoints, keyed by this payment, so a payment that failed on an expired
582
+ * quote deadline can say WHY nobody funded it instead of only that nobody did.
583
+ *
584
+ * Every declining agent is counted exactly once under its most recent reason. Empty means
585
+ * no agent declined against this payment, absent means the breakdown could not be read. A
586
+ * payment awarded out of a quote-request batch was bid on at quote time, so its declines
587
+ * are keyed to that batch and are read from the batch's status endpoint rather than here.
588
+ * As on the quote-request endpoints, the free-form decline detail is never relayed.
589
+ *
590
+ */
591
+ decline_summary?: Array<DeclineSummaryEntry>;
592
+ };
593
+ /**
594
+ * Why a payment failed. Present only when `status` is `failed`, and identical
595
+ * however you ask about the payment.
596
+ *
597
+ * `code` is the stable, machine-readable identity of the failure — branch on it
598
+ * rather than on `message`, which is written for a person and may be reworded.
599
+ * `docs_url` points at the page describing that code.
600
+ *
601
+ */
602
+ type PaymentFailure = {
603
+ /**
604
+ * Public error category in SCREAMING_SNAKE_CASE. Common codes:
605
+ * - `SETTLEMENT_FAILED`: the settlement could not be completed
606
+ * - `NO_QUOTES_RECEIVED`: no quotes arrived within the auction window
607
+ * - `INTERNAL_ERROR`: an unexpected error occurred
608
+ *
609
+ */
610
+ code: string;
611
+ /**
612
+ * Human-readable description of the failure, for a person reading it. Do not
613
+ * branch on this text.
614
+ *
615
+ */
616
+ message: string;
617
+ /**
618
+ * Which part of the system reported the failure.
619
+ *
620
+ */
621
+ domain?: 'PAYMENT_GATEWAY' | 'SETTLER_GATEWAY' | 'SETTLER_AGENT' | 'WALLET_ORCHESTRATION' | 'VERIFICATION_SERVICE' | 'BLOCKCHAIN' | 'EXTERNAL_SERVICE';
622
+ /**
623
+ * Link to the documentation page for this public code.
624
+ */
625
+ docs_url?: string;
626
+ /**
627
+ * What the caller should do next. Absent means the condition has not been classified, which is not the same as safe to retry.
628
+ * Re-sending the same `request_id` is an idempotent replay and always safe. This value is about submitting a new one, which starts a new payment. See https://docs.atum.xyz/errors for the value set.
629
+ */
630
+ retry_classification?: string;
631
+ blockchain_context?: PaymentBlockchainContext;
632
+ };
633
+ /**
634
+ * Which part of the system reported the failure.
635
+ *
636
+ */
637
+ type domain = 'PAYMENT_GATEWAY' | 'SETTLER_GATEWAY' | 'SETTLER_AGENT' | 'WALLET_ORCHESTRATION' | 'VERIFICATION_SERVICE' | 'BLOCKCHAIN' | 'EXTERNAL_SERVICE';
638
+ /**
639
+ * Where on chain a failed payment failed. Present only when the failure happened
640
+ * on chain — an escrow revert, or a fulfillment that could not be delivered — so a
641
+ * payment that failed before any transaction was sent carries no context here.
642
+ */
643
+ type PaymentBlockchainContext = {
644
+ /**
645
+ * CAIP-2 chain identifier
646
+ */
647
+ chain_id?: string;
648
+ /**
649
+ * Failed transaction hash
650
+ */
651
+ transaction_hash?: string;
652
+ /**
653
+ * Block number where error occurred
654
+ */
655
+ block_number?: number;
656
+ /**
657
+ * Contract that caused the error
658
+ */
659
+ contract_address?: string;
660
+ /**
661
+ * Smart contract revert reason
662
+ */
663
+ revert_reason?: string;
664
+ /**
665
+ * Gas consumed before failure
666
+ */
667
+ gas_used?: string;
668
+ /**
669
+ * Estimated gas needed for success
670
+ */
671
+ estimated_gas_needed?: string;
672
+ };
673
+ /**
674
+ * Human-readable payment request parameters for generating an unsigned PaymentRequest.
675
+ * Asset identifiers use a CAIP-19-like format with "/" separator and support friendly names.
676
+ *
677
+ */
678
+ type PreparePaymentRequest = {
679
+ /**
680
+ * Unique identifier for tracking this payment request.
681
+ * Used for idempotency and matching responses to requests.
682
+ *
683
+ */
684
+ request_id: string;
685
+ /**
686
+ * Source asset in human-readable CAIP-19-like format: {chain}/{asset}
687
+ * Supports both friendly names and full CAIP-19 identifiers:
688
+ * - "ethereum/usdc" (friendly names)
689
+ * - "eip155:1/erc20:0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48" (full CAIP-19)
690
+ *
691
+ */
692
+ source_asset: string;
693
+ /**
694
+ * Wallet address that will send the payment
695
+ */
696
+ source_account: string;
697
+ /**
698
+ * Destination asset in human-readable CAIP-19-like format: {chain}/{asset}
699
+ * Supports both friendly names and full CAIP-19 identifiers:
700
+ * - "arbitrum/usdc"
701
+ * - "eip155:42161/erc20:0xaf88d065e77c8cC2239327C5EDb3A432268e5831"
702
+ *
703
+ */
704
+ destination_asset: string;
705
+ /**
706
+ * Wallet address that will receive the payment
707
+ */
708
+ destination_account: string;
709
+ /**
710
+ * Simple amount specification in decimal format (e.g., "1.50" for $1.50 USDC).
711
+ * Use this OR specify both max_source_amount and fulfillment_amount.
712
+ * Cannot be used together with max_source_amount/fulfillment_amount.
713
+ *
714
+ */
715
+ amount?: string;
716
+ /**
717
+ * Maximum amount willing to spend from source (in decimal format).
718
+ * Must be specified together with fulfillment_amount.
719
+ * Cannot be used together with amount field.
720
+ *
721
+ */
722
+ max_source_amount?: string;
723
+ /**
724
+ * Exact amount to be fulfilled at destination (in decimal format).
725
+ * Must be specified together with max_source_amount.
726
+ * Cannot be used together with amount field.
727
+ *
728
+ */
729
+ fulfillment_amount?: string;
730
+ /**
731
+ * Seconds until quote deadline (from now).
732
+ * How long to wait for settlement provider quotes.
733
+ *
734
+ */
735
+ quote_deadline_seconds?: number;
736
+ /**
737
+ * Seconds until fulfillment deadline (from now).
738
+ * Final deadline for completing the payment.
739
+ *
740
+ */
741
+ fulfillment_deadline_seconds?: number;
742
+ };
743
+ /**
744
+ * Complete unsigned PaymentRequest ready for signing.
745
+ * Contains all resolved technical details and typed data ready for signing.
746
+ *
747
+ */
748
+ type PreparePaymentResponse = {
749
+ /**
750
+ * Complete PaymentRequest with signature field set to null.
751
+ * Client should fill in the signature field(s) in
752
+ * sender_auth.signed_messages, either by signing the message_hash
753
+ * field in signed_messages or by using typed data signing on the
754
+ * message_prehash field in signed messages, and then submit the full
755
+ * object to POST /v1/payments.
756
+ *
757
+ */
758
+ payment_request: PaymentRequest;
759
+ };
760
+ type ResolvePaymentResponse = {
761
+ /**
762
+ * The payment ID that corresponds to the given request ID
763
+ */
764
+ payment_id: string;
765
+ };
766
+ /**
767
+ * Step-by-step view of a payment's settlement lifecycle. Includes a route
768
+ * summary, a list of steps with timings, and if the payment failed, a
769
+ * structured error describing where and why.
770
+ *
771
+ */
772
+ type PaymentTimelineResponse = {
773
+ payment_id: string;
774
+ status: PaymentStatus;
775
+ transactions?: PaymentTransactions;
776
+ created_at: string;
777
+ updated_at: string;
778
+ /**
779
+ * Total time from first step to last completed step (only set for terminal states)
780
+ */
781
+ total_duration_ms?: number;
782
+ summary?: PaymentSummary;
783
+ error?: PaymentFailure;
784
+ steps: Array<TimelineStep>;
785
+ };
786
+ /**
787
+ * Top-level context about the payment (parties, assets, amounts)
788
+ */
789
+ type PaymentSummary = {
790
+ /**
791
+ * CAIP-19 identifier of the source asset
792
+ */
793
+ source_asset?: string;
794
+ source_account?: string;
795
+ dest_asset?: string;
796
+ dest_account?: string;
797
+ /**
798
+ * Raw fulfillment amount in smallest token units
799
+ */
800
+ fulfillment_amount?: string;
801
+ /**
802
+ * Human-readable formatted amount with symbol, e.g. "1.00 USDC".
803
+ * Only set when the source asset's decimals are known via the token registry.
804
+ *
805
+ */
806
+ display_amount?: string;
807
+ /**
808
+ * Raw max source amount in smallest token units
809
+ */
810
+ max_source_amount?: string;
811
+ request_id?: string;
812
+ };
813
+ type TimelineStep = {
814
+ /**
815
+ * Internal name of the step (matches settlement event type)
816
+ */
817
+ name: string;
818
+ /**
819
+ * Human-readable label
820
+ */
821
+ label: string;
822
+ /**
823
+ * Current status of this step:
824
+ * - `completed`: Step finished successfully
825
+ * - `in_progress`: Step currently executing
826
+ * - `pending`: Step hasn't started yet
827
+ * - `failed`: Step errored out
828
+ * - `skipped`: Step will never execute because an earlier step failed
829
+ *
830
+ */
831
+ status: 'completed' | 'in_progress' | 'pending' | 'failed' | 'skipped';
832
+ /**
833
+ * When the step completed (if it has)
834
+ */
835
+ timestamp?: string;
836
+ /**
837
+ * Time this step took, measured from the previous step
838
+ */
839
+ duration_ms?: number;
840
+ /**
841
+ * CAIP-2 chain this step happened on (if on-chain)
842
+ */
843
+ chain_id?: string;
844
+ /**
845
+ * Transaction hash associated with this step (if on-chain)
846
+ */
847
+ transaction_hash?: string;
848
+ /**
849
+ * Additional step-specific data (e.g. block_number, settler, reason)
850
+ */
851
+ details?: {
852
+ [key: string]: unknown;
853
+ };
854
+ };
855
+ /**
856
+ * Current status of this step:
857
+ * - `completed`: Step finished successfully
858
+ * - `in_progress`: Step currently executing
859
+ * - `pending`: Step hasn't started yet
860
+ * - `failed`: Step errored out
861
+ * - `skipped`: Step will never execute because an earlier step failed
862
+ *
863
+ */
864
+ type status2 = 'completed' | 'in_progress' | 'pending' | 'failed' | 'skipped';
865
+ /**
866
+ * Safe, outward-facing error. Derived from an internal error through the shared error catalog. The public code identifies the category and the message is a curated, safe description.
867
+ *
868
+ * A panic is caught by shared middleware that responds `{"error": "Internal server error occurred"}` instead, so a 500 is not guaranteed to carry this shape.
869
+ */
870
+ type ErrorResponse = {
871
+ /**
872
+ * Public, machine-readable error category in SCREAMING_SNAKE_CASE.
873
+ */
874
+ code: string;
875
+ /**
876
+ * Curated, safe, human-readable message.
877
+ */
878
+ message: string;
879
+ /**
880
+ * Correlation id to quote to support to locate the internal error record.
881
+ */
882
+ request_id?: string;
883
+ /**
884
+ * The payment this error was raised against. Absent when the error is not about a specific payment.
885
+ */
886
+ payment_id?: string;
887
+ /**
888
+ * Link to the documentation page for this public code.
889
+ */
890
+ docs_url?: string;
891
+ /**
892
+ * Originating service domain.
893
+ */
894
+ domain?: string;
895
+ /**
896
+ * What the caller should do next. Absent means the condition has not been classified, which is not the same as safe to retry.
897
+ * Re-sending the same `request_id` is an idempotent replay and always safe. This value is about submitting a new one, which starts a new operation. See https://docs.atum.xyz/errors for the value set.
898
+ */
899
+ retry_classification?: string;
900
+ };
901
+ /**
902
+ * Request body for opening a quote-request batch. Structurally the existing PaymentRequest
903
+ * with `sender_auth` omitted (the spend authorization is deferred to the award call); see
904
+ * schemas/declarations/PaymentRequest/v1/schema.json.
905
+ *
906
+ */
907
+ type CreateQuoteRequest = {
908
+ /**
909
+ * Semver-shaped declaration version (MAJOR.MINOR), locked to major 1 for v1. Producers emit
910
+ * the canonical value exported by the bindings' Version constant.
911
+ *
912
+ */
913
+ version: string;
914
+ /**
915
+ * Client-supplied idempotency key for this quote-request. The same request_id from the
916
+ * same originator returns the same quote_request_id. Independent of the award-call request_id.
917
+ *
918
+ */
919
+ request_id: string;
920
+ source: OwnedAsset;
921
+ /**
922
+ * Array of destination assets for the settlement agent to choose from (at least one required, at most 16).
923
+ * The ceiling bounds the fan-out one request can buy: every consumer iterates this list.
924
+ *
925
+ */
926
+ destination: Array<OwnedAsset>;
927
+ /**
928
+ * The exact amount to be received at the destination (smallest unit, e.g. wei or cents).
929
+ */
930
+ fulfillment_amount: string;
931
+ /**
932
+ * Optional cap on what the originator is willing to spend from source (smallest unit).
933
+ * Quotes with source_amount above this are filtered. No cap applied if omitted.
934
+ *
935
+ */
936
+ max_source_amount?: string;
937
+ /**
938
+ * Required. End of the collection window. After this point no new quotes are accepted.
939
+ * The gateway injects no default and never mutates the originator-supplied body, so the
940
+ * value is carried through verbatim to the award call. It must be supplied and must be in
941
+ * the future. Must be strictly earlier than fulfillment_deadline.
942
+ *
943
+ */
944
+ quote_deadline: string;
945
+ /**
946
+ * Required. Final deadline for completing the payment. Past it the payment fails and
947
+ * eligible for refund. The gateway injects no default and never mutates the
948
+ * originator-supplied body, so the value is carried through verbatim to the award call. It
949
+ * must be supplied and must be in the future. Must be strictly later than quote_deadline.
950
+ *
951
+ */
952
+ fulfillment_deadline: string;
953
+ /**
954
+ * Policy requirements for settler authentication. Keys are policy names, values indicate if required.
955
+ */
956
+ settler_auth_required?: {
957
+ [key: string]: (boolean);
958
+ };
959
+ originator_auth?: VerifiableCredentialAuth;
960
+ /**
961
+ * Wallet address or public key of a trusted service that auto-selects the best rate.
962
+ * Leave empty to use the default selector.
963
+ *
964
+ */
965
+ quote_selector?: string;
966
+ /**
967
+ * Optional third-party service that independently verifies delivery. Leave empty for the default verifier.
968
+ */
969
+ fulfillment_verifier?: {
970
+ /**
971
+ * The wallet address or public key of the verification service
972
+ */
973
+ account: string;
974
+ /**
975
+ * Origin of the fulfillment verifier service, with no path — the caller
976
+ * appends the verifier's own API paths. The gateway's `/v1/defaults` response
977
+ * supplies the default fulfillment verifier for each chain.
978
+ *
979
+ */
980
+ endpoint: string;
981
+ };
982
+ /**
983
+ * Optional escrow contract address. Leave empty to use the default.
984
+ */
985
+ escrow_contract_address?: string;
986
+ /**
987
+ * Optional fulfillment-proxy contract address on the destination chain. Leave empty to use the default.
988
+ */
989
+ fulfillment_proxy?: string;
990
+ /**
991
+ * Optional settler filtering. If whitelist is present, only whitelisted settlers may win.
992
+ * If blacklist is present, blacklisted settlers are excluded. Both can be specified;
993
+ * blacklist takes precedence (a settler in both is rejected).
994
+ *
995
+ */
996
+ settler_requirements?: {
997
+ /**
998
+ * Settler DIDs permitted to fulfill this request (W3C DID format). If present, only these may win.
999
+ */
1000
+ whitelist?: Array<(string)>;
1001
+ /**
1002
+ * Settler DIDs excluded from fulfilling this request (W3C DID format).
1003
+ */
1004
+ blacklist?: Array<(string)>;
1005
+ };
1006
+ /**
1007
+ * Optional JSON-LD context URLs — present when the originator wraps the request in a W3C
1008
+ * Data Integrity envelope so a downstream verifier can recover the signer identity.
1009
+ *
1010
+ */
1011
+ '@context'?: Array<(string)>;
1012
+ proof?: DataIntegrityProof;
1013
+ /**
1014
+ * Optional document-level W3C Verifiable Credentials (e.g. KnownToAtum about the request producer).
1015
+ */
1016
+ verifiableCredential?: Array<VerifiableCredential>;
1017
+ };
1018
+ /**
1019
+ * W3C Data Integrity proof conforming to the Data Integrity 1.0 specification. Which of jws or proofValue is required depends on the cryptosuite named in type, and that pairing is checked where the proof is verified rather than by this schema, so a document can satisfy the schema and still be refused at verification.
1020
+ */
1021
+ type DataIntegrityProof = {
1022
+ /**
1023
+ * Proof type identifier. ECDSA-secp256k1 (recoverable, EVM-compatible) for did:pkh:eip155:* signers; Ed25519 for did:pkh:solana:* signers.
1024
+ */
1025
+ type: string;
1026
+ /**
1027
+ * ISO 8601 timestamp when the proof was created. Canonicalize the value exactly as it appears in the raw JSON: parsing it into a date-time and re-serializing can change the spelling (Z versus +00:00), and a different spelling canonicalizes to different bytes, so the signature no longer verifies.
1028
+ */
1029
+ created: string;
1030
+ /**
1031
+ * DID URL identifying the verification method, e.g., 'did:pkh:eip155:1:0x...#blockchainAccountId' for ECDSA or 'did:pkh:solana:<chain>:<addr>#SolanaMethod2021' for Ed25519.
1032
+ */
1033
+ verificationMethod: string;
1034
+ /**
1035
+ * Purpose of the proof (e.g., assertionMethod, authentication).
1036
+ */
1037
+ proofPurpose: string;
1038
+ /**
1039
+ * Detached JWS signature in <base64url(header)>..<base64url(sig)> form, header {alg:ES256K-R, b64:false, crit:[b64]}. Required at runtime for EcdsaSecp256k1RecoverySignature2020.
1040
+ */
1041
+ jws?: string;
1042
+ /**
1043
+ * Multibase-encoded raw signature bytes. Required at runtime for Ed25519Signature2020; mutually exclusive with jws in practice.
1044
+ */
1045
+ proofValue?: string;
1046
+ };
1047
+ /**
1048
+ * One collected quote — the content-hash identifier plus the verbatim settler-signed FulfillmentQuote.
1049
+ */
1050
+ type Quote = {
1051
+ /**
1052
+ * Canonical content-hash of the signed quote bytes; identifies the quote server-side at
1053
+ * award time. Provided as a convenience — the gateway re-derives it from
1054
+ * bid_award.fulfillment_quote_json.
1055
+ *
1056
+ */
1057
+ quote_id: string;
1058
+ /**
1059
+ * The settler-signed FulfillmentQuote (structurally the canonical FulfillmentQuote/v1
1060
+ * declaration at https://schemas.atum.xyz/declarations/FulfillmentQuote/v1), returned
1061
+ * verbatim as an opaque signed document. A client recomputes quote_hash over the returned
1062
+ * bytes and verifies the settler signature, then re-embeds them into
1063
+ * bid_award.fulfillment_quote_json at award. quote_hash is canonicalization-based
1064
+ * (URDNA2015), so it is stable across JSON key-order/whitespace normalization. The
1065
+ * returned bytes are hash-equivalent to, but not necessarily byte-identical with, what the
1066
+ * settler emitted (quotes are stored as JSONB, which normalizes on write). The gateway
1067
+ * still never re-serializes the quote through a typed struct (that renormalizes timestamp
1068
+ * values and WOULD change quote_hash), so the Go binding exposes it as a raw JSON passthrough.
1069
+ *
1070
+ */
1071
+ fulfillment_quote: {
1072
+ [key: string]: unknown;
1073
+ };
1074
+ };
1075
+ /**
1076
+ * A collected quote in the status response, annotated with its award linkage.
1077
+ */
1078
+ type AwardedQuote = {
1079
+ quote_id: string;
1080
+ /**
1081
+ * The settler-signed FulfillmentQuote (structurally the canonical FulfillmentQuote/v1
1082
+ * declaration at https://schemas.atum.xyz/declarations/FulfillmentQuote/v1), returned
1083
+ * verbatim as an opaque signed document. A client recomputes quote_hash over the returned
1084
+ * bytes and verifies the settler signature, then re-embeds them into
1085
+ * bid_award.fulfillment_quote_json at award. quote_hash is canonicalization-based
1086
+ * (URDNA2015), so it is stable across JSON key-order/whitespace normalization. The
1087
+ * returned bytes are hash-equivalent to, but not necessarily byte-identical with, what the
1088
+ * settler emitted (quotes are stored as JSONB, which normalizes on write). The gateway
1089
+ * still never re-serializes the quote through a typed struct (that renormalizes timestamp
1090
+ * values and WOULD change quote_hash), so the Go binding exposes it as a raw JSON passthrough.
1091
+ *
1092
+ */
1093
+ fulfillment_quote: {
1094
+ [key: string]: unknown;
1095
+ };
1096
+ /**
1097
+ * payment_id if this quote was awarded; null otherwise. Under MVP single-award, at most
1098
+ * one quote per batch carries a non-null value.
1099
+ *
1100
+ */
1101
+ awarded_payment_id?: string | null;
1102
+ };
1103
+ /**
1104
+ * A (quote_id, payment_id) pair for an awarded quote in a batch.
1105
+ */
1106
+ type AwardedPayment = {
1107
+ quote_id: string;
1108
+ payment_id: string;
1109
+ };
1110
+ /**
1111
+ * Synchronous response to POST /v1/payments/quote-requests. Self-contained — the corridor
1112
+ * fields are echoed at the response root so a drop-recovery client can build the award call
1113
+ * without retaining the original request body.
1114
+ *
1115
+ * The corridor echoed here describes the batch you actually receive. On an idempotent
1116
+ * replay that is the ORIGINAL batch's corridor and window, which may differ from what you
1117
+ * just sent in the ways a retry is allowed to differ (the deadlines, and address casing).
1118
+ *
1119
+ */
1120
+ type QuoteRequestResponse = {
1121
+ /**
1122
+ * Gateway-generated resource ID for the batch, used in subsequent status reads and awards.
1123
+ */
1124
+ quote_request_id: string;
1125
+ /**
1126
+ * Collection-phase outcome of the create call:
1127
+ * - `ready` — collection complete; `quotes` populated. If no settler bid, this is still
1128
+ * `ready` with an empty `quotes` array (a successful "no quotes available" result —
1129
+ * distinct from `expired`, which only applies to collected quotes that later lapse).
1130
+ * - `collecting` — the sync wait cap fired before the quote deadline; poll the status endpoint for quotes.
1131
+ * The `awarded` and `expired` lifecycle states are observed only via the status endpoint, not here.
1132
+ *
1133
+ */
1134
+ status: 'collecting' | 'ready';
1135
+ /**
1136
+ * Whether this response describes a batch that already existed, rather than one opened
1137
+ * by this request. `true` means the `request_id` had been used before and you are being
1138
+ * handed the ORIGINAL batch — no second batch was opened and no second broadcast went
1139
+ * out to settlement agents.
1140
+ *
1141
+ * **Re-attempting a quote-request.** Re-submit the same request and you get the same
1142
+ * batch back. You may re-send the original bytes unchanged: `quote_deadline` bounds the
1143
+ * collection window and is short, so it will usually have expired by the time you
1144
+ * retry, and an expired deadline on a re-submission is not an error — the request is
1145
+ * resolved onto the batch that already exists rather than used to open one.
1146
+ * Re-signing with fresh deadlines is equally fine and returns the same batch.
1147
+ *
1148
+ * The window is NOT extended either way: it belongs to the batch, and `quote_deadline`
1149
+ * in this response is the batch's own. Read `status` to see whether collection is
1150
+ * still running.
1151
+ *
1152
+ * What you must not change under one `request_id` is the corridor's economics —
1153
+ * accounts, assets, or amounts — which are rejected with 409
1154
+ * IDEMPOTENCY_TERMS_MISMATCH rather than resolved onto the first batch. A genuinely
1155
+ * different corridor needs a new `request_id`.
1156
+ *
1157
+ * Present on every response, `false` for a newly opened batch. A response without the
1158
+ * field is from a gateway predating it, not a newly opened batch.
1159
+ *
1160
+ */
1161
+ idempotent_replay: boolean;
1162
+ source?: OwnedAsset;
1163
+ destination?: Array<OwnedAsset>;
1164
+ fulfillment_amount?: string;
1165
+ max_source_amount?: string;
1166
+ fulfillment_deadline?: string;
1167
+ quote_deadline?: string;
1168
+ /**
1169
+ * Collected quotes. Present when status is `ready` — an empty array if no settler bid.
1170
+ */
1171
+ quotes?: Array<Quote>;
1172
+ /**
1173
+ * How many agents the request was broadcast to, so silence is distinguishable from a
1174
+ * decline without a second call. Same meaning and same absence rule as on the status
1175
+ * endpoint: absent means unknown, never zero.
1176
+ *
1177
+ */
1178
+ requested_count?: number;
1179
+ /**
1180
+ * Why the request drew few or no quotes, carried here so that a `ready` response with an
1181
+ * empty `quotes` array explains itself rather than requiring a follow-up read.
1182
+ *
1183
+ * Same counting rules as the status endpoint: every declining agent counted exactly once
1184
+ * under its most recent reason, empty when nobody declined, absent when the detail could not
1185
+ * be read. Provisional while `status` is `collecting`, because agents are still responding.
1186
+ *
1187
+ */
1188
+ decline_summary?: Array<DeclineSummaryEntry>;
1189
+ };
1190
+ /**
1191
+ * Collection-phase outcome of the create call:
1192
+ * - `ready` — collection complete; `quotes` populated. If no settler bid, this is still
1193
+ * `ready` with an empty `quotes` array (a successful "no quotes available" result —
1194
+ * distinct from `expired`, which only applies to collected quotes that later lapse).
1195
+ * - `collecting` — the sync wait cap fired before the quote deadline; poll the status endpoint for quotes.
1196
+ * The `awarded` and `expired` lifecycle states are observed only via the status endpoint, not here.
1197
+ *
1198
+ */
1199
+ type status3 = 'collecting' | 'ready';
1200
+ /**
1201
+ * Asynchronous (202) response to POST /v1/payments/quote-requests. Returns the batch handle
1202
+ * plus the echoed corridor; quotes are retrieved via the status endpoint.
1203
+ *
1204
+ * The corridor echoed here describes the batch you actually receive. On an idempotent
1205
+ * replay that is the ORIGINAL batch's corridor and window, which may differ from what you
1206
+ * just sent in the ways a retry is allowed to differ (the deadlines, and address casing).
1207
+ *
1208
+ */
1209
+ type QuoteRequestAccepted = {
1210
+ quote_request_id: string;
1211
+ /**
1212
+ * Always `collecting` — a constant on this response, not a report of the batch's state.
1213
+ * On an idempotent replay the batch's window may already have closed; read
1214
+ * GET /v1/payments/quote-requests/{quoteRequestId} for its actual state.
1215
+ *
1216
+ */
1217
+ status: 'collecting';
1218
+ /**
1219
+ * Whether this response describes a batch that already existed, rather than one opened
1220
+ * by this request. `true` means the `request_id` had been used before and you are being
1221
+ * handed the ORIGINAL batch — no second batch was opened and no second broadcast went
1222
+ * out to settlement agents.
1223
+ *
1224
+ * The idempotency contract is the same as on the synchronous (200) response: a
1225
+ * re-submission may carry expired deadlines and is resolved onto the existing batch
1226
+ * rather than rejected, the collection window is the batch's own and is not extended,
1227
+ * and differing economics are rejected with 409 IDEMPOTENCY_TERMS_MISMATCH rather than
1228
+ * collapsed onto the first batch.
1229
+ *
1230
+ * Present on every response, `false` for a newly opened batch. A response without the
1231
+ * field is from a gateway predating it, not a newly opened batch.
1232
+ *
1233
+ */
1234
+ idempotent_replay: boolean;
1235
+ source?: OwnedAsset;
1236
+ destination?: Array<OwnedAsset>;
1237
+ fulfillment_amount?: string;
1238
+ max_source_amount?: string;
1239
+ fulfillment_deadline?: string;
1240
+ quote_deadline?: string;
1241
+ };
1242
+ /**
1243
+ * Always `collecting` — a constant on this response, not a report of the batch's state.
1244
+ * On an idempotent replay the batch's window may already have closed; read
1245
+ * GET /v1/payments/quote-requests/{quoteRequestId} for its actual state.
1246
+ *
1247
+ */
1248
+ type status4 = 'collecting';
1249
+ /**
1250
+ * Response to GET /v1/payments/quote-requests/{quoteRequestId}. The `status` enum describes
1251
+ * the quote-request batch lifecycle and is disjoint from the payment-status enum.
1252
+ *
1253
+ */
1254
+ type QuoteRequestStatusResponse = {
1255
+ quote_request_id: string;
1256
+ /**
1257
+ * Derived batch lifecycle, computed at read time (not a stored state machine). Disjoint
1258
+ * from the payment-status enum returned by the award and payment-status endpoints.
1259
+ * - `collecting` — collection window still open; `quotes` lists those collected so far
1260
+ * (a quote is awardable from arrival, by its own `award_deadline`; more may arrive until
1261
+ * `collection_close`).
1262
+ * - `ready` — collection complete; none awarded yet; either at least one quote is still
1263
+ * within its `award_deadline`, or no settler bid (empty `quotes` array — the successful
1264
+ * "no quotes available" result).
1265
+ * - `awarded` — a quote produced a payment row; no further awards accepted (MVP).
1266
+ * - `expired` — collection closed, nothing awarded, and every collected quote is now past
1267
+ * its `award_deadline` ("quotes lapsed"). An empty batch is `ready`, not `expired` — the
1268
+ * two are deliberately distinct ("no quotes available" vs "quotes lapsed").
1269
+ *
1270
+ */
1271
+ status: 'collecting' | 'ready' | 'awarded' | 'expired';
1272
+ /**
1273
+ * Collected quotes with award linkage — those collected so far while `collecting`, the full set once the window closes.
1274
+ */
1275
+ quotes?: Array<AwardedQuote>;
1276
+ /**
1277
+ * Flat list of awarded (quote_id, payment_id) pairs. At most one entry under MVP single-award.
1278
+ */
1279
+ payments?: Array<AwardedPayment>;
1280
+ /**
1281
+ * How many agents the request was broadcast to. The only auction count that is not
1282
+ * derivable from the rest of this response:
1283
+ *
1284
+ * - quoted = `quotes` length
1285
+ * - declined = sum of `decline_summary[].count`
1286
+ * - participated = quoted + declined
1287
+ * - silent = `requested_count` - participated
1288
+ *
1289
+ * Silence and a decline are different signals, which is why the denominator is surfaced
1290
+ * rather than left implicit.
1291
+ *
1292
+ * ABSENT when the number is unknown, which happens when the broadcast count was never
1293
+ * recorded or when the auction detail could not be read. Absence means unknown, never zero,
1294
+ * so `silent` is derivable only when this field is present.
1295
+ *
1296
+ */
1297
+ requested_count?: number;
1298
+ /**
1299
+ * Why the request drew few or no quotes, so a caller can tell "nobody can fund this right
1300
+ * now" from "my request was malformed".
1301
+ *
1302
+ * EXHAUSTIVE over agents: every agent that declined is counted exactly once, under its most
1303
+ * recent reason, so the counts sum to the number of agents that declined. An agent that
1304
+ * declined more than once with different reasons is counted once, not once per reason.
1305
+ *
1306
+ * Empty means nobody declined. ABSENT means the auction detail could not be read, so the
1307
+ * breakdown is unknown. While `status` is `collecting` it is provisional, because agents are
1308
+ * still responding.
1309
+ *
1310
+ * The free-form decline detail is never relayed, because that detail carries an agent's
1311
+ * balances and would let a caller map inventory by polling cheap quote-requests across
1312
+ * corridors.
1313
+ *
1314
+ */
1315
+ decline_summary?: Array<DeclineSummaryEntry>;
1316
+ };
1317
+ /**
1318
+ * Derived batch lifecycle, computed at read time (not a stored state machine). Disjoint
1319
+ * from the payment-status enum returned by the award and payment-status endpoints.
1320
+ * - `collecting` — collection window still open; `quotes` lists those collected so far
1321
+ * (a quote is awardable from arrival, by its own `award_deadline`; more may arrive until
1322
+ * `collection_close`).
1323
+ * - `ready` — collection complete; none awarded yet; either at least one quote is still
1324
+ * within its `award_deadline`, or no settler bid (empty `quotes` array — the successful
1325
+ * "no quotes available" result).
1326
+ * - `awarded` — a quote produced a payment row; no further awards accepted (MVP).
1327
+ * - `expired` — collection closed, nothing awarded, and every collected quote is now past
1328
+ * its `award_deadline` ("quotes lapsed"). An empty batch is `ready`, not `expired` — the
1329
+ * two are deliberately distinct ("no quotes available" vs "quotes lapsed").
1330
+ *
1331
+ */
1332
+ type status5 = 'collecting' | 'ready' | 'awarded' | 'expired';
1333
+ type DeclineSummaryEntry = {
1334
+ reason: DeclineReason;
1335
+ /**
1336
+ * Agents whose most recent decline reason was this one. Counts agents, never rows, and an
1337
+ * agent appears under one reason only.
1338
+ *
1339
+ */
1340
+ count: number;
1341
+ /**
1342
+ * What would have to change for a settler giving this reason to submit a price quote,
1343
+ * drawn from the same closed set as the `retry_classification` on an error response so
1344
+ * a caller reads one vocabulary.
1345
+ *
1346
+ * It describes the decline only. The authoritative instruction for the payment is the
1347
+ * `retry_classification` on its own error response: a payment can fail for a reason no
1348
+ * settler named, and it can succeed while some settlers declined.
1349
+ *
1350
+ * Optional, and a pattern-constrained string for the same reason `DeclineReason` is.
1351
+ *
1352
+ */
1353
+ retry_classification?: string;
1354
+ /**
1355
+ * Link to the documentation for this reason. Absent rather than empty when no page is
1356
+ * published, so a reader never follows a link to the site root.
1357
+ *
1358
+ */
1359
+ docs_url?: string;
1360
+ };
1361
+ /**
1362
+ * A settler's reason for not bidding, projected from its internal reason code through
1363
+ * the shared decline catalog (`apis/decline/v1/catalog.json`), which is the single
1364
+ * source of truth for the reason set. Several internal codes may map to one public
1365
+ * reason.
1366
+ *
1367
+ * Deliberately a pattern-constrained string rather than a closed enum. The set grows
1368
+ * whenever a settler gains a cause worth naming, and a consumer whose generated client
1369
+ * closes the set rejects the whole response on a value it has not seen. Treat an
1370
+ * unrecognised value as `OTHER`.
1371
+ *
1372
+ * `OTHER` covers a reason whose detail is settler-authored free text, and any reason
1373
+ * this gateway does not recognise. Both are counted so the summary stays exhaustive,
1374
+ * without relaying text we neither author nor validate.
1375
+ *
1376
+ */
1377
+ type DeclineReason = string;
1378
+ /**
1379
+ * Request body for POST /v1/payments/awards. Carries the two originator-signed artifacts:
1380
+ * `sender_auth` (Permit2 deposit authorization) and a fully-formed `bid_award` declaration.
1381
+ * The awarded quote is derived server-side from bid_award.fulfillment_quote_json — no
1382
+ * explicit quote_id on the wire.
1383
+ *
1384
+ */
1385
+ type AwardRequest = {
1386
+ /**
1387
+ * Client-supplied idempotency key for this award call. Independent of the quote-request's request_id.
1388
+ */
1389
+ request_id: string;
1390
+ sender_auth: SenderAuth;
1391
+ bid_award: BidAward;
1392
+ };
1393
+ /**
1394
+ * Fully-formed, originator-signed bid award. Mirrors schemas/declarations/BidAward/v1/schema.json.
1395
+ * `authorization` carries the Escrow reserve-witness signature naming the chosen settler;
1396
+ * `fulfillment_quote_json` is the verbatim settler-signed quote string received in the quote
1397
+ * response (carrying the settler's proof).
1398
+ *
1399
+ */
1400
+ type BidAward = {
1401
+ /**
1402
+ * Semver-shaped declaration version (MAJOR.MINOR), locked to major 1 for v1. Producers emit
1403
+ * the canonical value exported by the bindings' Version constant.
1404
+ *
1405
+ */
1406
+ version: string;
1407
+ authorization: SignedMessage;
1408
+ /**
1409
+ * The settler-signed FulfillmentQuote received in the quote response, forwarded verbatim.
1410
+ * Verification is canonicalization-based — the settler's W3C Data Integrity proof is checked
1411
+ * over the canonicalized form, and `quote_id` is derived as the canonical content-hash — so a
1412
+ * JSON decode/re-encode that only changes key order or whitespace does not invalidate it.
1413
+ * Clients SHOULD still forward the received bytes as-is rather than rebuild the object; the
1414
+ * SDK helpers do this and also expose settler-proof verification.
1415
+ *
1416
+ */
1417
+ fulfillment_quote_json: string;
1418
+ /**
1419
+ * Optional JSON-LD context URLs when the award is wrapped in a W3C Data Integrity envelope.
1420
+ */
1421
+ '@context'?: Array<(string)>;
1422
+ proof?: DataIntegrityProof;
1423
+ /**
1424
+ * Optional W3C Verifiable Credentials attesting the award producer.
1425
+ */
1426
+ verifiableCredential?: Array<VerifiableCredential>;
1427
+ };
1428
+ /**
1429
+ * Synchronous response to POST /v1/payments/awards. The `status` field describes the payment
1430
+ * lifecycle. Note there are two distinct status surfaces for a Quote-API payment, with
1431
+ * different vocabularies: (1) this award response (`awarding`/`completed`/…), and
1432
+ * (2) the separate GET /v1/payments/{paymentId}/status endpoint you poll afterward, which
1433
+ * reports the same payment under its own values (an in-progress payment reads as `pending`
1434
+ * there). Both are disjoint from the quote-request batch status on the quote-request endpoints.
1435
+ *
1436
+ */
1437
+ type AwardResponse = {
1438
+ payment_id: string;
1439
+ /**
1440
+ * Payment lifecycle status on the award response:
1441
+ * - `completed` — settlement finished within the sync wait (includes fulfillment_confirmation).
1442
+ * - `awarding` — settlement still in progress when the sync cap fired (or on wait=false);
1443
+ * poll GET /v1/payments/{paymentId}/status.
1444
+ * - `failed` — settlement reached a terminal failure (e.g. the settler could not fulfill, or
1445
+ * an on-chain step was rejected).
1446
+ * - `cancelled` — the payment was terminated before settlement completed and will not proceed.
1447
+ * `failed` and `cancelled` are terminal states surfaced here only when they occur within the
1448
+ * sync wait; otherwise the response is `awarding` and the terminal state is read from the
1449
+ * payment-status endpoint.
1450
+ *
1451
+ */
1452
+ status: 'awarding' | 'completed' | 'failed' | 'cancelled';
1453
+ fulfillment_confirmation?: FulfillmentConfirmation;
1454
+ };
1455
+ /**
1456
+ * Payment lifecycle status on the award response:
1457
+ * - `completed` — settlement finished within the sync wait (includes fulfillment_confirmation).
1458
+ * - `awarding` — settlement still in progress when the sync cap fired (or on wait=false);
1459
+ * poll GET /v1/payments/{paymentId}/status.
1460
+ * - `failed` — settlement reached a terminal failure (e.g. the settler could not fulfill, or
1461
+ * an on-chain step was rejected).
1462
+ * - `cancelled` — the payment was terminated before settlement completed and will not proceed.
1463
+ * `failed` and `cancelled` are terminal states surfaced here only when they occur within the
1464
+ * sync wait; otherwise the response is `awarding` and the terminal state is read from the
1465
+ * payment-status endpoint.
1466
+ *
1467
+ */
1468
+ type status6 = 'awarding' | 'completed' | 'failed' | 'cancelled';
1469
+ /**
1470
+ * Asynchronous (202) response to POST /v1/payments/awards — just the payment handle.
1471
+ */
1472
+ type AwardAccepted = {
1473
+ payment_id: string;
1474
+ /**
1475
+ * Always `awarding` — settlement is in progress server-side.
1476
+ */
1477
+ status: 'awarding';
1478
+ };
1479
+ /**
1480
+ * Always `awarding` — settlement is in progress server-side.
1481
+ */
1482
+ type status7 = 'awarding';
1483
+ /**
1484
+ * The addresses for one chain. Optional fields appear only where they apply to that
1485
+ * chain; an absent optional field is not an error.
1486
+ *
1487
+ */
1488
+ type ChainDefaults = {
1489
+ /**
1490
+ * CAIP-2 identifier of the chain these defaults describe, normalised to lower case.
1491
+ */
1492
+ chain_id: string;
1493
+ /**
1494
+ * The account named as the reserver in the deposit authorization. Sign against this exact value; a deposit reserved by anyone else is rejected.
1495
+ */
1496
+ quote_selector: string;
1497
+ /**
1498
+ * The escrow the deposit is made into, and the spender of the token approval. Empty when the chain is not fully configured.
1499
+ */
1500
+ escrow_contract: string;
1501
+ /**
1502
+ * The contract that pays the receiver. Read this from the DESTINATION chain's defaults, not the source chain's. Empty when the chain is not fully configured.
1503
+ */
1504
+ fulfillment_proxy: string;
1505
+ /**
1506
+ * The service that attests settlement, and the account it signs with.
1507
+ */
1508
+ fulfillment_verifier: {
1509
+ /**
1510
+ * The account named as the releaser in the deposit authorization. Sign against this exact value.
1511
+ */
1512
+ account: string;
1513
+ /**
1514
+ * Base URL of the fulfillment verifier serving this chain.
1515
+ */
1516
+ endpoint: string;
1517
+ };
1518
+ /**
1519
+ * The Permit2 this chain's escrow verifies against, sent only when it is not the canonical deployment. When absent, use the canonical Permit2 address for the chain. EVM and Tron only.
1520
+ */
1521
+ permit2_contract?: string;
1522
+ /**
1523
+ * Which deposit witness this chain's escrow expects. `4` and above select the four-member witness, `3` the two-member one; absent means four. EVM and Tron only - on Solana this is carried by `svm_signature_domain_version`.
1524
+ */
1525
+ deposit_witness_version?: number;
1526
+ /**
1527
+ * Tokens this chain's escrow accepts for deposit. Absent when the gateway has no listing for the chain, which does not mean no token is accepted.
1528
+ */
1529
+ tokens?: Array<{
1530
+ symbol: string;
1531
+ /**
1532
+ * Token contract address, in the chain's native address format.
1533
+ */
1534
+ address: string;
1535
+ /**
1536
+ * Decimal places, for converting a human amount to base units.
1537
+ */
1538
+ decimals: number;
1539
+ }>;
1540
+ /**
1541
+ * Solana only. The cluster the escrow's signing domain is bound to, needed to build the deposit hash. Absent for EVM and Tron.
1542
+ */
1543
+ svm_signature_cluster_id?: string;
1544
+ /**
1545
+ * Solana only. Version of the escrow's signing domain. Absent for EVM and Tron.
1546
+ */
1547
+ svm_signature_domain_version?: number;
1548
+ };
1549
+ /**
1550
+ * Either one chain's defaults or every chain keyed by CAIP-2 chain id, depending on whether `chain_id` was supplied. A top-level `chain_id` identifies the first.
1551
+ */
1552
+ type GetDefaultsResult = ChainDefaults | ChainDefaultsByChain;
1553
+ /**
1554
+ * Defaults for every chain the gateway serves, keyed by CAIP-2 chain id. Each key repeats the `chain_id` of the value it maps to.
1555
+ */
1556
+ type ChainDefaultsByChain = {
1557
+ [key: string]: ChainDefaults;
1558
+ };
1559
+ type SubmitPaymentData = {
1560
+ requestBody: PaymentRequest;
1561
+ };
1562
+ type SubmitPaymentResponse = PaymentResponse;
1563
+ type GetPaymentStatusData = {
1564
+ /**
1565
+ * The ID of the payment to query
1566
+ */
1567
+ paymentId: string;
1568
+ };
1569
+ type GetPaymentStatusResponse2 = GetPaymentStatusResponse;
1570
+ type ResolvePaymentData = {
1571
+ /**
1572
+ * The client-supplied request ID embedded in the payment request
1573
+ */
1574
+ requestId: string;
1575
+ };
1576
+ type ResolvePaymentResponse2 = ResolvePaymentResponse;
1577
+ type GetPaymentTimelineData = {
1578
+ /**
1579
+ * The ID of the payment to query
1580
+ */
1581
+ paymentId: string;
1582
+ };
1583
+ type GetPaymentTimelineResponse = PaymentTimelineResponse;
1584
+ type PreparePaymentData = {
1585
+ requestBody: PreparePaymentRequest;
1586
+ };
1587
+ type PreparePaymentResponse2 = PreparePaymentResponse;
1588
+ type AuthorizePaymentData = {
1589
+ requestBody: PaymentRequest;
1590
+ };
1591
+ type AuthorizePaymentResponse = AuthorizationResult;
1592
+ type CreateQuoteRequestData = {
1593
+ requestBody: CreateQuoteRequest;
1594
+ /**
1595
+ * Return a handle immediately (`false`, default) or hold the connection for collected quotes (`true`).
1596
+ */
1597
+ wait?: boolean;
1598
+ };
1599
+ type CreateQuoteRequestResponse = QuoteRequestResponse | QuoteRequestAccepted;
1600
+ type GetQuoteRequestStatusData = {
1601
+ /**
1602
+ * The ID of the quote-request batch to query
1603
+ */
1604
+ quoteRequestId: string;
1605
+ };
1606
+ type GetQuoteRequestStatusResponse = QuoteRequestStatusResponse;
1607
+ type AwardQuoteData = {
1608
+ requestBody: AwardRequest;
1609
+ /**
1610
+ * Return a handle immediately (`false`, default) or hold the connection for the payment result (`true`).
1611
+ */
1612
+ wait?: boolean;
1613
+ };
1614
+ type AwardQuoteResponse = AwardResponse | AwardAccepted;
1615
+ type GetDefaultsData = {
1616
+ /**
1617
+ * CAIP-2 chain identifier. Omit it, or send it empty, to receive every chain the gateway serves, keyed by chain id.
1618
+ */
1619
+ chainId?: string;
1620
+ };
1621
+ type GetDefaultsResponse = GetDefaultsResult;
1622
+ type HealthCheckResponse = {
1623
+ status?: string;
1624
+ };
1625
+ type $OpenApiTs = {
1626
+ '/v1/payments': {
1627
+ post: {
1628
+ req: SubmitPaymentData;
1629
+ res: {
1630
+ /**
1631
+ * Payment request submitted successfully
1632
+ */
1633
+ 200: PaymentResponse;
1634
+ /**
1635
+ * Invalid request
1636
+ */
1637
+ 400: ErrorResponse;
1638
+ /**
1639
+ * Signature or sender authorization could not be verified
1640
+ */
1641
+ 401: ErrorResponse;
1642
+ /**
1643
+ * Payment declined during counterparty authorization
1644
+ */
1645
+ 403: ErrorResponse;
1646
+ /**
1647
+ * The `request_id` has already been used for a payment with different economics
1648
+ * (`IDEMPOTENCY_TERMS_MISMATCH`). Re-submitting one `request_id` is how a retry is
1649
+ * made safe, so it must identify one payment; use a distinct `request_id` per
1650
+ * payment.
1651
+ *
1652
+ */
1653
+ 409: ErrorResponse;
1654
+ /**
1655
+ * Payment request too large to process
1656
+ */
1657
+ 413: ErrorResponse;
1658
+ /**
1659
+ * Internal server error
1660
+ */
1661
+ 500: ErrorResponse;
1662
+ /**
1663
+ * The request was not accepted: a dependency is temporarily unavailable, or this operation is paused (`SERVICE_PAUSED`). Nothing was submitted, so the request is safe to retry.
1664
+ */
1665
+ 503: ErrorResponse;
1666
+ };
1667
+ };
1668
+ };
1669
+ '/v1/payments/{paymentId}/status': {
1670
+ get: {
1671
+ req: GetPaymentStatusData;
1672
+ res: {
1673
+ /**
1674
+ * Payment status retrieved successfully
1675
+ */
1676
+ 200: GetPaymentStatusResponse;
1677
+ /**
1678
+ * Payment not found
1679
+ */
1680
+ 404: ErrorResponse;
1681
+ /**
1682
+ * Internal server error
1683
+ */
1684
+ 500: ErrorResponse;
1685
+ };
1686
+ };
1687
+ };
1688
+ '/v1/payments/resolve': {
1689
+ get: {
1690
+ req: ResolvePaymentData;
1691
+ res: {
1692
+ /**
1693
+ * Payment found
1694
+ */
1695
+ 200: ResolvePaymentResponse;
1696
+ /**
1697
+ * Missing request_id parameter
1698
+ */
1699
+ 400: ErrorResponse;
1700
+ /**
1701
+ * No payment found for the given request ID
1702
+ */
1703
+ 404: ErrorResponse;
1704
+ /**
1705
+ * Internal server error
1706
+ */
1707
+ 500: ErrorResponse;
1708
+ };
1709
+ };
1710
+ };
1711
+ '/v1/payments/{paymentId}/timeline': {
1712
+ get: {
1713
+ req: GetPaymentTimelineData;
1714
+ res: {
1715
+ /**
1716
+ * Timeline retrieved successfully
1717
+ */
1718
+ 200: PaymentTimelineResponse;
1719
+ /**
1720
+ * Payment not found
1721
+ */
1722
+ 404: ErrorResponse;
1723
+ /**
1724
+ * Internal server error
1725
+ */
1726
+ 500: ErrorResponse;
1727
+ };
1728
+ };
1729
+ };
1730
+ '/v1/payments/prepare': {
1731
+ post: {
1732
+ req: PreparePaymentData;
1733
+ res: {
1734
+ /**
1735
+ * Payment request prepared successfully
1736
+ */
1737
+ 200: PreparePaymentResponse;
1738
+ /**
1739
+ * Invalid request parameters
1740
+ */
1741
+ 400: ErrorResponse;
1742
+ /**
1743
+ * Endpoint not yet implemented
1744
+ */
1745
+ 501: ErrorResponse;
1746
+ };
1747
+ };
1748
+ };
1749
+ '/v1/payments/authorizations': {
1750
+ post: {
1751
+ req: AuthorizePaymentData;
1752
+ res: {
1753
+ /**
1754
+ * Authorization decision received (authorized or declined)
1755
+ */
1756
+ 200: AuthorizationResult;
1757
+ /**
1758
+ * The request was rejected before authorization was attempted, so no
1759
+ * authorization outcome exists.
1760
+ *
1761
+ */
1762
+ 400: ErrorResponse;
1763
+ /**
1764
+ * The counterparty's proof was rejected (`PROOF_INVALID` or `PROOF_STALE`).
1765
+ * This is an authorization outcome, so the body is an `AuthorizationResult`
1766
+ * with `status: error`.
1767
+ *
1768
+ */
1769
+ 401: AuthorizationResult;
1770
+ /**
1771
+ * Counterparty not found (no registration for the resolved DID). An
1772
+ * authorization outcome, so the body is an `AuthorizationResult` with
1773
+ * `status: error` and `error_code: COUNTERPARTY_NOT_FOUND`.
1774
+ *
1775
+ */
1776
+ 404: AuthorizationResult;
1777
+ /**
1778
+ * Either shape, depending on where the failure happened. A failure before
1779
+ * authorization was attempted returns `ErrorResponse`. A failure carrying an
1780
+ * authorization outcome returns `AuthorizationResult` with `status: error`.
1781
+ *
1782
+ */
1783
+ 500: ErrorResponse | AuthorizationResult;
1784
+ /**
1785
+ * Counterparty webhook error (HTTP error or connection failure). An
1786
+ * authorization outcome, so the body is an `AuthorizationResult` with
1787
+ * `status: error` and `error_code: WEBHOOK_ERROR` or
1788
+ * `WEBHOOK_CONNECTION_ERROR`.
1789
+ *
1790
+ */
1791
+ 502: AuthorizationResult;
1792
+ /**
1793
+ * Authorization timed out (the counterparty did not respond). An
1794
+ * authorization outcome, so the body is an `AuthorizationResult` with
1795
+ * `status: timeout`.
1796
+ *
1797
+ */
1798
+ 504: AuthorizationResult;
1799
+ };
1800
+ };
1801
+ };
1802
+ '/v1/payments/quote-requests': {
1803
+ post: {
1804
+ req: CreateQuoteRequestData;
1805
+ res: {
1806
+ /**
1807
+ * Quote-request resolved synchronously. `status` is `ready` when quotes were collected,
1808
+ * or `collecting` when the sync wait cap fired before the quote deadline.
1809
+ *
1810
+ */
1811
+ 200: QuoteRequestResponse;
1812
+ /**
1813
+ * Quote-request accepted; collection continues asynchronously.
1814
+ */
1815
+ 202: QuoteRequestAccepted;
1816
+ /**
1817
+ * Invalid request. `QUOTE_DEADLINE_NOT_FUTURE` is the one worth planning for: a NEW
1818
+ * quote-request whose `quote_deadline` has already passed is refused, because there is
1819
+ * no window left to collect quotes in. It does not apply to a re-submission — an
1820
+ * already-used `request_id` resolves onto the batch that exists and its expired
1821
+ * deadline is ignored, which is what makes a retry recoverable.
1822
+ *
1823
+ */
1824
+ 400: ErrorResponse;
1825
+ /**
1826
+ * The `request_id` has already been used for a quote-request with different
1827
+ * economics (`IDEMPOTENCY_TERMS_MISMATCH`). Re-submitting one `request_id` is how a
1828
+ * retry is made safe, so it must identify one batch; use a distinct `request_id`
1829
+ * per quote-request.
1830
+ *
1831
+ */
1832
+ 409: ErrorResponse;
1833
+ /**
1834
+ * Internal server error
1835
+ */
1836
+ 500: ErrorResponse;
1837
+ /**
1838
+ * The request was not accepted: a dependency is temporarily unavailable, or this operation is paused (`SERVICE_PAUSED`). Nothing was submitted, so the request is safe to retry.
1839
+ */
1840
+ 503: ErrorResponse;
1841
+ };
1842
+ };
1843
+ };
1844
+ '/v1/payments/quote-requests/{quoteRequestId}': {
1845
+ get: {
1846
+ req: GetQuoteRequestStatusData;
1847
+ res: {
1848
+ /**
1849
+ * Quote-request status retrieved successfully
1850
+ */
1851
+ 200: QuoteRequestStatusResponse;
1852
+ /**
1853
+ * Quote-request not found, or not owned by the caller.
1854
+ */
1855
+ 404: ErrorResponse;
1856
+ /**
1857
+ * Internal server error
1858
+ */
1859
+ 500: ErrorResponse;
1860
+ };
1861
+ };
1862
+ };
1863
+ '/v1/payments/awards': {
1864
+ post: {
1865
+ req: AwardQuoteData;
1866
+ res: {
1867
+ /**
1868
+ * Award resolved synchronously. `status` is `completed` with a fulfillment_confirmation
1869
+ * when settlement finished within the sync wait, or a non-terminal payment status
1870
+ * (e.g. `awarding`) if the cap fired first.
1871
+ *
1872
+ */
1873
+ 200: AwardResponse;
1874
+ /**
1875
+ * Award accepted; settlement continues asynchronously.
1876
+ */
1877
+ 202: AwardAccepted;
1878
+ /**
1879
+ * Invalid request (bad signatures, expired quote, or ownership mismatch)
1880
+ */
1881
+ 400: ErrorResponse;
1882
+ /**
1883
+ * The quote, or another quote in the same batch, has already been awarded
1884
+ * (single-award-per-batch, FR-09).
1885
+ *
1886
+ */
1887
+ 409: ErrorResponse;
1888
+ /**
1889
+ * Internal server error
1890
+ */
1891
+ 500: ErrorResponse;
1892
+ };
1893
+ };
1894
+ };
1895
+ '/v1/defaults': {
1896
+ get: {
1897
+ req: GetDefaultsData;
1898
+ res: {
1899
+ /**
1900
+ * Chain defaults. A single object when `chain_id` was supplied, otherwise an object keyed by CAIP-2 chain id.
1901
+ */
1902
+ 200: GetDefaultsResult;
1903
+ /**
1904
+ * The `chain_id` is not a valid CAIP-2 chain identifier
1905
+ */
1906
+ 400: ErrorResponse;
1907
+ /**
1908
+ * The requested chain is not served by this gateway, or - when `chain_id` was omitted - no chain could be resolved at all
1909
+ */
1910
+ 404: ErrorResponse;
1911
+ /**
1912
+ * A dependency is temporarily unavailable
1913
+ */
1914
+ 503: ErrorResponse;
1915
+ };
1916
+ };
1917
+ };
1918
+ '/health': {
1919
+ get: {
1920
+ res: {
1921
+ /**
1922
+ * Service is healthy
1923
+ */
1924
+ 200: {
1925
+ status?: string;
1926
+ };
1927
+ };
1928
+ };
1929
+ };
1930
+ };
1931
+
1932
+ /** The signed terms a recovered permit carries. */
1933
+ interface AuthTerms {
1934
+ /** Atomic units, decimal string. */
1935
+ amount: string;
1936
+ /** Unix seconds. */
1937
+ deadlineSec: number;
1938
+ }
1939
+ /** The recovered and parsed permit, so a consumer can run its own policy checks. */
1940
+ interface ParsedPermit {
1941
+ scheme: SenderAuthMessageScheme;
1942
+ /** EVM/Tron: permit token; Solana: mint. */
1943
+ token: string;
1944
+ amount: string;
1945
+ deadlineSec: number;
1946
+ reserver: string;
1947
+ releaser: string;
1948
+ /** EVM/Tron only (Permit2 spender). */
1949
+ spender?: string;
1950
+ /** Solana only (the signed depositor). */
1951
+ depositor?: string;
1952
+ /**
1953
+ * The escrow commitments as actually signed. EVM only today: Tron signs the frozen
1954
+ * two-member witness and the Solana prehash has no destination member, so both leave these
1955
+ * undefined. Undefined means "this scheme does not carry the commitment", NOT "the commitment
1956
+ * was absent" — on EVM an absent one is rejected as a malformed prehash and never gets here.
1957
+ */
1958
+ destination?: string;
1959
+ depositRequestHash?: string;
1960
+ }
1961
+ /** One verified `signed_messages[]` entry: the signed terms plus the parsed permit. */
1962
+ interface VerifiedSenderAuth extends AuthTerms {
1963
+ permit: ParsedPermit;
1964
+ }
1965
+ /** What {@link verifyPaymentRequest} returns. */
1966
+ interface VerifyResult {
1967
+ /** One entry per `sender_auth.signed_messages[]`, in order. */
1968
+ results: VerifiedSenderAuth[];
1969
+ /** The `source.account` every signature was verified to recover to. */
1970
+ recoveredAccount: string;
1971
+ }
1972
+ /**
1973
+ * Expectations for {@link verifyPaymentRequest}.
1974
+ *
1975
+ * The first three are what turn this into a check against YOUR terms. Omit them and the token,
1976
+ * network and amount are taken from the request itself, which proves only that the signatures
1977
+ * are self-consistent with fields the request's author controls.
1978
+ */
1979
+ interface VerifyPaymentRequestExpectations {
1980
+ /** Authoritative source-asset address (bare token, no CAIP prefix). */
1981
+ sourceAsset?: string;
1982
+ /** Authoritative CAIP-2 network. Parsed from the request when omitted. */
1983
+ network?: string;
1984
+ /** Authoritative max source amount to bind the permit amount against. */
1985
+ maxSourceAmount?: string;
1986
+ /** Opt-in atum-escrow-scheme fail-fast checks. */
1987
+ escrowContract?: string;
1988
+ reserver?: string;
1989
+ releaser?: string;
1990
+ /** Opt-in commitment checks. Compose `destination` from the REQUEST's destination. */
1991
+ destination?: string;
1992
+ requestId?: string;
1993
+ /** Solana: additionally required by the deposit-hash domain, independent of role binding. */
1994
+ svmSignatureClusterId?: string;
1995
+ svmSignatureDomainVersion?: number;
1996
+ /** EVM/Tron: the Permit2 contract the signature is bound to. */
1997
+ permit2Contract?: string;
1998
+ /** Freshness reference, Unix seconds. Defaults to now. */
1999
+ nowSec?: number;
2000
+ }
2001
+ /**
2002
+ * Recovers every `sender_auth.signed_messages[]` entry and binds the signed terms to
2003
+ * `expected`, returning the parsed permits and the account they all recover to.
2004
+ *
2005
+ * Strict by design: every entry must be a bindable permit, and a malformed one throws rather
2006
+ * than being skipped. A caller with deliberately mixed messages — an EVM setup approval
2007
+ * alongside the permit, say — must compose the per-entry adapter calls itself.
2008
+ *
2009
+ * This is the sender_auth layer only. Request-shape and per-consumer policy are the caller's.
2010
+ */
2011
+ declare function verifyPaymentRequest(request: PaymentRequest, expected?: VerifyPaymentRequestExpectations): VerifyResult;
2012
+
2013
+ export { type $OpenApiTs as $, type AuthTerms as A, type AwardedPayment as B, type CreateQuoteRequestData as C, type AwardedQuote as D, type ErrorResponse as E, type BidAward as F, type GetDefaultsData as G, type HealthCheckResponse as H, type ChainDefaultsByChain as I, type ChainDefaults as J, type DataIntegrityProof as K, type DeclineReason as L, type DeclineSummaryEntry as M, type FulfillmentConfirmation as N, type GetDefaultsResult as O, type PaymentRequest as P, type GetPaymentStatusResponse as Q, type ResolvePaymentData as R, type SubmitPaymentData as S, type OwnedAsset as T, type PaymentBlockchainContext as U, type VerifiedSenderAuth as V, type PaymentFailure as W, type PaymentResponse as X, type PaymentStatus as Y, type PaymentSummary as Z, type PaymentTimelineResponse as _, type ParsedPermit as a, type PaymentTransaction as a0, type PaymentTransactions as a1, type PreparePaymentRequest as a2, type PreparePaymentResponse as a3, type Quote as a4, type QuoteRequestAccepted as a5, type QuoteRequestResponse as a6, type QuoteRequestStatusResponse as a7, type ResolvePaymentResponse as a8, type SenderAuth as a9, type SenderAuthMessageScheme as aa, type TimelineStep as ab, type VerifiableCredential as ac, type VerifiableCredentialAuth as ad, type domain as ae, type error_code as af, type status as ag, type status2 as ah, type status3 as ai, type status4 as aj, type status5 as ak, type status6 as al, type status7 as am, type VerifyPaymentRequestExpectations as b, type VerifyResult as c, type AuthorizePaymentData as d, type AuthorizePaymentResponse as e, type GetDefaultsResponse as f, type SubmitPaymentResponse as g, type GetPaymentStatusData as h, type GetPaymentStatusResponse2 as i, type ResolvePaymentResponse2 as j, type GetPaymentTimelineData as k, type GetPaymentTimelineResponse as l, type PreparePaymentData as m, type PreparePaymentResponse2 as n, type CreateQuoteRequestResponse as o, type GetQuoteRequestStatusData as p, type GetQuoteRequestStatusResponse as q, type AwardQuoteData as r, type AwardQuoteResponse as s, type SignedMessage as t, type CreateQuoteRequest as u, verifyPaymentRequest as v, type AuthorizationResult as w, type AwardAccepted as x, type AwardRequest as y, type AwardResponse as z };