@atumlabs/payment-gateway-client 2.0.0 → 2.2.0

package/CHANGELOG.md

@@ -5,6 +5,55 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [2.2.0] - 2026-08-04
+
+> **Read this before upgrading if you script `send-payment`.** Its exit codes now
+> distinguish a settled payment from one still settling and one that failed, where every
+> accepted submission previously exited `0`. See the first entry under Changed.
+>
+> One typed-API change: three fields on `PaymentResponse` are no longer optional. This makes
+> reading a response simpler, not harder — see Changed.
+
+### Added
+- `send-payment --wait` keeps checking a submitted payment until it settles or fails, instead of reporting it as still pending. `--wait-seconds <n>` sets how long (default 60). With `--wait` the JSON on stdout is printed once the wait ends and reports the payment as of the last check — so it carries the settled `status` and the `fulfillment_confirmation`, rather than the `pending` the submit returned. Without `--wait`, output is unchanged. The bound is a client-side convenience: giving up does not affect the payment, and re-submitting the same `request_id` or reading the status endpoint picks up wherever it got to. A settlement that stalls never becomes terminal on its own, so no bound can promise a terminal answer.
+- `send-payment` and `payment-status` now print a one-line outcome summary to stderr saying what the payment's state means for a re-attempt: a pending payment is collected by re-submitting the **same** `request_id`, while a terminally failed one keeps its id and needs a **new** one. The JSON on stdout is unchanged.
+- Documented in `docs/idempotency.md` and the README: what the `409` compares, that deadlines and the signature are exempt from it, `idempotent_replay`, how to read `status`, and that a direct caller may either poll the status endpoint or re-submit.
+
+### Changed
+- **Behaviour change — `send-payment` exit codes.** Previously any accepted submission exited `0`. Now `0` means `completed`, `2` means `pending`, and `3` means `failed`/`cancelled`; `1` continues to mean the payment could not be submitted. Previously a still-settling payment and a terminally failed one both exited `0`, so `send-payment ... && <next step>` ran the next step for a payment that had not settled — including when re-submitting a `request_id` whose payment had already failed. Scripts that treat `0` as "submitted" should treat `0` and `2` as "submitted"; scripts that mean "settled" now get that from `0` alone. `payment-status` is unaffected: as a lookup, its exit code reports whether the lookup worked.
+- `--request-id`'s help text now states the consequence of omitting it: an id is generated, which makes every bare re-run a separate payment rather than a retry.
+- **`PaymentResponse.payment_id`, `.status` and `.idempotent_replay` are now required** in the typed API, matching what the gateway has always sent. They were typed optional, so TypeScript reported them as possibly `undefined` and reading `idempotent_replay` meant writing `=== true` to satisfy the compiler for a value that is always present. Existing code keeps compiling — a narrowed type only removes checks — unless it constructs a `PaymentResponse` itself, as a test fixture might, in which case all three now have to be supplied.
+
+
+
+### Fixed
+- Corrected the idempotency documentation. The 2.1.0 note below said that reusing a `request_id` with different terms returns the original payment and silently drops the new terms. The gateway rejects it with `409` `IDEMPOTENCY_TERMS_MISMATCH`, so an integrator following the old text would neither expect nor handle that error.
+- `IDEMPOTENCY_TERMS_MISMATCH`'s message described the compared terms as "source, destination, or fulfillment_amount", which had become incomplete — `max_source_amount` is compared too. It now names the categories ("accounts, assets, or amounts") rather than enumerating fields, so it stays accurate as the payment schema grows. The docs describe the comparison the same way, and point at the error's own `message` for which category differed.
+
+## [2.1.0] - 2026-07-31
+
+### Added
+- The CLIs read an optional `.env` file from the working directory, so `cp .env.example .env` configures them. Resolution order: a CLI flag, then the environment, then `.env`, then the built-in default. This applies to the CLIs only; the SDK reads the environment but never modifies it, so an application embedding the SDK stays in control of its own configuration.
+- `getErrorResponse(err)` returns the typed, public-facing gateway error (`ErrorResponse` — `code`, `message`, `request_id?`, `docs_url?`, `domain?`) from a caught `ApiError`, or `undefined` for anything else; `isApiError(err)` type guard for the transport-level error. No internal error taxonomy is exposed.
+- Idempotency and retries documentation (`docs/idempotency.md`) plus a summary in the README: the two guarantees (gateway dedup and on-chain single-settlement) and the per-chain differences (EVM/Tron vs Solana).
+- The published package now ships `LICENSE` and an autogenerated `THIRD-PARTY-NOTICES.txt` (attributing the third-party components statically bundled into `dist/`).
+- The gateway base URL now honors a `GATEWAY_URL` environment variable. Precedence: an explicit URL (SDK `{ BASE }` or the CLI `--gateway` flag), then `GATEWAY_URL`, then the built-in production-testnet default. A blank or whitespace-only `GATEWAY_URL` counts as unset and falls through to the default. An explicit `{ BASE: '' }` is used verbatim, which is how a caller targets a same-origin proxy.
+- The exported `OpenAPI` configuration now reports this package's default gateway (production-testnet), matching what a client resolves when no URL is supplied. The OpenAPI contract continues to list the mainnet server first, in line with the other Atum service contracts.
+
+### Changed
+- README signing example now uses the shipped signer helpers (`createSenderSigner` + `signPaymentRequest`) instead of manual signing, and the error-handling example reads the typed `ErrorResponse` fields.
+- The idempotency docs now state the consequence of reusing a `request_id` with different terms: the gateway returns the original payment, so the new terms are silently dropped and a genuinely new payment needs a new id.
+- The `fulfillment_verifier.endpoint` example in the OpenAPI spec is now a bare origin (`https://veri-fill.production-testnet.atum.xyz`) and its description says so. The field is a base URL to which the caller appends the verifier's own paths, so an example carrying `/v1/fulfillment` would double the path for anyone copying its shape.
+- Two documentation links in the OpenAPI contract now point at `schemas.atum.xyz`. Descriptive text only: JSON-LD `@context` prefixes, schema `$id` values, and `did:web:` identifiers are unchanged, since those take part in signature canonicalization.
+- The package is marked `restricted` and its `license` field is `SEE LICENSE IN LICENSE`. The publish guard now also fails on any inlined copyleft dependency, stale/incomplete third-party notices, missing license materials in the tarball, or an incorrect `license` field.
+- Default gateway hosts point at the canonical `payment-gw.production-{testnet,mainnet}.atum.xyz` endpoints (the SDK/CLI default and the generated client default), replacing the retired `atumlabs.xyz` / `api.atum.network` hosts.
+
+### Fixed
+- The CLIs (`send-payment`, `request-quote`, `quote-status`, `payment-status`) report the real package version via `--version` (they previously hardcoded `1.0.0`).
+- `docs/` is now included in the published package. The README links to `docs/idempotency.md`, which had not been shipped, so the link was dead for anyone installing from npm.
+- README corrections: the install instructions now distinguish a global install (for the command-line tools) from a project install (for the SDK), and the removal instructions match; the `.env` file and the gateway-URL precedence are documented; monorepo build detail moved to `CONTRIBUTING.md`.
+- A zero-config client (`new PaymentGatewayClient()` with no `BASE`) now uses a single, consistent gateway host; previously it fetched chain defaults from the testnet host but submitted payments to the mainnet host.
+
 ## [2.0.0] - 2026-07-27
 
 ### Breaking

package/README.md

@@ -2,25 +2,38 @@
 
 TypeScript client for Atum Payment Gateway API with CLI support.
 
+> **Proprietary software - not open source.**
+>
+> Copyright (c) 2026 Atum Labs, Inc. All rights reserved. Access to and use of `@atumlabs/payment-gateway-client` are limited to entities expressly authorized by Atum and are governed by the Atum Payment Gateway Client Private Repository License Agreement in the LICENSE file included with this package. Do not redistribute, publish, mirror, sublicense, or provide this package to any unauthorized person. By accessing, installing, copying, or using the package, you agree to the license terms.
+
 > NOTE: Payments from EVM chains require prior ERC-20 approval on the source token for the Permit2 contract (0x000000000022D473030F116dDEE9F6B43aC78BA3 on virtually all EVM chains).
 > 
-> (And the same applies for Tron/TRC-20, with a Permit2 address of TJhMXTHQHeQyMD7TcKQFqAePNgG4b31H9m on mainnet or TPUqJPASUn1zLvbLBgRZ5pBYrx7WSe5ahp on Shasta)`)
+> (And the same applies for Tron/TRC-20, with a Permit2 address of TJhMXTHQHeQyMD7TcKQFqAePNgG4b31H9m on mainnet or TPUqJPASUn1zLvbLBgRZ5pBYrx7WSe5ahp on Shasta).
 
 ## Installation
 
 `@atumlabs/payment-gateway-client` is a private npm package. Once your npm account
-has been granted access, install it with npm:
+has been granted access, install it with npm.
+
+To use the SDK in a project:
 
 ```bash
 npm install @atumlabs/payment-gateway-client
 ```
 
-This also installs the `send-payment`, `request-quote`, `quote-status`, and
-`payment-status` CLI commands.
+To use the command-line tools, install globally so they are on your `PATH`:
+
+```bash
+npm install -g @atumlabs/payment-gateway-client
+```
+
+A project-local install also provides the commands, under `node_modules/.bin`, so
+`npx send-payment ...` works without a global install.
 
 ## CLI Usage
 
-After linking, the `send-payment` command is available globally:
+The package provides four commands: `send-payment`, `request-quote`,
+`quote-status`, and `payment-status`. After a global install:
 
 ```bash
 send-payment [options] <sender> <amount> <sourceAsset> <receiver> <destinationAsset>
@@ -38,10 +51,39 @@ send-payment [options] <sender> <amount> <sourceAsset> <receiver> <destinationAs
 
 - `-V, --version` - Output the version number
 - `--gateway <url>` - Payment gateway URL (default: testnet)
-- `--request-id <id>` - Custom request ID (overrides prefix)
-- `--request-id-prefix <prefix>` - Custom request ID prefix (default: `pmt-gw-cli`)
+- `--request-id <id>` - Idempotency key; seeds the on-chain deposit nonce. Re-run with the same id to re-attempt one payment. Omitted, an id is generated and printed, which makes every bare re-run a separate payment (see [Idempotency and retries](#idempotency-and-retries))
+- `--request-id-prefix <prefix>` - Prefix for the auto-generated request id (default: `pmt-gw-cli`)
+- `--wait` - After submitting, keep checking until the payment settles or fails instead of reporting it as still pending
+- `--wait-seconds <n>` - How long `--wait` keeps checking (default: `60`). A convenience bound only; giving up does not affect the payment
 - `-h, --help` - Display help
 
+### Exit codes
+
+`send-payment` reports the payment's ending, so `send-payment ... && <next step>`
+runs the next step only for a settled payment:
+
+| Code | Meaning                                                                     |
+| ---- | --------------------------------------------------------------------------- |
+| `0`  | `completed` — settled                                                       |
+| `2`  | `pending` — accepted, no result yet                                          |
+| `3`  | `failed` / `cancelled` — terminal; a fresh attempt needs a new `--request-id` |
+| `1`  | no outcome obtained (rejected, gateway unreachable, bad arguments)            |
+
+On `2`, follow the payment with **`payment-status <payment_id>`** — the id is in the
+output — or use `--wait` to have `send-payment` do it for you. Re-running
+`send-payment` with the same `--request-id` also returns the current state, but it
+rebuilds and re-sends the payment to do so, which is more work than a status
+lookup.
+
+`1` is the case that reverses that order. It means the outcome is **unknown**, not
+that nothing happened: a request that timed out may still have been accepted, and
+you may not have a `payment_id` to look up. Re-run with the same `--request-id`,
+which resolves to the payment if one was created and creates it if not. The id is
+printed on failure for exactly this.
+
+`payment-status` is a lookup, so its exit code reports whether the lookup worked
+(`0`) or not (`1`), never the payment's outcome — read `status` for that.
+
 ### CAIP-19 Asset Format Examples
 
 - **EVM ERC20**: `eip155:42161/erc20:0xaf88d065e77c8cC2239327C5EDb3A432268e5831`
@@ -75,19 +117,32 @@ export TURNKEY_API_PRIVATE_KEY=...
 send-payment --provider turnkey <args...>
 ```
 
-Turnkey signing uses the shared `@atum-labs/turnkey-signer` (and `@atum-labs/km-core`),
-which live in this monorepo under `key-management/` and are consumed as pnpm workspace
-packages (`workspace:*`), built locally by the `build:deps` step. `@solana/web3.js` and
-the other Turnkey deps are already declared, so no extra setup is required.
+Everything Turnkey signing needs is already declared as a dependency, so no extra
+setup is required. The Turnkey code is loaded on demand, so the private-key path
+does not pull in Turnkey or `@solana/web3.js`.
+
+### Configuration file
+
+The command-line tools also read an optional `.env` file from the directory you
+run them in, so credentials and settings do not have to be retyped each time:
+
+```
+PRIVATE_KEY=0x...
+GATEWAY_URL=https://payment-gw.production-testnet.atum.xyz
+SOLANA_RPC_URL=
+TURNKEY_ORGANIZATION_ID=
+TURNKEY_WALLET_ID=
+TURNKEY_API_PUBLIC_KEY=
+TURNKEY_API_PRIVATE_KEY=
+```
+
+Where a setting has a matching flag, the flag takes precedence, then a value
+already set in your environment, then `.env`, then the built-in default. Keep the
+file out of version control — it holds signing keys.
 
-Notes:
-- The shared packages are workspace members, so a root `pnpm install` links them, and
-  `pnpm run build` and `pnpm test` build them first (`build:deps`).
-- The Turnkey code is loaded lazily (`import('./turnkey-impl')`), so the private-key
-  path never pulls in Turnkey or `@solana/web3.js`.
-- For publishing, the build (tsup) bundles the shared `@atum-labs/*` packages directly
-  into `dist`, so the published package is self-contained with no `@atum-labs/*` runtime
-  dependencies. The siblings stay `workspace:*` devDependencies used only at build time.
+This applies to the command-line tools only. The SDK does not read `.env`; pass
+configuration as arguments, or set `GATEWAY_URL` in your own application's
+environment.
 
 ### Output
 
@@ -105,12 +160,10 @@ PRIVATE_KEY=0xabc... send-payment \
   tron:shasta/trc20:TG3XXyExBkPp9nzdajDZsozEu4BkaSJozs
 ```
 
-### Unlinking
-
-To remove the global CLI command:
+### Removing the command-line tools
 
 ```bash
-npm unlink -g @atumlabs/payment-gateway-client
+npm uninstall -g @atumlabs/payment-gateway-client
 ```
 
 ## SDK Usage
@@ -118,18 +171,31 @@ npm unlink -g @atumlabs/payment-gateway-client
 ### Basic Setup
 
 ```typescript
-import { 
+import {
   PaymentGatewayClient,
+  createSenderSigner,
+  signPaymentRequest,
+  getErrorResponse,
   type PaymentResponse,
-  ApiError
+  ApiError,
 } from '@atumlabs/payment-gateway-client';
-import { ethers } from 'ethers';
 
 const client = new PaymentGatewayClient({
-  BASE: 'https://payment-gateway.atumlabs.xyz' // or your gateway URL
+  BASE: 'https://payment-gw.production-testnet.atum.xyz' // or your gateway URL
 });
 ```
 
+### Gateway URL
+
+The client uses the production-testnet gateway by default. To target another
+environment, in order of precedence:
+
+1. Pass it explicitly — SDK `new PaymentGatewayClient({ BASE })`, or the CLI `--gateway` flag.
+2. Set the `GATEWAY_URL` environment variable.
+3. Otherwise the built-in default `https://payment-gw.production-testnet.atum.xyz` is used.
+
+Mainnet access is granted by Atum; use the mainnet gateway URL provided to you.
+
 ### Example: Tron to Celo Sepolia Payment
 
 ```typescript
@@ -149,15 +215,22 @@ async function sendPayment() {
     fulfillmentAmount: '100000', // 0.10 USDT (6 decimals)
     sourceAsset: 'tron:shasta/trc20:TG3XXyExBkPp9nzdajDZsozEu4BkaSJozs', // USDT on Tron Shasta
     destinationAccount: '0xYourEthereumAddressHere',
-    destinationAsset: 'eip155:11142220/erc20:0x456a3D042C0DbD3db53D5489e98dFb038553B0d0' // USDC on Celo Sepolia
+    destinationAsset: 'eip155:11142220/erc20:0x456a3D042C0DbD3db53D5489e98dFb038553B0d0', // USDC on Celo Sepolia
+    // Required. Your stable idempotency key — reuse the SAME value on retry so a
+    // retry never becomes a second payment (see "Idempotency and retries" below).
+    requestId: 'order-4711',
   });
 
-  // Sign the message (Tron uses the same signing as Ethereum, but without the 0x private key prefix)
-  const wallet = new ethers.Wallet(privateKey.replace(/^0x/, ''));
-  paymentRequest.sender_auth.signed_messages[0].signature = 
-    wallet.signingKey.sign(
-      paymentRequest.sender_auth.signed_messages[0].message
-    ).serialized;
+  // Sign the prepared request with the SDK signer helper. It handles the
+  // per-chain signing differences internally (EVM typed-data, Tron hash,
+  // Solana Ed25519), so you never touch a chain library directly.
+  const sourceChainId = 'tron:shasta'; // CAIP-2 chain id, i.e. sourceAsset.split('/')[0]
+  const signer = createSenderSigner(sourceChainId, {
+    provider: 'raw',
+    privateKey,
+    pinnedAddress: tronSender,
+  });
+  await signPaymentRequest(paymentRequest, signer);
 
   try {
     // Submit the payment
@@ -165,16 +238,41 @@ async function sendPayment() {
       requestBody: paymentRequest
     }) as PaymentResponse;
 
-    console.log('Payment successful!');
+    // A 2xx means the payment was accepted, NOT that it settled. Branch on `status`:
+    // cross-chain settlement can outrun the gateway's synchronous window, so an accepted
+    // payment may still have no result yet. See "Idempotency and retries" below.
     console.log('Payment ID:', response.payment_id);
-    console.log('Source TX:', response.fulfillment_confirmation?.source_tx_hash);
-    console.log('Destination TX:', response.fulfillment_confirmation?.destination_tx_hash);
-    
+    if (response.idempotent_replay) {
+      // This request_id had been used before, so this is the payment your earlier attempt
+      // created. Nothing additional was charged.
+      console.log('Handed back an existing payment');
+    }
+
+    switch (response.status) {
+      case 'completed':
+        console.log('Settled.');
+        console.log('Source TX:', response.fulfillment_confirmation?.source_tx_hash);
+        console.log('Destination TX:', response.fulfillment_confirmation?.destination_tx_hash);
+        break;
+      case 'failed':
+      case 'cancelled':
+        // Terminal, and this request_id stays bound to it. A fresh attempt needs a NEW id.
+        console.error('Failed:', response.error?.code, response.error?.message);
+        break;
+      default:
+        // Still settling. Do not release goods, and do not pay again under a new id.
+        // Follow it with getPaymentStatus(payment_id); re-submitting this same request
+        // also returns the current state, but it re-sends the payment to do so.
+        console.log('Still settling — follow it with getPaymentStatus.');
+    }
+
     return response;
   } catch (error) {
-    if (error instanceof ApiError) {
-      console.error('API Error:', error.status, error.statusText);
-      console.error('Response:', error.body);
+    const gwError = getErrorResponse(error);
+    if (gwError) {
+      console.error('Gateway error:', gwError.code, gwError.message, gwError.request_id);
+    } else if (error instanceof ApiError) {
+      console.error('HTTP', error.status, error.statusText, error.url);
     }
     throw error;
   }
@@ -183,19 +281,53 @@ async function sendPayment() {
 
 ### Error Handling
 
-The SDK provides detailed error information through the `ApiError` type:
+The gateway returns a typed, public error body — `ErrorResponse`
+(`{ code, message, request_id?, docs_url?, domain? }`). Use `getErrorResponse`
+to narrow a caught error to it; it returns `undefined` for anything that is not
+a gateway error with that shape. For transport-level detail (HTTP status, URL),
+the thrown value is still an `ApiError`.
 
 ```typescript
-catch (error) {
-  if (error instanceof ApiError) {
-    console.error('Status:', error.status);
-    console.error('Status Text:', error.statusText);
-    console.error('URL:', error.url);
-    console.error('Response Body:', error.body);
+import { getErrorResponse, ApiError } from '@atumlabs/payment-gateway-client';
+
+try {
+  await client.payments.submitPayment({ requestBody: paymentRequest });
+} catch (error) {
+  const gwError = getErrorResponse(error);
+  if (gwError) {
+    console.error('Code:', gwError.code);             // machine-readable category
+    console.error('Message:', gwError.message);       // safe, human-readable text
+    console.error('Request ID:', gwError.request_id); // quote this to support
+    console.error('Docs:', gwError.docs_url);
+  } else if (error instanceof ApiError) {
+    // Transport-level failure with no typed body (e.g. a proxy/gateway error).
+    console.error('HTTP', error.status, error.statusText, error.url);
+  } else {
+    throw error;
   }
 }
 ```
 
+A thrown error does **not** mean no payment was created — a request that timed out
+may still have been accepted. Treat it as unknown rather than as a failure:
+
+- If you already hold the `payment_id` from an earlier attempt, read
+  `getPaymentStatus` — the cheapest way to find out what happened.
+- If you do not, re-submit the same `request_id`. It resolves to the payment if one
+  was created and creates it if not, which is the only recovery that works without
+  an id.
+
+One code is worth handling by name:
+
+```typescript
+const gwError = getErrorResponse(error);
+if (gwError?.code === 'IDEMPOTENCY_TERMS_MISMATCH') {
+  // 409 — this request_id already identifies a payment with different economics.
+  // Re-submitting cannot amend that payment; a genuinely different one needs a new
+  // request_id. See "Idempotency and retries".
+}
+```
+
 ### Asset Identifiers
 
 Assets are identified using the [CAIP-19](https://chainagnostic.org/CAIPs/caip-19) format:
@@ -203,13 +335,37 @@ Assets are identified using the [CAIP-19](https://chainagnostic.org/CAIPs/caip-1
 - Tron example: `tron:shasta/trc20:TG3XXyExBkPp9nzdajDZsozEu4BkaSJozs`
 - EVM example: `eip155:11142220/erc20:0x456a3D042C0DbD3db53D5489e98dFb038553B0d0`
 
-## Package Structure
-
-- `src/` - Source TypeScript files
-  - `generated/` - Auto-generated API client from OpenAPI spec
-  - `cli/` - CLI implementation
-- `dist/` - Pre-compiled JavaScript (ready to use)
-
----
-
-This repository contains proprietary Atum Labs code. Access is restricted and governed by the Private Repository License included in this repo.
+## Idempotency and retries
+
+Every payment carries a `request_id`. Pass a stable value and reuse the exact
+same one on every retry (a timeout, a network blip, a restart) and you end up
+with one payment, not two — and you get the same answer each time.
+
+- Using this SDK, `request_id` is **required** on the payment path
+  (`preparePaymentRequest`), and it is the only thing you manage: the SDK derives
+  the on-chain deposit nonce deterministically from it, so retries line up on
+  their own. Reuse the same `request_id` to retry safely.
+- On the CLI, `--request-id` is optional; when omitted an id is generated and
+  printed, so you can re-run with `--request-id <id>` to re-attempt the same
+  payment. A bare re-run, with no `--request-id`, is a **separate** payment.
+- A genuinely new payment needs a **new** `request_id`. Reusing one with different
+  economics (a corrected amount, a different token) is rejected with `409`
+  `IDEMPOTENCY_TERMS_MISMATCH` — one id identifies one payment.
+- Deadlines and the signature are exempt, so a re-submission of the original
+  bytes is fine even though its deadlines have expired by then.
+- `idempotent_replay` on the response tells you whether you were handed a payment
+  that already existed.
+- `pending` is not success. It means accepted and still settling: re-submit the
+  same `request_id` to collect the result. A `failed` payment is terminal and
+  keeps its id, so recovering from one needs a new id.
+
+See [docs/idempotency.md](docs/idempotency.md) for the full model: the two
+guarantees, when the `409` applies, how to read the outcome, and the per-chain
+differences (EVM/Tron vs Solana).
+
+## What is in the package
+
+- `dist/` — compiled JavaScript and TypeScript declarations, ready to use
+- `dist/cli/` — the four command-line tools
+- `docs/` — reference documentation, including [idempotency and retries](docs/idempotency.md)
+- `LICENSE`, `THIRD-PARTY-NOTICES.txt` — license terms and third-party attribution

package/THIRD-PARTY-NOTICES.txt

@@ -0,0 +1,45 @@
+THIRD-PARTY SOFTWARE NOTICES AND INFORMATION
+==============================================================================
+@atumlabs/payment-gateway-client
+
+The published artifact of this package (the compiled code under dist/) statically
+bundles the third-party open-source components listed below; their source is
+redistributed within this package, so their license and copyright notices are
+reproduced here. Components and versions were taken from the exact modules the
+build inlined. This file does NOT cover packages the consumer installs separately
+as dependencies of this package (for example @solana/web3.js, axios, ethers, bs58,
+commander, dotenv, tweetnacl, and zod) — those ship under their own licenses and are not
+redistributed here.
+
+LICENSE SUMMARY (1 component)
+------------------------------------------------------------------------------
+    1  MIT
+==============================================================================
+
+------------------------------------------------------------------------------
+@noble/hashes  1.8.0   (MIT)
+Author: Paul Miller (https://paulmillr.com)
+------------------------------------------------------------------------------
+
+The MIT License (MIT)
+
+Copyright (c) 2022 Paul Miller (https://paulmillr.com)
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the “Software”), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in
+all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+THE SOFTWARE.
+