# Agent Wallet Runtime API Source: https://docs.anyway.sh/api-reference/agent-wallet-api Authenticate agent-signed requests and use Agent Wallet runtime routes. Create and manage wallets, allocations, policies, and keys through the Agents app or Anyway CLI. ```text theme={null} Base URL: https://api.anyway.sh ``` ## Authentication Every runtime request uses the Agent Wallet Key's P-256 key and sends: | Header | Value | | ------------------- | ------------------------------------------------- | | `X-Agent-Pubkey` | Standard Base64-encoded SPKI P-256 public key | | `X-Agent-Timestamp` | Current Unix timestamp in seconds | | `X-Agent-Signature` | Standard Base64-encoded ASN.1 DER ECDSA signature | Sign the SHA-256 digest of this UTF-8 payload: ```text theme={null} METHOD /registered/route/path unix_timestamp ``` Use the registered path without the query string. The timestamp must be within 300 seconds of the server. The CLI handles signing, encoding, and local key selection automatically. ## Route summary | Method | Path | Result | | ------ | ---------------------------------- | --------------------------------------- | | `GET` | `/v1/agent-wallet` | Agent and assigned wallet identity | | `GET` | `/v1/agent-wallet/policies` | Policies attached to the wallet | | `GET` | `/v1/agent-wallet/history` | Wallet activity | | `GET` | `/v1/agent-wallet/credit-balance` | Organization Credit balance | | `POST` | `/v1/agent-wallet/sign-typed-data` | Wallet signature for EIP-712 typed data | An agent runtime receives no merchant management authority. ## Agent identity ```http theme={null} GET https://api.anyway.sh/v1/agent-wallet ``` The `data` object contains: | Field | Meaning | | --------------------------- | ------------------------------------------------------ | | `agentId`, `name` | Agent identity | | `publicKey`, `keyQuorumId` | Current signing identity | | `walletId`, `walletAddress` | Assigned Anyway wallet and EOA address when present | | `providerWalletId`, `appId` | Values needed to build wallet authorization signatures | | `revoked` | Whether the agent identity is revoked | Use `anyway wallets agents whoami` for the same runtime check. ## Policies ```http theme={null} GET https://api.anyway.sh/v1/agent-wallet/policies ``` Each policy includes its public identity, name, and enforcement configuration. Policies are enforced server-side; a client-side confirmation or displayed limit is not the enforcement boundary. ```bash theme={null} anyway wallets agents policies ``` ## History ```http theme={null} GET https://api.anyway.sh/v1/agent-wallet/history?limit=50 ``` `limit` defaults to `50` and accepts `1` through `200`. Entries can include `agentId`, destination address, amount, status, transaction hash, failure message, transfer type, explorer URL, and creation time. ```bash theme={null} anyway wallets agents history --limit 50 --format json ``` ## Organization Credits ```http theme={null} GET https://api.anyway.sh/v1/agent-wallet/credit-balance ``` ```json theme={null} { "success": true, "message": "Credit balance retrieved", "data": { "balance": 12.5, "unit": "USDC" } } ``` This is the organization-level Anyway Credit pool, not the agent wallet's on-chain USDC allocation. ## Sign EIP-712 typed data ```http theme={null} POST https://api.anyway.sh/v1/agent-wallet/sign-typed-data Content-Type: application/json ``` ```json theme={null} { "typed_data": { "domain": {}, "types": { "Example": [{ "name": "value", "type": "uint256" }] }, "primary_type": "Example", "message": { "value": "1" } }, "signature": "" } ``` The successful `data.signature` is a `0x`-prefixed secp256k1 Ethereum signature. The request's `signature` field is a separate wallet authorization signature; it is not one of the three P-256 HTTP authentication headers. Prefer the CLI for constructing this request: ```bash theme={null} anyway wallets agents sign --typed-data-file ./typed-data.json ``` ## Common errors | Status | Meaning | | ------ | ----------------------------------------------------------- | | `400` | Invalid body or no wallet is assigned | | `401` | Missing, stale, invalid, unknown, or revoked P-256 identity | | `500` | Runtime operation failed | An Agent Wallet Key is a spending credential. Never send its private material to this API, store it in telemetry, or include it in model prompts. Only the public key and request signature belong in HTTP headers. # Choose the Right API Source: https://docs.anyway.sh/api-reference/api-surfaces Choose the public API and authentication method for each integration. Anyway exposes separate supported integration surfaces for merchant servers, webhook receivers, agent runtimes, and instrumented applications. | Surface | Audience | Authentication | Primary capability | | ------------------- | ------------------------- | --------------------------------------------- | ------------------------------------------------ | | Merchant API | Merchant backend | `X-API-Key` | Commerce records | | Webhook delivery | Merchant HTTPS endpoint | Ed25519 signature | Receive order lifecycle events | | Agent Wallet API | Agent runtime | P-256 request signature | Read policy/history and authorize wallet actions | | SuperAPI directory | Agents and developers | Public discovery; Agent Wallet for paid calls | Discover and call x402 services | | Telemetry collector | Instrumented applications | Agent Traces API key | Export OpenTelemetry traces | ## Public integration rules The **Merchant API** is the supported server-to-server commerce API. Agent Wallet, webhook, SuperAPI, and telemetry contracts are also documented because customer code calls or receives them directly. Do not send a Merchant API key as a Bearer token and do not treat an Agent Wallet Key as a merchant credential. ## Base URLs ```text theme={null} Merchant API: https://merchant-api-prod.anyway.sh Agent Wallet API: https://api.anyway.sh SuperAPI directory: https://marketplace-prod.anyway.sh Telemetry: https://collector.anyway.sh ``` Use URLs returned by Anyway, including `paymentLinkUrl` and callable SuperAPI URLs. Do not derive alternate links or assume that all surfaces share one hostname. # Authentication Source: https://docs.anyway.sh/api-reference/authentication Use Merchant API keys, Agent Wallet signatures, and telemetry keys safely. ## Merchant API key Create a **Merchant API key** under **Business profile → Developers → API Keys**. ```bash theme={null} curl https://merchant-api-prod.anyway.sh/v1/me \ -H "X-API-Key: ak_YOUR_API_KEY" ``` `GET /v1/me` returns the key's `orgId`, `apiKeyId`, and permissions. Merchant API keys are server-side credentials. ## Agent Wallet Key An Agent Wallet Key is a P-256 signing bundle created for one agent wallet: ```bash theme={null} export ANYWAY_AGENT_WALLET_KEY="" anyway wallets agents whoami ``` The CLI signs each Agent Wallet API request. Advanced direct clients send: | Header | Value | | ------------------- | ---------------------------- | | `X-Agent-Pubkey` | Base64 SPKI P-256 public key | | `X-Agent-Timestamp` | Current Unix timestamp | | `X-Agent-Signature` | Base64 DER ECDSA signature | The signature covers the SHA-256 digest of: ```text theme={null} METHOD /request/path unix_timestamp ``` Prefer the CLI unless you specifically need to implement this protocol. ## Telemetry key Agent Traces API keys authorize SDK export to the collector. Store them in environment variables or a secrets manager and redact them from spans. Never expose any secret in browser code, public source, model prompts, traces, screenshots, or support messages. Rotate a key immediately if its value may have leaked. # Catalog, Customers & Access Source: https://docs.anyway.sh/api-reference/catalog Products, subscription records, customers, and entitlements. The generated endpoint pages contain the exact filters and response schemas for these Merchant API operations. ## Products Search and filter the organization catalog. Read one product by its Anyway ID. List the customer-facing Anyway links configured for a product. ## Subscription records Filter and paginate recorded subscriptions. Inspect lifecycle, customer, product, and billing data. Use these operations to inspect subscription records and their lifecycle data. The list accepts `status` and `customer_id`. A subscription response includes its stable `subscriptionId`, customer and product, `DAY`, `MONTH`, or `YEAR` billing interval, current period end, scheduled-cancellation state, and initial/latest order IDs when those relationships exist. These Merchant API operations are read-only; schedule cancellation from the authenticated Business app. ## Customers Read customers derived from commerce records. Inspect one derived customer identity. Customers are derived from the organization's order history. A customer record contains its stable `customerId` and normalized email. To load related commerce records, filter orders and subscriptions with that `customer_id`. ## Entitlements Resolve access using an email, wallet, or customer identity, optionally scoped to a product. An entitlement response describes current access; it is not a substitute for authenticating the person making the request. Match the resolved identity to your own authenticated user before granting content or service access. # Inspect API key Source: https://docs.anyway.sh/api-reference/endpoint/api-keys api-reference/openapi.json GET /v1/me Inspect the organization and permissions attached to the current API key. Authenticate with an API key that belongs to the target organization. # Check product access Source: https://docs.anyway.sh/api-reference/endpoint/check-entitlement api-reference/openapi.json GET /v1/entitlements/check Check whether a customer currently has access to a product. Authenticate with an API key that belongs to the target organization. # Get a customer Source: https://docs.anyway.sh/api-reference/endpoint/get-customer api-reference/openapi.json GET /v1/customers/{id} Retrieve one customer by its Anyway customer ID. Authenticate with an API key that belongs to the target organization. # Get an order Source: https://docs.anyway.sh/api-reference/endpoint/get-order api-reference/openapi.json GET /v1/orders/{id} Retrieve one order by its Anyway order ID. Authenticate with an API key that belongs to the target organization. # Get a product Source: https://docs.anyway.sh/api-reference/endpoint/get-product api-reference/openapi.json GET /v1/product/{id} Retrieve one product by its Anyway product ID. Authenticate with an API key that belongs to the target organization. `GET /v1/products/{id}` remains available as a deprecated alias. New integrations should use `GET /v1/product/{id}`. # Get product payment links Source: https://docs.anyway.sh/api-reference/endpoint/get-product-payment-links api-reference/openapi.json GET /v1/product/{id}/payment-links List the customer-facing Anyway payment links configured for a product. Use the returned `paymentLinkUrl` exactly as provided. Provider account and collection details are not part of this public response. `GET /v1/products/{id}/payment-links` remains available as a deprecated alias. New integrations should use `GET /v1/product/{id}/payment-links`. # Get a subscription record Source: https://docs.anyway.sh/api-reference/endpoint/get-subscription api-reference/openapi.json GET /v1/subscriptions/{id} Retrieve one subscription record by its Anyway subscription ID. Authenticate with an API key that belongs to the target organization. # List customers Source: https://docs.anyway.sh/api-reference/endpoint/list-customers api-reference/openapi.json GET /v1/customers List customers associated with the authenticated organization’s orders. Authenticate with an API key that belongs to the target organization. # List subscription records Source: https://docs.anyway.sh/api-reference/endpoint/list-subscriptions api-reference/openapi.json GET /v1/subscriptions List recurring-payment subscription records visible to the authenticated organization. Authenticate with an API key that belongs to the target organization. # List orders Source: https://docs.anyway.sh/api-reference/endpoint/orders api-reference/openapi.json GET /v1/orders List the authenticated organization’s orders with pagination and filters. Authenticate with an API key that belongs to the target organization. # List products Source: https://docs.anyway.sh/api-reference/endpoint/products api-reference/openapi.json GET /v1/product List published, draft, or archived products for the authenticated organization. Authenticate with an API key that belongs to the target organization. `GET /v1/products` remains available as a deprecated alias with the same query and response contract. New integrations should use `GET /v1/product`. # Webhook Delivery Source: https://docs.anyway.sh/api-reference/endpoint/webhooks Receive, verify, deduplicate, and process signed commerce events. Create and manage webhook endpoints under **Business profile → Developers → Webhooks**. ## Verification key Fetch Anyway's public Ed25519 key and cache it: ```bash theme={null} curl https://api.anyway.sh/v1/webhooks/signing-key ``` ```json theme={null} { "keyId": "default", "algorithm": "ed25519", "publicKey": "whpk_", "keys": [{ "kty": "OKP", "use": "sig", "crv": "Ed25519", "kid": "default", "x": "", "alg": "EdDSA" }] } ``` `publicKey` is the prefixed raw-key representation, while `keys` is the equivalent JWKS representation. The delivery envelope follows Standard Webhooks and uses an asymmetric Ed25519 (`v1a`) signature. Refresh the cached key if verification begins failing after a key rotation. ## Events Current events are: | Event | Meaning | | ---------------------- | ------------------------------------------------------------ | | `order.pending` | An order exists but payment is not confirmed | | `order.paid` | Payment is confirmed and the order may be fulfilled | | `order.failed` | The payment attempt failed | | `subscription.created` | A customer subscription was created | | `subscription.updated` | The current period or scheduled-cancellation details changed | | `subscription.expired` | The subscription expired | | `subscription.ended` | The subscription reached its final ended state | An empty endpoint event selection subscribes to all supported events. Fulfill only after a verified `order.paid`. A period-end cancellation is reported through `subscription.updated`; use `cancelAtPeriodEnd` and `currentPeriodEnd` to represent the scheduled state before `subscription.ended`. ## Delivery headers and signed content | Header | Meaning | | ------------------- | ----------------------------------------------------------------------------------- | | `webhook-id` | Stable logical event ID and idempotency key; unchanged across retries of that event | | `webhook-timestamp` | Unix timestamp in seconds | | `webhook-signature` | `v1a,` in Standard Webhooks format | The signed message is the exact byte sequence: ```text theme={null} webhook-id.webhook-timestamp.raw-body ``` Verify against the raw request body before JSON parsing. Reject stale timestamps and unknown signatures. ## Verify Ed25519 signatures ```javascript Node.js theme={null} import express from "express"; import { createPublicKey, verify as verifySignature } from "node:crypto"; const signingKeyResponse = await fetch("https://api.anyway.sh/v1/webhooks/signing-key"); if (!signingKeyResponse.ok) throw new Error("Unable to load Anyway signing keys"); const jwks = await signingKeyResponse.json(); const verificationKeys = jwks.keys.map((jwk) => createPublicKey({ key: jwk, format: "jwk" }), ); function verifyAnywayWebhook(rawBody, headers) { const id = headers["webhook-id"]; const timestamp = headers["webhook-timestamp"]; const signatureHeader = headers["webhook-signature"]; if (!id || !timestamp || !signatureHeader) throw new Error("Missing webhook headers"); const timestampSeconds = Number(timestamp); if (!Number.isSafeInteger(timestampSeconds) || Math.abs(Math.floor(Date.now() / 1000) - timestampSeconds) > 300) { throw new Error("Stale webhook timestamp"); } const signedContent = Buffer.concat([ Buffer.from(`${id}.${timestamp}.`, "utf8"), rawBody, ]); const valid = signatureHeader.split(" ").some((versionedSignature) => { const [version, encodedSignature] = versionedSignature.split(",", 2); if (version !== "v1a" || !encodedSignature) return false; try { const signature = Buffer.from(encodedSignature, "base64"); return verificationKeys.some((key) => verifySignature(null, signedContent, key, signature), ); } catch { return false; } }); if (!valid) throw new Error("Invalid webhook signature"); return JSON.parse(rawBody.toString("utf8")); } const app = express(); app.post("/webhooks/anyway", express.raw({ type: "application/json" }), (req, res) => { let event; try { event = verifyAnywayWebhook(req.body, { "webhook-id": req.header("webhook-id"), "webhook-timestamp": req.header("webhook-timestamp"), "webhook-signature": req.header("webhook-signature"), }); } catch { return res.sendStatus(401); } enqueueIdempotently(req.header("webhook-id"), event); return res.sendStatus(204); }); ``` ```python Python theme={null} # pip install cryptography import base64 import json import time from urllib.request import urlopen from cryptography.exceptions import InvalidSignature from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PublicKey def decode_base64url(value): return base64.urlsafe_b64decode(value + "=" * (-len(value) % 4)) with urlopen("https://api.anyway.sh/v1/webhooks/signing-key", timeout=5) as response: jwks = json.load(response) verification_keys = [ Ed25519PublicKey.from_public_bytes(decode_base64url(jwk["x"])) for jwk in jwks["keys"] ] def verify_anyway_webhook(raw_body, headers): webhook_id = headers.get("webhook-id") timestamp = headers.get("webhook-timestamp") signature_header = headers.get("webhook-signature") if not webhook_id or not timestamp or not signature_header: raise ValueError("Missing webhook headers") timestamp_seconds = int(timestamp) if abs(int(time.time()) - timestamp_seconds) > 300: raise ValueError("Stale webhook timestamp") signed_content = f"{webhook_id}.{timestamp}.".encode() + raw_body for versioned_signature in signature_header.split(): try: version, encoded_signature = versioned_signature.split(",", 1) if version != "v1a": continue signature = base64.b64decode(encoded_signature, validate=True) for key in verification_keys: try: key.verify(signature, signed_content) return json.loads(raw_body) except InvalidSignature: pass except (ValueError, TypeError): continue raise InvalidSignature("Invalid webhook signature") @app.post("/webhooks/anyway") def anyway_webhook(): try: event = verify_anyway_webhook(request.get_data(), request.headers) except (InvalidSignature, ValueError): return ("", 401) enqueue_idempotently(request.headers["webhook-id"], event) return ("", 204) ``` ## Payload The signed envelope contains `type`, RFC 3339 `timestamp`, `apiVersion`, endpoint identity, and either `data.order` or `data.subscription`, according to the event type. Important order fields include: | Field | Meaning | | --------------------------------------- | ------------------------------------------------------------------------ | | `orderId`, `orgId` | Anyway order and organization | | `merchantReference`, `merchantMetadata` | Your correlation values; treat as untrusted strings | | `status`, `provider` | Canonical payment state and rail | | `amountCents`, `currency` | Minor-unit amount and lowercase settlement currency | | `product` | Optional product `id` and `name` | | `paymentLinkId` | Originating link when known | | `crypto` | Optional CAIP chain, asset, payer, recipient, and transaction provenance | | `originalOrderId` | Related original order when applicable | | `providerSubscriptionId` | Payment-channel subscription attribution when applicable | | `createdAt`, `updatedAt` | RFC 3339 UTC timestamps | For a payment link opened with `merchant_reference=PUR_456&user_id=USR_123&source=web`, an order event contains the same values: ```json theme={null} { "type": "order.paid", "data": { "order": { "orderId": "ORD_EXAMPLE", "merchantReference": "PUR_456", "merchantMetadata": { "merchant_reference": "PUR_456", "user_id": "USR_123", "source": "web" }, "status": "PAID" } } } ``` The webhook signature covers the exact raw body, including `merchantMetadata`. Signature verification proves that Anyway delivered the payload; it does not make the original buyer-visible query values suitable for authorization. Never authorize access solely from `merchantMetadata`, a buyer note, email, or URL parameter. Compare the order, amount, currency, product, and reference with your own server-side record. ## Subscription payload Subscription events use `data.subscription`. Important fields include: | Field | Meaning | | ----------------------------- | ---------------------------------------------------------- | | `subscriptionId`, `orgId` | Anyway subscription and organization | | `status`, `provider` | Canonical lifecycle state and payment provider | | `providerSubscriptionId` | Provider-side subscription correlation identifier | | `customerId`, `customerEmail` | Customer identity when available | | `product` | Optional product `id` and `name` | | `billingInterval` | `DAY`, `MONTH`, or `YEAR` | | `amountCents`, `currency` | Minor-unit amount and lowercase settlement currency | | `currentPeriodEnd` | Current paid-through time when available | | `cancelAtPeriodEnd` | Whether final cancellation is scheduled for the period end | | `canceledAt`, `endedAt` | Cancellation and final-end timestamps when available | | `createdAt`, `updatedAt` | RFC 3339 UTC timestamps | ```json theme={null} { "type": "subscription.updated", "data": { "subscription": { "subscriptionId": "SUB_EXAMPLE", "orgId": "ORG_EXAMPLE", "providerSubscriptionId": "sub_example", "status": "ACTIVE", "customerId": "CUS_EXAMPLE", "customerEmail": "buyer@example.com", "product": { "id": "PRD_EXAMPLE", "name": "Pro Plan" }, "billingInterval": "MONTH", "amountCents": 9900, "currency": "usd", "currentPeriodEnd": "2026-09-10T00:00:00Z", "cancelAtPeriodEnd": true, "createdAt": "2026-08-10T00:00:00Z", "updatedAt": "2026-08-10T08:00:00Z" } } } ``` `merchantReference` and `merchantMetadata` belong to order payloads. They are not fields of `data.subscription`; use `subscriptionId` to query related orders when you need the initial checkout context. ## Delivery behavior * Return a `2xx` quickly after durable enqueueing. * Each attempt has a 10-second timeout. * Transport failures, `408`, `429`, and `5xx` responses are retried. * `3xx` responses and permanent `4xx` responses other than `408` and `429` are not retried. * Delivery allows up to 12 attempts with exponential backoff capped at one hour. * `Retry-After` is honored for `429` and `503`, up to the one-hour cap. * Delivery is at least once and events can arrive out of order. Use `webhook-id` as the delivery idempotency key. Do not let a late pending event regress a locally paid order or let an older subscription update overwrite newer lifecycle state. Do not log webhook signatures, API keys, full payment details, identity documents, payout-account information, or unredacted customer metadata. # Developer Overview Source: https://docs.anyway.sh/api-reference/introduction Choose the Business or Agents integration surface. Anyway exposes separate integration paths for selling, account management, agent spending, and telemetry. Create products and payment links, receive order events, and match eligible Card / USD sales with Finance records. Create controlled agent wallets and call paid APIs over x402. ## Authentication * **Merchant API keys** access commerce records from a server. * **Merchant login** manages products, Finance setup, wallet ownership, Credits, webhooks, and account settings. * **Agent Wallet Keys** are used by an agent runtime for identity, policies, history, and paid calls. Never use an Agent Wallet Key as a merchant credential, and never expose either credential in browser code or logs. ## Choose the right API first The Merchant API, webhook delivery contract, Agent Wallet API, SuperAPI, and agent-tracing collector use different hostnames and credentials. Choose the correct hostname, credential, and contract. Use one CLI for Business and Agents workflows. # Merchant API Source: https://docs.anyway.sh/api-reference/merchant-api Access commerce resources using a server-side Merchant API key. The Merchant API is the stable, organization-scoped commerce API for merchant backends. Its endpoint pages are rendered from the published OpenAPI contract, so request parameters and response schemas stay aligned with the running service. Use the generated endpoint pages as the source of truth for paths, parameters, fields, and status codes. These guides explain how to use the API without duplicating the contract. ## Explore the API Inspect the organization and key associated with the current request. Confirm payment status and build idempotent fulfillment. Access products, subscriptions, customers, and entitlements. Inspect exact query parameters, response fields, and errors. ## Common rules * The public Merchant API uses a server-side `X-API-Key`. * Every request is scoped to the organization associated with that key. * Successful responses use the standard response envelope; list operations return paginated data. * A missing or invalid key is rejected before organization data is resolved. Never expose a Merchant API key in browser code, a mobile application, a public repository, or a customer-visible URL. # Orders API Source: https://docs.anyway.sh/api-reference/orders-guide Query orders, confirm payment status, and build safe fulfillment with the Merchant API. Use the generated endpoint pages for the complete query parameters and response schemas. Filter and paginate organization-scoped orders. Inspect one order and its available payment-channel identifiers. ## List and detail behavior The list operation supports payment-status checks and operational views. Its `status` filter matches the human-facing `displayStatus`, while the response also preserves the canonical status. You can also narrow orders by `customer_id` or Anyway `subscription_id`. Merchant API order detail does not expose payment-provider or provider account identifiers. `orderId` is the canonical order identifier. The legacy `id` response field contains the same value but is deprecated. `amount` is the display-unit amount, while `amountCents` is the stored minor-unit amount. Card orders can also include `fundsSettled` and `settledAvailableOn`. Use `fundsSettled` as the payout-eligibility state; `settledAvailableOn` is only the provider's estimated availability time. Both fields are omitted for payment methods without this settlement lifecycle. ## Subscription relationships An order created for a recurring payment includes `subscriptionId`. The initial payment has no `originalOrderId`; each renewal points `originalOrderId` to that initial order. Use `GET /v1/orders?subscription_id=SUB_EXAMPLE` to retrieve the order history for one subscription. ## Payment-link correlation Append URL-encoded query parameters when sending a payment link to a buyer: ```text theme={null} https://pay.anyway.sh/pay/PL_EXAMPLE?merchant_reference=PUR_456&user_id=USR_123&source=web ``` When checkout opens, Anyway stores the query parameters on the checkout-attempt record as `merchantMetadata`. If a key matches `merchant_reference` or `merchantReference`, Anyway also promotes its value to the attempt's separate `merchantReference` field while keeping the original key-value pair in `merchantMetadata`. When payment is confirmed, both values are copied from the checkout attempt to the order record. Subscription renewal orders inherit them from the initial order. This persistence path makes the same correlation data available through order responses and Webhooks after checkout has finished. Payment-link query parameters are exposed through two complementary fields: * `merchantReference` is the promoted value of the `merchant_reference` query parameter. It is stored separately as a first-class correlation field, and the orders list can filter it with `merchant_reference`. * `merchantMetadata` contains every custom payment-link query parameter as string key-value pairs. Merchant API responses return the map, but arbitrary metadata keys cannot be used as list filters. After receiving an order ID from a webhook or success redirect, retrieve the order and read both fields: ```bash theme={null} curl "https://merchant-api-prod.anyway.sh/v1/orders/ORD_EXAMPLE" \ -H "X-API-Key: ak_YOUR_MERCHANT_API_KEY" ``` ```json theme={null} { "success": true, "message": "Order retrieved", "data": { "orderId": "ORD_EXAMPLE", "status": "PAID", "merchantReference": "PUR_456", "merchantMetadata": { "merchant_reference": "PUR_456", "user_id": "USR_123", "source": "web" } } } ``` Treat `merchantMetadata`, buyer-supplied notes, and URL query parameters as untrusted input; never use them alone to authorize access or set a price. ## Fulfillment Fulfill from a verified paid state or a verified `order.paid` webhook. Make delivery idempotent by the Anyway order ID. Anyway protects paid orders from duplicate payment events and status regression, but your fulfillment handler must also tolerate retries. A successful API response does not make buyer-controlled metadata trustworthy. Authorization and pricing decisions must come from server-controlled records. # Finance & Payouts Source: https://docs.anyway.sh/billing/finance-and-payouts Understand your USD balance, transactions, payout accounts, and payout requests. Finance manages Business balances, posted revenue, verification, payout accounts, and payout requests. ## Review total and available balances Finance separates two figures: | Figure | Meaning | | --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | **Total balance** | The combined USD, USDC, and USDT holdings shown by Business, including USD that may still be clearing | | **Available balance** | The amount currently available after unsettled USD and open payout requests are withheld; non-USD holdings remain display-only for bank payouts | When some USD is still clearing, Finance shows the withheld amount and may show its next estimated availability time. The estimate does not release funds by itself: availability changes only after settlement is confirmed. Refunded or disputed orders remain withheld instead of becoming requestable. The available USD component is based on posted Finance transactions. Each eligible platform-collected Card / USD sale records: * the gross amount paid by the buyer; * the applicable Anyway fee; * the net amount owed to your business; and * the related order ID. When checking the records, use the fee posted for the completed order; do not calculate it from a hard-coded rate. Income — per-transaction Anyway fee, net earnings, and funds availability The Business totals do not include organization Credits or funds allocated to Agent Wallets. Only the available USD component can fund a USD payout request; USDC and USDT do not increase the bank payout limit. Financial posting happens after the order is paid, so a new transaction can take a short time to appear. If payout availability cannot be calculated safely, Finance shows it as unavailable and blocks a new request instead of estimating a larger amount. ## Payout readiness Merchant verification must be **Approved** before you can add your first payout account. If you already have an active payout account, a later verification review does not block payout requests from that account. It does block adding another account until account creation becomes available again. The verification status rail changes with the application state. It may offer **Start application**, **Continue setup**, **Refresh status**, **Provide more info**, or **Contact support**. Payout account gate — merchant verification must be approved first Payout — available balance by currency, verification banner, and payout accounts ## Supported payout accounts | Account type | Details requested | | ------------------- | ------------------------------------------------------------------------------------------------------------------------- | | US ACH | Account holder name, checking or savings account type, 9-digit routing number, and account number | | UK bank | Account holder name, bank name, 6-digit sort code, and 8-digit account number | | Hong Kong bank, USD | Account holder name, bank name, an account number containing 4 to 64 digits, and an 8 or 11-character Hong Kong SWIFT/BIC | | Hong Kong bank, HKD | Account holder name, bank name, and an account number containing 4 to 64 digits; SWIFT/BIC is optional | | Alipay | Account holder name and Alipay account | | China bank | Account holder name, bank name, and account number; branch name and CNAPS code are optional | Finance balances and payout requests remain in USD for every account type. The selected account determines the receiving currency. A non-USD route is converted at the mid-market rate at withdrawal time; it does not create a non-USD balance in Anyway. You can save multiple accounts. Adding a new one does not replace an existing account. Removing an account prevents it from being used for a new payout request. Historical payout requests keep their masked account reference. Enter payout details only in the secure Finance form. Never send full account information through email, chat, support tickets, or screenshots. ## Request a USD payout Review the available USD amount shown in Finance. The total balance is not the payout limit. The minimum payout request is **\$50 USD**. Select one active saved payout account. The request remains denominated in USD; a non-USD route converts the transfer at withdrawal time. Optionally add a merchant note of up to 200 characters, then confirm. Follow the request in Finance as its status changes. ## Payout request states | Status | Meaning | | ---------- | --------------------------------- | | Requested | The request was submitted | | Processing | The payout is being processed | | Paid | The payout was marked as sent | | Rejected | The request will not be processed | Paid and rejected requests are final. If a request is rejected, review the available information and contact support before creating a replacement request. # Credits & Funding Source: https://docs.anyway.sh/billing/usage-limits Understand organization Credits, wallet USDC, and how paid calls are funded. Anyway Credits and wallet USDC can both fund eligible agent activity, but they are not the same balance. The Agents **Account balance** displays buffer USDC, agent-wallet allocations, and organization Credits in one funding overview. USDT belongs to the Business balance view and is not part of this Agents allocation bar. Credits remain a separate, non-withdrawable asset. | Balance | Scope | Used for | | -------------- | ----------------------- | -------------------------------------------- | | Anyway Credits | Organization | Eligible SuperAPI and x402 charges | | Wallet USDC | Individual agent wallet | x402 payments after Credits are insufficient | | Buffer USDC | Wallet owner | Allocation to and from agent wallets | ## Check Credits As the wallet owner with a merchant login: ```bash theme={null} anyway wallets credit balance ``` From an agent runtime: ```bash theme={null} anyway wallets agents credit-balance ``` Both commands refer to the organization Credit pool. They do not report the selected agent wallet's USDC balance. ## Add Credits In the Agents wallet page, open **Add funds → Credits**, select an available package, and complete checkout. After successful payment, the balance refreshes automatically. The app loads the available package catalog for the current environment. Do not hard-code package IDs or checkout URLs. Credit fulfillment is webhook-driven and idempotent. If a payment event is delayed, Anyway can restore a missed fulfillment without crediting the same purchase twice. You can also start the same flow from the CLI: ```bash theme={null} anyway wallets credit topup ``` ## Payment order For an eligible SuperAPI call, Anyway uses organization Credits first. If Credits are insufficient, the call can fall back to the paying agent wallet's USDC balance. Credits cannot be: * withdrawn as USDC; * assigned to only one agent wallet; * used for a direct wallet transfer; or * treated as Business revenue. # Anyway Business Source: https://docs.anyway.sh/concepts Create products and payment-method-specific links, then manage checkout, orders, balances, and payouts. Anyway Business brings together products and payment links, customers, orders and subscriptions, Finance, and developer settings. Publish a product and share its customer-facing Anyway payment link. Submit the required business and representative details to enable Card / USD payments. Review paid orders and match Finance entries to their order IDs. Add a payout account, review your available balance, and submit a USD payout request. Find the Payment pages, Developers, language, and keyboard shortcuts. Send telemetry from the Anyway SDK and review traces from the CLI. ## How the Business flow works Set a name, description, price, and pricing model. Anyway creates a public payment link. Select and configure the payment method you want to offer. Send the returned `paymentLinkUrl` to the customer. Paid platform-collected Card / USD orders are recorded in Finance as your net earnings after the applicable Anyway fee. After approval, save one or more payout accounts and request a payout from your available USD balance. ## Business and Agents are separate views Use the product switcher in the Anyway app to move between these views: * **Business** for products, customers, orders, subscriptions, Finance, and Developers. * **Agents** for SuperAPI, the organization funding view, agent wallets, policies, and wallet activity. The same Anyway account can use both views. Their balances and workflows are shown separately so that merchant revenue is not confused with agent spending. # Agent Wallets Source: https://docs.anyway.sh/features/agent-wallet Allocate funds to agents and enforce their spending policies. An Agent Wallet gives one agent its own payment identity, balance allocation, and server-enforced spending policy. ## Buffer and allocation The Agents wallet page presents one owner-controlled buffer balance. Use **Distribute** to move USDC from the buffer into an agent wallet, or withdraw funds from the agent wallet back to the buffer. This model makes it clear: * how much the organization controls in the buffer; * how much is allocated across agents; and * how much each agent is allowed to spend. ## Manage wallets in the app Open a wallet row or its actions menu to inspect details, fund or withdraw an allocation, edit its policy, reset its key, and review activity. The page also exposes the organization Credit ledger. If setup was interrupted, use the displayed recovery state rather than creating another owner wallet. Agent Wallets — funding balance across USDC, USD Credit, and agent wallets Funding an agent moves USDC from the Main wallet to that agent's allocation; the network fee is sponsored by Anyway: Fund agent wallet — transfer from Main wallet on Base ## Create a wallet Use the one-step onboarding flow: ```bash theme={null} anyway login --agent-wallet ``` Or create another wallet while signed in: ```bash theme={null} anyway wallets agents create --name "Research Agent" ``` The setup creates a P-256 signing key. In the current CLI device flow, the CLI supplies an ephemeral public key, so the browser encrypts the private-key payload for that CLI session before relaying it. The browser also downloads a one-time local backup; that automatic download does not send the key to the CLI. Relay happens only after the user explicitly confirms, copies, or manually downloads from the device-flow dialog. Store the one-time Key backup securely after setup. ## Authentication modes | Task | Authentication | | --------------------------------------------------------- | ---------------- | | Create, list, fund, reset, or manage agent wallets | Merchant login | | View agent identity, policy, history, or make a paid call | Agent Wallet Key | | Read or top up organization Credits | Merchant login | | Read Credits from an agent runtime | Agent Wallet Key | Set the runtime key as an environment variable: ```bash theme={null} export ANYWAY_AGENT_WALLET_KEY="" ``` Or import the same bundle into the CLI: ```bash theme={null} anyway wallets agents import --token ``` ## Spending controls Spending policies are enforced server-side. A call that exceeds the configured limit is rejected before the wallet signs the payment. The current policy editor configures a maximum amount per typed-data signature. The attached server policy always blocks direct `eth_sendTransaction`; a zero maximum means typed-data signing is uncapped, while a positive value adds the per-signature USDC cap. Recommended practice: * start with a small per-transaction maximum; * omit CLI `--yes` during development so the x402 quote still requires confirmation; * monitor wallet history after changing a policy; and * rotate or reset a wallet if its key may have been exposed. An Agent Wallet Key is a secret signing credential. Do not include it in screenshots, support requests, source control, telemetry, or model prompts. # Agents App Guide Source: https://docs.anyway.sh/features/agents-app Navigate SuperAPI, Agent Wallets, funding, wallet activity, and shortcuts. The Agents view has two focused destinations: | Page | What it does | | ------------- | ------------------------------------------------------------------------------------------ | | SuperAPI | Browse paid APIs and copy a ready-made prompt for an AI agent | | Agent Wallets | Fund the organization buffer, allocate funds, manage wallets, policies, keys, and activity | Use the product switcher beside the Anyway logo to return to Business. ## Agent Wallet page The balance card combines the organization funding picture and shows how funds are allocated. From this page you can: * add funds, including purchasing organization Credits; * distribute USDC to an agent wallet; * withdraw an allocation back to the buffer; * create another agent wallet; * open a wallet detail drawer; * edit a spending policy; * reset a wallet key; and * inspect wallet activity and the Credit ledger. Incomplete or recoverable wallet setup states are shown on the same page so that you can resume rather than create conflicting wallets. ## Command palette Press `⌘K` on macOS or `Ctrl+K` elsewhere. Agents view can search SuperAPI, Agent Wallets, Documentation, individual wallets, and the create-wallet action. Business-only destinations are hidden. ## Language English and Simplified Chinese are available in the profile menu. Switching languages keeps the current page and session. User-created wallet names remain unchanged. # Anyway Agents Source: https://docs.anyway.sh/features/agents-overview Give agents a controlled way to pay for APIs and track what they spend. Anyway Agents combines an organization funding view, isolated agent wallets, spending policies, Credits, and paid API access. Complete login and wallet setup in one browser-assisted CLI flow. Distribute funds to individual wallets and enforce server-side limits. Discover an API, approve the quote, and let the CLI handle the x402 payment. Review wallet activity, policy outcomes, key safety, and the Credit ledger. Find funding, wallet actions, SuperAPI, language controls, and keyboard shortcuts. ## How funds are organized * **Account balance** combines the organization funding picture, including buffer USDC, agent allocations, and organization Credits. * **Buffer USDC** is the owner-controlled amount available for allocation. * **Agent wallets** receive an allocation from the buffer and have their own policies. * **Anyway Credits** are organization-level USD credits used before wallet USDC for eligible SuperAPI calls. * **Wallet USDC** belongs to an individual agent wallet and can pay when Credits are insufficient. Business revenue and payout balances are managed in the Business view. They are not part of the Agents buffer or an agent wallet. ## Use the product switcher The Anyway app has separate Business and Agents navigation. Choose **Agents** for SuperAPI and Agent Wallets. Choose **Business** for Products, Customers, Sales, and Finance. # Business API Reference Source: https://docs.anyway.sh/features/business-api Connect a merchant backend to Anyway's public commerce API and webhook contracts. Use the public Merchant API when your backend needs to read commerce records, confirm order and payment status, or automate fulfillment. The Business app remains the place to create API keys, configure webhook endpoints, manage products, and operate Finance. Endpoint pages are generated from the published OpenAPI contract. Use those pages as the source of truth for paths, parameters, response fields, and status codes. Choose the correct public API surface, credential, and integration contract. ## Business integration paths Understand the organization-scoped, server-side commerce API. Create and use a Merchant API key without exposing it to browser code. Confirm payment status and build idempotent fulfillment. Work with products, subscriptions, customers, and entitlements. Verify signed events and process retries safely. Distinguish Merchant API, webhooks, agent runtime, SuperAPI, and telemetry. Use only the customer-facing contracts linked from this page. Undocumented services and routes are not public integration surfaces. # Business Verification Source: https://docs.anyway.sh/features/business-verification Submit business or individual verification details and track the status. Business verification covers KYB for a business and identity verification (KYC) for its representative. Individual merchants complete KYC with their personal tax details. The whole application lives in the **Merchant verification** section of the **Settings → Setting up** checklist — a fresh account starts here: Payment setup on a fresh account — merchant verification at 0/4 with the corner progress card ## Choose an account type The first step asks whether you are applying as a **Business** or an **Individual**. | Account type | Registration details | | ------------ | ------------------------------------------------------------------------------------------------------------------------ | | Business | Legal entity name, tax residency, registration number and date, registered address, and a dedicated payout contact email | | Individual | Legal name, tax residency, and personal tax or registration number | Both account types also provide product and support details. For a Business application, the registered address country is taken from the selected tax residency. For Hong Kong addresses, the postal code may be left blank. For China, an Individual uses a citizen ID with 17 digits followed by a digit or `X`. A Business uses an 18-character Unified Social Credit Code. ## What you need Prepare the following information before starting: * the registration details for your selected account type; * product name, an `https://` website or product URL, and customer support email; * confirmation that the product is ready, pricing is publicly visible, and the intended use is ethical; * identity details, including legal name, date of birth, nationality, phone number, and residential address; * first and last name when applying as an Individual; and * a clear, non-empty passport image in JPG or PNG format, no larger than 10 MB. You do not need to enter bank or payout account details to submit business verification. ## Application states | Status | Meaning | What you can do | | ------------------------- | -------------------------------------------------- | -------------------------------------- | | Draft | The application has not been submitted | Continue editing | | Submitted | Anyway received the application | Wait for a status update | | Under review | Verification is in progress | Wait for a status update | | More information required | The application needs a correction or new document | Update and resubmit | | Approved | The application was approved | Continue with Finance setup | | Rejected | The application was not approved | Check the available status information | ## Submit or update an application In the Business view, go to **Settings → Setting up**. Actions that start, continue, or update the application lead here. While the application is under review, the Payout page offers **Refresh status**. A rejected application offers **Contact support** instead. Under **Application entity**, select the type that matches the applicant. Enter the registration, product, compliance, identity, and address information. Use a clear, unedited JPG or PNG image. Make sure the text and photo are readable. Check names, dates, registration numbers, and addresses before submitting. If the status changes to **More information required**, open the application, correct the requested fields, upload a replacement document if needed, and submit again. ## After approval Once every section is approved, the checklist shows **Card / USD available** and you can create Card / USD products and payment links: Payment setup with merchant verification approved — Card / USD available The verification items belong to one reviewed application. Editing any of them after approval sends the whole application back to review. Until it is approved again, new Card / USD products, payment links, and payout accounts are unavailable — existing payment links and payouts keep working. Continue in Finance to add a payout account and manage payout requests. Add a US, UK, Hong Kong, Alipay, or China payout account and learn how payout requests are processed. # Wallet Activity & Security Source: https://docs.anyway.sh/features/cost-tracking Review wallet activity, policy outcomes, keys, and Credit history. Use Agent Wallets to understand how funds moved, which policy applied, and whether a key needs attention. ## What to inspect Review paid calls, transfers, and policy outcomes for one agent wallet. Confirm the wallet identity, current allocation, and setup state. Inspect organization Credit entries separately from wallet USDC. Confirm the active per-transaction limit before enabling autonomous approval. ## CLI checks ```bash theme={null} anyway wallets agents whoami anyway wallets agents policies anyway wallets agents history ``` Add `--format json` when another tool or agent needs to parse the result. ## Keep activity data safe * Redact Agent Wallet Keys and API keys. * Do not attach raw payment signatures to traces. * Avoid logging customer payment data or Business payout information. * Use stable agent, project, and trace identifiers instead of personal information. Use `anyway traces list` to review SDK execution traces and model-cost data. Business orders and Finance transactions remain in the Business view. # Orders & Sales Records Source: https://docs.anyway.sh/features/customer-order-attribution Track paid orders and match them with Finance transactions. Orders are the source of truth for the customer purchase. Finance shows how eligible Card / USD sales affect your available balance. ## List, filter, and export The Orders table shows order ID, customer, amount, payment method, status, and time. Filter by status, product, and date range, or clear all filters. CSV export uses the active filters and the export limit shown in the dialog. Orders — transaction ledger with order type, payment method, and status ## Follow a payment The customer completes checkout through the public Anyway payment link. Anyway processes payment events idempotently so duplicate or out-of-order events do not create duplicate orders or move a paid order back to pending. Eligible Card / USD sales are added to Finance asynchronously. A paid order can appear in Orders shortly before its Finance transaction appears. This short delay is expected because financial posting runs asynchronously. ## Match records by order ID For each Card / USD sale, compare: | Field | Orders | Finance | | --------------------- | --------------------------------------------- | -------------------------------------- | | Order ID | Primary purchase identifier | Available as the transaction reference | | Gross amount | Amount paid by the customer | `gross` | | Anyway fee | Shown with the payment details when available | `platform fee` | | Net business earnings | — | `seller amount` | | Status | Customer payment status | Financial posting status | The fee configuration in effect when the buyer pays is used for that order. Later pricing changes only affect future orders. ## Order details * Platform-collected Card / USD orders show the customer amount, Anyway fee, net earnings, card details and checks, and a payment timeline. Finance ledger entries are looked up by order ID. * Crypto orders show status, product, amount, email, note, merchant reference, chain, payment link, transaction hash, and an explorer link when available. * Recurring orders are labeled as the initial subscription payment or a renewal. Open the related subscription to review its complete order history. Follow customer purchase history and subscription renewal relationships. ## Different payment methods * An incomplete or unsuccessful checkout is not recorded as a completed sale. * Crypto, x402, and credit activity use their own balance or activity views and are not included in the Card / USD Finance ledger. Do not fulfill solely from a browser redirect. Verify the order through your server or a signed webhook and make fulfillment idempotent. ## Need help matching a payment? Send the order ID—not full card, bank, identity, or passport details—to [support@anyway.sh](mailto:support@anyway.sh). # Customers & Subscriptions Source: https://docs.anyway.sh/features/customers-and-subscriptions Inspect customer purchase history and manage recurring customer subscriptions. The **Customers** and **Subscriptions** pages under **Payment** describe commerce sold by your organization. ## Customers The Customers page lists the stable Anyway customer ID and normalized email for customers derived from your organization's orders. Open a customer to review related orders and subscriptions, then follow an item to its full detail view. Customer records are created from commerce activity; this page is not a general-purpose contact database and does not edit customer identity. Customers — list with per-customer order and subscription history ## Subscriptions The Subscriptions page lists recurring customer subscriptions and supports status filtering. Open a subscription to inspect: * status, customer, product, amount, currency, and billing interval; * the current period end and whether cancellation is scheduled; and * the initial payment plus later renewal orders. Supported lifecycle statuses are `PENDING`, `ACTIVE`, `PAUSED`, `CANCELED`, `EXPIRED`, and `ENDED`. Billing intervals can be daily, monthly, or yearly. Recurring checkout is available for supported Card / USD pricing; Crypto payment links remain one-time. Subscriptions — recurring billing with interval, status, and period end ## Order relationships | Order kind | `subscriptionId` | `originalOrderId` | | ---------------------------- | ---------------- | --------------------------- | | One-time purchase | Not present | Not present | | Initial subscription payment | Present | Not present | | Subscription renewal | Present | Points to the initial order | Use these relationships to distinguish one-time orders from initial and renewal charges without relying on a payment-provider identifier. ## Schedule cancellation Canceling from the Subscriptions page schedules cancellation at the end of the current billing period. The subscription can remain active until `currentPeriodEnd`; the detail shows that state through `cancelAtPeriodEnd`. Refreshes and Webhook updates reconcile the record with the payment provider. Read subscription lifecycle and order relationship fields from your backend. Read customer identities and use `customer_id` to filter related records. # Developer Settings Source: https://docs.anyway.sh/features/developer-settings Create scoped API keys and manage webhook endpoints. Open the profile menu in Business view and select **Developers**. The page has separate **API Keys** and **Webhooks** tabs. Developers — Agent Traces API Key and Merchant API Keys ## API key types | Key | Use it for | Send it as | | -------------------- | --------------------------------------------------------------------------------- | -------------------------------------------------- | | Merchant API key | Access products, orders, subscriptions, customers, and entitlements from a server | `X-API-Key` | | Agent Traces API key | Send telemetry from the Anyway SDK | SDK configuration or `Authorization: Bearer ` | Create only the key type required by the integration. Copy a new secret immediately and store it in a server-side secrets manager; the complete value may not be shown again. Never put either key in browser JavaScript, a mobile binary, source control, screenshots, support tickets, or telemetry. ## Webhook endpoints The **Webhooks** tab lets you create, update, enable, disable, and remove organization-scoped HTTPS endpoints. Anyway signs deliveries with its platform Ed25519 key; verification uses the published public key rather than a per-endpoint shared secret. Review the stable server API and its generated contract. Verify signatures and implement idempotent fulfillment. # Products & Payment Links Source: https://docs.anyway.sh/features/payments Create products and share customer-facing Anyway payment links. Each product can have one or more payment links. Customers only need the public Anyway URL returned as `paymentLinkUrl`. ## Create a payment link Go to **Business → Products** and enter the product name, description, price, and currency. Create Product — name, description, and one-time or subscription pricing Choose the payment method and complete the requested setup. You can add more payment links to the same product later — each link inherits the product and only sets its own pricing. Create Payment Link — pricing inherited from the product Select **Create Product**. The app creates the product as published and opens a success dialog. Select **Copy payment link** from that dialog. There is no separate publish step. ```json Selected payment-link response fields theme={null} { "productId": "PRD_EXAMPLE", "paymentLinkUrl": "https://pay.anyway.sh/pay/PL_EXAMPLE" } ``` Use the returned `paymentLinkUrl` as the checkout base URL. Do not parse or reconstruct its path. You may append URL-encoded query parameters when you need to carry correlation data through checkout. ## Attach correlation data Append string-valued query parameters to the payment link you send to a buyer: ```text theme={null} https://pay.anyway.sh/pay/PL_EXAMPLE?merchant_reference=PUR_456&user_id=USR_123&source=web ``` Anyway preserves the first string value for each query parameter in the order's `merchantMetadata`. The `merchant_reference` parameter has an additional role: Anyway also promotes it to the top-level `merchantReference` field, while retaining it in `merchantMetadata`. A checkout URL may contain at most 20 distinct query parameter names, and its complete raw query string may be at most 4,096 bytes. `merchantReference` may be at most 255 UTF-8 bytes. If a parameter name is repeated, Anyway keeps only its first value. Checkout rejects a URL that exceeds these limits. | Field | Intended use | Query behavior | | ------------------- | -------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | | `merchantReference` | One stable business correlation value, such as a purchase or cart ID | The orders list supports the `merchant_reference` filter | | `merchantMetadata` | Additional string key-value context, such as an internal user ID or acquisition source | Returned with the order; arbitrary metadata keys are not filters | For the example above, order payloads contain: ```json theme={null} { "merchantReference": "PUR_456", "merchantMetadata": { "merchant_reference": "PUR_456", "user_id": "USR_123", "source": "web" } } ``` Use a URL builder so names and values are encoded correctly. Do not put secrets or raw personal data in these parameters: they are visible to the buyer and may appear in browser history and request logs. ## What happens at checkout The hosted checkout shows only methods available for the buyer's device, country, currency, and provider eligibility. It may offer cards, Apple Pay or Google Pay, Link, Klarna, Cash App Pay, and bank payment. The page follows the buyer's own language. See [supported payment methods](/mor/payment-methods) for details. Anyway hosted checkout with card and wallet payment options The buyer opens the Anyway payment link. Anyway creates a checkout attempt and keeps your order reference and metadata attached. The buyer completes the selected payment flow. Anyway confirms the payment and creates or updates the corresponding order. For platform-collected Card / USD payments, the sale is added to your Finance ledger asynchronously. If you configure the optional success URL, it must be a valid HTTPS URL. Anyway returns the buyer to it after confirmation and echoes the custom query parameters together with `anyway_order_id`, `status`, and the signed callback proof when available. The same correlation fields are available in order webhooks and Merchant API order responses. Verify the order status on your server before delivering high-value goods. Query parameters and `merchantMetadata` are buyer-visible input. Use them for correlation and context, not as the sole authorization or pricing decision. ## Manage products and links The Products list can filter `PUBLISHED`, `DRAFT`, and `ARCHIVED` items. Open a published product to archive it or an archived product to republish it. From the product overview, you can also edit its name or description, review existing payment links, create another link for a supported payment method, and copy a public URL. After creating a product, the app opens a success dialog with **Copy payment link**, **Preview checkout**, and **Done**. **Done** returns to Products. Adding a link to an existing product opens the same dialog; closing it returns to the product overview. You can also copy a link from the overview. ## Safe sharing checklist * Share `paymentLinkUrl` or a derived URL that changes only its encoded query parameters. * Keep `merchantReference` stable and unique in your system. * Use webhooks as the server-side payment signal. * Make fulfillment idempotent so the same paid event cannot deliver twice. * Compare the order amount and currency with your own product record. # Agents Quickstart Source: https://docs.anyway.sh/features/sandbox Create an agent wallet, fund it, and make a paid API call. ## 1. Install the CLI ```bash theme={null} npm install -g @anyway-sh/cli ``` ## 2. Create your first agent wallet ```bash theme={null} anyway login --agent-wallet ``` This opens one browser flow that: 1. signs you in; 2. creates the owner wallet if needed; 3. creates an agent wallet; and 4. securely returns the Agent Wallet Key to the CLI. The key is revealed once. Store the downloaded backup securely and never commit it, paste it into chat, or include it in logs. For a non-interactive environment, begin the device flow and resume it after the owner approves: ```bash theme={null} anyway login --agent-wallet --non-interactive anyway login --continue anyway wallets agents create --continue ``` Run both continuation commands in order; the first completes login and the second saves the Agent Wallet Key. Repeat a continuation command while its status is pending. ## 3. Fund the wallet Open [Agent Wallets](https://app.anyway.sh/wallets?view=agent), then: 1. add funds to the buffer balance; 2. select **Distribute funds**; 3. choose the agent wallet and amount. Credits and USDC are different: * Credits are shared by the organization and are used first for eligible SuperAPI calls. * USDC is allocated to a specific agent wallet. ## 4. Confirm the agent identity ```bash theme={null} export ANYWAY_AGENT_WALLET_KEY="" anyway wallets agents whoami anyway wallets agents policies anyway wallets agents credit-balance ``` `whoami` identifies the agent and wallet. `credit-balance` reports the organization's USD Credits, not the wallet's USDC balance. ## 5. Discover and call a paid API ```bash theme={null} curl https://marketplace-prod.anyway.sh/v1/api/directory curl https://marketplace-prod.anyway.sh/v1/api/info/{upstream_id} ``` Use the directory entry's `id` as `upstream_id`, then copy the callable x402 URL from the info response's `curl_x402` field: ```bash theme={null} anyway superapi call "" ``` The CLI makes the initial request, reads the 402 quote, asks for confirmation, signs the payment, retries the call, and prints the API response. Use `--yes` only in an agent runtime where automatic approval is intentional. Wallet balance and spending policies remain the final guardrails. # SuperAPI Source: https://docs.anyway.sh/features/super-api Discover and call paid APIs through one x402-compatible interface. SuperAPI lets an agent discover a service, receive a price quote, authorize payment, and get the API response. Open SuperAPI in the Agents view and copy a ready-made prompt or endpoint example. SuperAPI — paid services with endpoint status and pricing ## Always discover before calling List the available services: ```bash theme={null} curl https://marketplace-prod.anyway.sh/v1/api/directory ``` Then fetch the selected service's current endpoint details: ```bash theme={null} curl https://marketplace-prod.anyway.sh/v1/api/info/{upstream_id} ``` Use the directory entry's `id` as `upstream_id`. Then use the HTTP method, parameters, and x402 URL in the info response's `endpoints` and `curl_x402` fields; do not derive them from the display name. ## Make a paid call With an Agent Wallet Key configured: ```bash theme={null} anyway superapi call "" ``` For a POST endpoint: ```bash theme={null} anyway superapi call "" \ --body '{"query":"open source payment APIs"}' ``` The command: 1. sends the initial request; 2. decodes the returned payment requirement; 3. shows the quote; 4. asks for confirmation; 5. signs with the selected Agent Wallet; 6. retries with the payment signature; and 7. prints the API result. Use `--format json` for machine-readable output. Use `--yes` only when the runtime is intentionally allowed to approve quotes automatically. ## Payment guardrails * Organization Credits are used before wallet USDC when eligible. * The selected agent wallet's spending policy is enforced server-side. * A payment above the policy limit is rejected. * Discovery and info responses should be refreshed instead of cached indefinitely. # Business App Guide Source: https://docs.anyway.sh/features/webapp Find every Business page, shortcut, and account setting in the current Anyway app. The Business view is organized around selling, operating, and understanding your product. ## Navigation map | Area | Page | What it does | | ------------ | ------------- | -------------------------------------------------------------------------------------------- | | Top level | Home | Overview of gross revenue, MRR, orders, and available balance | | Top level | Products | Create, publish, archive, and share products and payment links | | Top level | Customers | Inspect a customer's related orders and subscriptions | | Sales | Subscriptions | Filter recurring subscriptions, inspect renewal orders, and schedule period-end cancellation | | Sales | Orders | Filter, inspect, and export customer orders | | Finance | Income | Review settled income with per-transaction fees and funds availability | | Finance | Payout | Review balances, payout accounts, and payout requests | | Settings | Preferences | Appearance and dashboard language for this device | | Settings | Setting up | The payment setup checklist: verification, API keys, payout accounts | | Profile menu | Developers | Create API keys and configure webhook endpoints | Business Home — gross revenue, MRR, orders, and available balance ## Product switcher and language Use the product switcher beside the Anyway logo to move between **Business** and **Agents**. The active view changes the sidebar without changing your account or organization. English and Simplified Chinese are available from sign-in and the profile menu. Switching languages keeps the current page, session, and form state. User-created content and unknown server messages remain in their original language. ## Command palette Press `⌘K` on macOS or `Ctrl+K` on Windows and Linux. In the Business view the palette navigates to **Home**, **Products**, **Orders**, **Finance**, and the **Documentation**, searches your products by name, and offers the **Create product** and **Export orders** actions plus the color-theme switch. In the Agents view it covers **SuperAPI**, **Agent Wallets**, wallet search, **Create wallet**, and **Connect SDK**. ## Payment setup A brand-new account — no verification application and no setup item completed — is taken once to **Settings → Setting up**, the **Payment setup** checklist. It groups everything required to accept payments by the capability each section unlocks: 1. **Merchant verification** — what you sell, business details, site readiness, and identity; unlocks Card / USD products and payment links. 2. **Payment integration** — an API key and a webhook endpoint; usable from day one. 3. **Settlement** — a payout account (gated until verification is approved) and tax information. The **Application entity** choice at the top — **Business** or **Sole proprietor** — determines which verification items apply. Payment setup — Payment integration and Settlement sections The same checklist stays within reach as a card in the bottom-right corner of every Business page; minimised, it keeps the progress count. See the [Business Quickstart](/quickstart) for the full first-run path. Agent-wallet creation remains on the Agent Wallets page in the Agents view. # Commerce Webhooks Source: https://docs.anyway.sh/features/webhooks Receive signed order and subscription lifecycle events. Use webhooks as the server-side signal that an order or customer subscription changed. A browser success page is useful for the buyer, but it is not a reliable fulfillment trigger. ## Set up an endpoint In the Business profile menu, open **Developers**, then select **Webhooks**. Enter the public HTTPS URL that should receive the selected commerce events. Cache the published Ed25519 public key in your server-side configuration. You may also retain the endpoint ID for configuration tracking. Neither value is a signing secret. Verify the signature against the raw request body before parsing or acting on the event. ## Fulfillment rules * Route behavior by event type. * Use the `webhook-id` header as the delivery idempotency key. * Compare amount, currency, product, and merchant reference with your own records. * Update local subscription state from `subscription.*` events; a scheduled period-end cancellation arrives as `subscription.updated`, while the final stop arrives as `subscription.ended`. * Return a successful response quickly and move slow work to a queue. * Accept retries and out-of-order delivery. * Never move a locally paid order back to pending because an older event arrives. Never log signatures, API keys, full customer payment details, passport images, or payout account details. Review the public key, signature contract, payload, retries, and idempotency rules. Understand subscription status, scheduled cancellation, and renewal orders. # Account Review Source: https://docs.anyway.sh/mor/account-review What Anyway reviews before you can accept payments — website compliance, business model, AIGC compliance, and legal pages Account review covers **basic website compliance + business model / payment compliance + AIGC-specific compliance + legal page compliance**. To protect consumers, keep the payment network secure, and comply with card network, payment partner, and applicable legal requirements, every merchant that wants to accept **Card / USD payments through Anyway's Merchant of Record service** must complete an account review. Crypto (USDC) payments are not gated by this review: they remain available before, during, and after it. As a Merchant of Record, Anyway reviews your business model, website content, products, consumer policies, and potential risks. Passing the review does not grant permanent transaction eligibility. Anyway may continuously review or re-review your account based on subsequent product changes, transaction behavior, dispute rates, refund rates, consumer complaints, or regulatory requirements. ## 1. Review scope — merchant identity Merchants must provide truthful, accurate, and complete personal or business information. Depending on the account type, Anyway may request: * Personal identity information and proof of identity; * Business name, registration information, and registered address; * Ultimate beneficial owner (UBO) information; * The actual operating entity of the website or product; * Settlement account information; * Other materials required for KYC / KYB. Submitting false, forged, impersonated, or misleading information may result in a rejected application or account suspension. ## 2. Website basic requirements Before applying for review, your website or product should be substantially complete and publicly accessible. A landing page only, a "coming soon" page, or a site where the core features cannot be tried usually cannot pass review. At a minimum, your website should clearly present: ### Product information Users should be able to clearly understand: * What product or service you offer; * The product's main features; * How the product is used; * What users receive after purchase; * Whether the product is a subscription, credits-based, one-time purchase, or another pricing model. Do not use false, exaggerated, or misleading product descriptions. ### Pricing information If the website offers paid services, it should clearly display: * The price of goods or services; * The billing cycle; * Whether auto-renewal applies; * The price and purpose of Credits / Tokens / Points; * Whether charges begin automatically after a free trial ends; * Any other fees that may be charged to consumers. Do not add mandatory fees after payment that were not previously disclosed. ### Contact information The website must provide a genuine, actively maintained customer support channel, for example: * A support email address; * A Contact Us page; * A live chat / support system. Consumers must reasonably be able to reach the merchant. ### Legal pages At a minimum, the website should publicly provide: * Terms of Service / Terms & Conditions * Privacy Policy * Refund Policy If you offer AI-generated content (AIGC), you should also provide: * An Acceptable Use Policy (AUP) or an equivalent AI Content Policy These pages should be accessible from the website footer, checkout, or another reasonable location. ## 3. Terms of Service Merchants must provide Terms of Service consistent with their actual business model. At a minimum, the Terms of Service should cover: * The merchant or operating entity; * The products and services offered; * User account rules; * How charges work; * Auto-renewal rules; * How to cancel; * Rules for Credits / Tokens / Points (if applicable); * Refund policy; * Prohibited user conduct; * Intellectual property; * AI services and third-party model disclosures (if applicable); * Service suspension and account termination rules; * A link to the Privacy Policy; * Contact information. ### Auto-renewal If the product uses a subscription model, you must clearly state: * The subscription price; * The monthly / annual billing cycle; * That the subscription renews automatically; * That the user authorizes recurring charges; * How to cancel the subscription. Users must be able to cancel through a reasonable, clear process. Deliberately complex or misleading cancellation flows are not allowed. ### Credits / Points If the product sells Credits, Tokens, Points, or similar virtual allowances, you should state: * What the credits can purchase; * Whether they expire; * Whether they are refundable; * Whether they are transferable; * What happens to remaining credits when an account is closed; * Whether an auto-top-up mechanism exists. If auto-top-up is enabled, you must obtain the user's explicit authorization in advance. ### Refunds The refund policy must clearly state: * Which situations qualify for a refund; * Which situations do not; * The refund request window; * How to request a refund; * The expected processing time. The refund policy must be accessible before the user pays. ## 4. Privacy Policy Merchants must publicly provide a Privacy Policy that matches their actual data-handling practices. At a minimum, it should cover: * Who the data controller is; * What personal information is collected; * Why it is collected; * How the data is used; * Cookie / analytics usage; * Whether data is shared with third-party service providers; * Data retention periods; * Cross-border data transfers (if applicable); * Users' rights to access, correct, and delete their data; * Rules for handling minors' data; * A contact for privacy questions. If you use third-party analytics, AI, cloud, or login services, disclose them as appropriate. Where payment card information is handled by Anyway and its payment partners, merchants should not claim to store full card details themselves unless that is actually the case. ## 5. AIGC-specific review If your product lets users generate AI content via prompts, uploaded images, video, audio, or other inputs, Anyway performs an additional AIGC compliance review. This includes, but is not limited to: AI image generation, AI video generation, AI avatars, AI face swap, AI voice / voice cloning, AI characters / companions, AI chat, AI image editing, AI video editing, AI content generation platforms, and AI wrappers built on third-party models. ### Independent branding The product must have its own brand, name, and positioning. Allowed: > Powered by / Built with OpenAI, Gemini, Claude, Flux, Kling, etc. Not allowed (unless you actually hold the brand owner's authorization): > Official ChatGPT Generator, Official Gemini Video Generator, OpenAI Official Image Generator Do not use third-party AI models' logos, trademarks, or names in a way that leads consumers to believe the product is officially operated by the model provider. ### Underlying model disclosure For AI image, video, and other generative AI products, reasonably disclose the main underlying models or model providers actually used. For example: > Our service uses third-party AI models including OpenAI, Google Gemini, Flux and Kling. If users can choose between models, showing model names directly in the product UI is sufficient. Do not: * Invent models that do not exist; * Misstate model versions; * Pass off third-party models as proprietary models; * Imply an official partnership with a model provider that does not exist. ## 6. AIGC content moderation AIGC merchants must maintain a genuine, effective content safety review mechanism. Merely stating "illegal content is prohibited" in the Terms of Service is not sufficient. The platform should moderate content at two stages, at minimum: * **Before generation:** review user prompts, uploaded content, or other generation instructions. * **After generation:** review AI output before it is displayed or delivered to the user. If the platform has a public gallery, community, feed, or content-sharing feature, published content should also be continuously moderated. Merchants may use third-party moderation APIs, AI content-safety models, in-house review systems, keyword plus semantic models, human review, or any combination of these. During account review or ongoing risk review, Anyway may ask merchants to explain or provide evidence of their content moderation mechanisms. ## 7. AIGC prohibited content AIGC products must take reasonable measures to prevent users from generating, uploading, distributing, or selling the following content. ### Child safety Strictly prohibited, with zero tolerance: * CSAM; * Sexual or sexualized content involving minors; * Sexual innuendo directed at minors; * AI-generated or fictional sexual content depicting minors. ### Pornographic and NSFW content AI services whose primary purpose is generating pornography, sexually explicit content, or adult entertainment are not allowed. Merchants must not let users bypass content moderation through features such as an "NSFW Mode," "Uncensored Mode," "Adult Mode," or disabling safety filters. ### Deepfakes and impersonation Do not generate or distribute deepfake content of real people that could mislead others, without the person's consent. In particular: * Non-consensual sexual deepfakes; * Celebrity sexual deepfakes; * Identity impersonation; * Fraud; * Fake endorsements. ### Violent and extremist content Do not generate: * Extremely gory content; * Terrorist propaganda; * Extremist propaganda; * Content depicting serious violence against real people; * Content encouraging real-world violence. ### Hateful content Do not generate content that seriously demeans, discriminates against, dehumanizes, or promotes violence against protected groups. ### Intellectual property infringement Merchants should take reasonable measures to prevent: * Unauthorized reproduction of copyrighted content; * Impersonation of third-party brands; * Unauthorized trademark use; * Mass generation of clearly infringing content. If the product involves AI image, video, or character generation, provide a reasonable channel for intellectual property complaints. ## 8. Acceptable Use Policy (AUP) AIGC merchants must publicly provide an Acceptable Use Policy, or include a complete AI Content Policy in their Terms of Service. At a minimum, the AUP should specify: * What content may not be generated; * What conduct is prohibited; * How the platform performs automated content moderation; * Whether human review exists; * How users can report violations; * How the platform handles violating content; * What penalties violating accounts may face; * How users can appeal (if applicable). The moderation the platform actually enforces must match its published policy. Publishing an AUP purely to pass review, while the product actually lets users bypass the restrictions, is prohibited. ## 9. Reporting and complaints AIGC products should provide a genuine, working reporting channel, for example: * abuse@\[domain] or report@\[domain]; * A website report form; * An in-product Report button; * A support email address. Platforms that publish user-generated content publicly should offer content-level reporting. Reports involving child safety, fraud, deepfakes, or intellectual property should be handled with priority. ## 10. Protection of minors If the product may be used by minors, merchants must take reasonable protective measures appropriate to the product and its target markets. High-risk AI products may be required to: * Set a minimum age; * Provide an age declaration; * Implement an age gate; * Verify age for sensitive features; * Block minors from adult or otherwise restricted content. For products involving pornography, adult entertainment, or other categories Anyway prohibits, age verification does not make the product eligible for Anyway's payment services. ## 11. Prohibited and restricted categories All merchants must also comply with Anyway's [Prohibited & Restricted Business Categories](/mor/prohibited-and-restricted) policy. If a product falls into a category Anyway explicitly prohibits, it cannot pass account review even if the website materials are complete, KYC/KYB is done, and Terms of Service, Privacy Policy, and content moderation are all in place. For restricted categories, Anyway may require additional business descriptions, product demos, licenses, authorization documents, content moderation evidence, age verification, supplier agreements, transaction data, or other risk controls. ## 12. Review outcomes Account review may result in: The account passes review and can accept payments within the business scope approved by Anyway. Anyway needs further materials — for example: website content changes; additions to the Terms / Privacy / Refund Policy; a product demo; a business model explanation; an AI content moderation plan; supplemental KYC/KYB; or authorization and other supporting documents. Anyway may reject the application if the business falls into a prohibited category, its risk exceeds Anyway's risk tolerance, or it cannot meet payment network and compliance requirements. ## 13. Ongoing review Passing account review is not the end of the process. Anyway continuously monitors account risk. The following may trigger a re-review: * Major changes to the product or website; * New business lines; * New AIGC / NSFW / UGC features; * Domain changes; * Sudden large increases in transaction volume; * Abnormal refund rates; * Abnormal chargeback rates; * Increased fraudulent transactions; * Large volumes of consumer complaints; * Intellectual property complaints; * Notices from regulators or payment networks; * Actual operations inconsistent with the information provided at application. After approval, merchants must not operate businesses that Anyway has not approved by modifying the product, hiding pages, redirecting domains, or other means. Material business changes should be reported to Anyway promptly. ## Pre-submission checklist Before submitting your account for review, confirm: **Website** * [ ] The website is live * [ ] The product's features and business model are clear * [ ] Pricing is public and transparent * [ ] There is a genuine, working support email * [ ] Users can actually purchase and use the product **Legal policies** * [ ] Terms of Service * [ ] Privacy Policy * [ ] Refund Policy * [ ] Auto-renewal rules (if applicable) * [ ] Credits / Points rules (if applicable) * [ ] AUP / AI Content Policy (AIGC products) **AIGC** * [ ] Independent branding * [ ] No impersonation of underlying model providers' official products * [ ] Main underlying AI models disclosed * [ ] Prompt-level content moderation in place * [ ] AI output content moderation in place * [ ] NSFW / CSAM / deepfake and other high-risk content blocked * [ ] User reporting mechanism in place * [ ] Process for handling violating content and accounts in place **Payments** * [ ] Users see the price before paying * [ ] Users clearly know whether auto-renewal applies * [ ] Users can easily cancel subscriptions * [ ] The refund policy is accessible before payment * [ ] Checkout matches the price and product shown on the website Completing these items improves review efficiency but does not guarantee approval. Anyway makes the final decision based on your specific business model, target markets, payment network requirements, and overall risk level. Make sure the information you submit matches what you actually operate. Concealing your real business, operating unapproved products after passing review, letting users bypass content safety measures, or offering prohibited businesses through other domains may lead to immediate account suspension, delayed settlement, or termination of service. # Fees Source: https://docs.anyway.sh/mor/fees Anyway MoR pricing for transactions, refunds, payouts, and disputes **The standard successful-transaction fee is 3.9% + \$0.50.** There are no monthly or setup fees. Agreement-specific rates may differ, so use the fee posted for each completed order as the source of truth. ## Successful transactions The standard rate for cards and digital wallets is: | Payment method | Percentage | Fixed | | ----------------------- | ---------- | ------ | | Cards & digital wallets | 3.9% | \$0.50 | **Standard-rate example (card):** > Pre-tax sale amount: \$1,000 > > Fee: \$1,000 × 3.9% + \$0.50 = \$39.50 > > Net amount: \$960.50 You can see the fee and net earnings for every transaction on the [Income page](https://app.anyway.sh/finance/income): Income page with per-transaction Anyway fee and net earnings ## Refunds The fee posted for the original successful transaction is not returned, whether the refund is full or partial. ## Payouts | Item | Fee | | ------------------- | -------------------------- | | Standard payout fee | 1% of the payout amount | | Minimum fee | \$10.00 per payout request | The standard payout fee is charged per request. When 1% is below \$10, the \$10 minimum applies. The final fee may be adjusted or waived, so the fee recorded when the payout is processed is the source of truth. The final amount received depends on the receiving bank. Intermediary bank fees, currency conversion, and the bank's own crediting rules may cause differences. Request payouts from the [Payout page](https://app.anyway.sh/finance/payout): Payout page with available balance by currency and payout accounts ## Disputes (chargebacks) Dispute fees use the amount assessed by the payment provider and posted to your account. The amount is not fixed and may vary by provider, network, currency, or agreement. # Supported Payment Methods, Countries & Currencies Source: https://docs.anyway.sh/mor/payment-methods Payment methods Anyway accepts from your customers, and the currencies and regions supported for payouts ## Accepting payments The hosted checkout shows only the methods available to each buyer. Availability depends on the buyer's device, country, currency, and payment-provider eligibility. | Category | Methods | | ------------- | ---------------------------------------------------- | | Credit cards | Visa, Mastercard, JCB, Amex | | Wallets | Apple Pay or Google Pay, plus Link | | Other methods | Klarna, Cash App Pay, and bank payment when eligible | Payment-method availability can change as provider configuration and regional eligibility change. The methods shown on the hosted checkout are the source of truth for that buyer. What a customer may see at checkout: Anyway checkout with card, Apple Pay, Link, Klarna, Cash App Pay, and bank payment options ## Payout accounts Payout requests are denominated in USD and reviewed manually. The current payout-account options are: | Destination | Account type | Receiving currency | | -------------- | ---------------------- | ------------------ | | United States | ACH | USD | | United Kingdom | Bank account | GBP | | Hong Kong | Bank account | USD or HKD | | Mainland China | Bank account or Alipay | CNY | The receiving currency identifies the destination transfer route. It does not create a non-USD balance in Anyway. See [Finance & Payouts](/billing/finance-and-payouts#supported-payout-accounts) for account details and [Fees](/mor/fees#payouts) for payout pricing. # Prohibited & Restricted Business Categories Source: https://docs.anyway.sh/mor/prohibited-and-restricted Products, services, and business types that require additional review or may not be sold through Anyway **Last updated: August 2026** This page lists products, services, and business types that either require additional review or may not be sold through Anyway. As a Merchant of Record (MoR), Anyway may act as the seller of record in relevant transactions and assume responsibilities relating to payment processing, consumer protection, refunds, disputes, taxes, and compliance. To comply with applicable laws and regulations, card network rules, acquiring bank and other financial partner requirements, and to manage fraud, chargeback, consumer protection, and other risks, certain products and services may only be sold after specific conditions are met and Anyway has given prior approval. Other products and services are strictly prohibited from being sold through Anyway. We classify relevant businesses into: * **Restricted Businesses:** Businesses that may be supported in principle, but require additional compliance and risk review and must receive explicit approval from Anyway before sales begin. * **Prohibited Businesses:** Businesses that may not be sold, promoted, provided, or processed through Anyway. The current self-service application requires you to confirm that your business is not in a restricted category. It does not provide an exception path for restricted businesses. If your business falls into a restricted category, do not submit that confirmation. Contact Anyway before applying. Any approval granted by Anyway for a restricted business category applies only to the specific business model, website, products, and services disclosed at the time of approval. Merchants may not treat such approval as automatic approval for any other business, product, website, or service. Anyway may impose conditions on an approval, re-review, suspend, or revoke an approval based on laws and regulations, card network rules, financial partner requirements, consumer complaints, chargeback activity, or Anyway's own risk assessment. Merchants are responsible for accurately and completely disclosing their actual business. Selling prohibited categories, or selling restricted categories without approval, may result in declined transactions, account suspension or termination, delayed settlements, and restrictions on relevant funds to the extent permitted by law, card network rules, or Anyway's terms of service. If you are unsure whether your product or service complies with these requirements, please contact Anyway before you begin selling. ## Restricted Businesses The following products and services require additional review. **Before receiving explicit approval from Anyway, merchants may not begin selling these products or services through Anyway.** The current self-service application does not support this approval path, so contact Anyway before applying. Anyway may require merchants to provide company information, business model descriptions, relevant licenses, product screenshots, content moderation mechanisms, consumer protection measures, supply chain documentation, or other supplemental materials. ### 1. AIGC (AI-generated content) Includes products and services that provide AI-generated text, images, audio, video, virtual characters, or other generative content. **Conditions and notes:** * Merchants must not generate, sell, or distribute pornographic, sexually explicit, or other prohibited adult content. * Merchants must not generate or distribute illegal, harmful, fraudulent, or rights-infringing content. * Merchants should maintain appropriate content safety mechanisms, including screening and restricting prohibited-content-related keywords, models, prompts, or outputs. * Merchants should maintain reasonable user reporting and content handling mechanisms. * AI-generated content must not infringe any third party's copyright, trademark, likeness rights, privacy rights, or other intellectual property rights. * Where applicable, merchants should reasonably disclose to users that the content is AI-generated. * Products aimed at minors should implement appropriate minor protection measures. * Anyway may require merchants to disable or restrict specific models, features, prompts, content categories, or user-generated content capabilities before providing services. ### 2. Content creation and user-generated content platforms Includes platforms that allow users to upload, publish, sell, subscribe to, or earn income from content. **Conditions and notes:** * Merchants must maintain content moderation and reporting mechanisms. * Merchants must prohibit adult content, illegal content, and intellectual property infringement. * Merchants should maintain a process for handling repeat infringers. * Merchants must be able to promptly remove illegal or infringing content. * Merchants must not allow creators to use the platform for undisclosed third-party payment collection, person-to-person money transfers, or other financial activities. ### 3. Games of skill **Conditions and notes:** * Game outcomes must be primarily determined by participants' skill, rather than chance or luck. * Games must not constitute gambling, betting, or lotteries under applicable law. * Merchants must clearly and completely disclose participation rules, fees, and reward rules. * Rewards with real economic value may require additional review. * Age verification must be implemented where applicable. ### 4. Streaming services **Conditions and notes:** * Merchants must own the legal copyright, license, or other authorization for the content being distributed. * Services must not include unauthorized films, music, sports events, or other copyrighted content. * Merchants must comply with applicable digital rights management (DRM) and intellectual property protection requirements. ### 5. IPTV **Conditions and notes:** * Only legally authorized or licensed content may be distributed. * Merchants must be able to provide proof of relevant content authorization or licensing. * Unauthorized retransmission of television, sports events, films, or other copyrighted channels or content is prohibited. ### 6. Online education platforms **Conditions and notes:** * Any claimed certificates, certifications, degrees, or related qualifications must be truthful and accurate. * Merchants must not make false promises regarding employment, income, exam pass rates, or professional qualifications. * Merchants must clearly disclose course content, pricing, and refund policies. * Merchants must not sell essay-writing, exam-taking, forged credentials, or other academic fraud services. ### 7. Subscription services **Conditions and notes:** * Merchants must clearly disclose subscription pricing, billing cycles, and renewal methods before payment. * Automatic renewals must receive the customer's explicit prior consent. * Merchants must provide a reasonable, clear, and easy-to-use cancellation method. * Merchants must not induce customers to subscribe through hidden terms, misleading free trials, or other negative-option practices. * Merchants must not intentionally make subscriptions difficult to cancel. ### 8. In-game virtual items Includes game currency, skins, equipment, and other virtual goods. **Conditions and notes:** * Merchants must have legal authorization to sell the relevant virtual goods. * Merchants must not violate the terms of service of relevant game developers, publishers, or platforms. * Merchants must not facilitate unauthorized secondary-market trading. * Virtual items must not be used for gambling, betting, or gambling-like mechanisms. * Virtual items that can be exchanged for fiat currency, crypto assets, or other assets with real monetary value may be subject to further restrictions. ### 9. VPN / VPS / cloud computing services **Conditions and notes:** * Services must not be marketed as a way to evade laws, regulatory restrictions, or conduct illegal activities. * Merchants must publish a clear Acceptable Use Policy. * Merchants must prohibit use of the service for cyberattacks, malware distribution, fraud, spam, illegal content distribution, or other illegal activities. * Merchants should maintain reasonable abuse complaint and response mechanisms. ### 10. Cloud storage and file-sharing services **Conditions and notes:** * Merchants must maintain infringement complaint and takedown mechanisms. * Services must not primarily operate around pirated content, cracked software, film or media resources, or other unauthorized content. * Merchants must be able to handle illegal content, malware, and other high-risk files. * Anyway may require a detailed explanation of content moderation and abuse prevention mechanisms. ### 11. Computer software and software stores **Conditions and notes:** * Software sold must be properly licensed. * Selling cracked software, pirated software, or malware is prohibited. * Unauthorized resale of software licenses, accounts, or activation keys is prohibited. * Merchants must not provide software used to conduct cyberattacks, unauthorized access, information theft, or other illegal activity. ### 12. Luxury goods, high-value goods, and valuables **Conditions and notes:** * Product authenticity must be verifiable. * Merchants must be able to provide appropriate procurement, provenance, or authorization documentation. * Counterfeit goods must not be sold. * Anyway may impose additional transaction or settlement limits based on product value, transaction amount, and chargeback risk. ### 13. Dating and matchmaking services **Conditions and notes:** * Appropriate age restrictions must be implemented. * Services must not involve prostitution, escort services, or any commercial sexual services. * Merchants must maintain fraud, harassment, and abuse prevention mechanisms. * Merchants must comply with local laws and regulations regarding online dating and matchmaking services in the target markets. * This category may be entirely prohibited in certain jurisdictions. ### 14. Travel and travel booking services Includes travel bookings, travel packages, and other travel services with long fulfillment periods. **Conditions and notes:** * Merchants must hold applicable travel service licenses or qualifications. * Merchants must clearly disclose cancellation and refund policies. * Anyway may impose reserves, delayed settlements, or other risk controls based on booking periods, fulfillment periods, refund risk, and chargeback risk. * Airlines, cruises, charters, timeshares, and other high-risk travel businesses may not be supported. ## Prohibited Businesses The following products, services, and business models may not be sold, promoted, provided, or processed through Anyway. ### 1. Illegal products and services Includes, but is not limited to: * Illegal drugs, controlled substances, and related drug paraphernalia * Equipment used to manufacture, process, or use illegal drugs * Forged identity documents, fake credentials, false certificates, or other fraudulent documents * SIM card cloning devices, communication jamming devices, and other illegal telecommunications equipment * Products or services used to conduct or assist illegal activity * Human trafficking or any product or service that facilitates human exploitation * Any product or service that is illegal in the merchant's jurisdiction or target sales market ### 2. Adult content and services Merchants may not sell, provide, or monetize through Anyway: * Pornographic or sexually explicit images, videos, text, audio, or other content * Adult content primarily intended for sexual gratification * AI-generated pornographic, NSFW, or sexually explicit content * Adult live streaming or adult live chat * Prostitution, escort services, erotic massage, or other commercial sexual services * Other products or services primarily intended for pornography or sexual services ### 3. Intellectual property infringement Merchants may not sell or provide: * Unauthorized distribution of films, music, books, software, games, or other copyrighted content * Counterfeit goods * Products that make unauthorized use of third-party brands, trademarks, characters, likenesses, or other intellectual property * Cracked software, pirated software, or unauthorized software licenses and activation keys * Products or services that directly infringe, or are primarily used to facilitate infringement of, third-party copyrights, trademarks, patents, trade secrets, likeness rights, or other legal rights ### 4. Fraudulent, misleading, and unfair business practices Prohibited practices include, but are not limited to: * Pyramid schemes and Ponzi schemes * Multi-level marketing programs that primarily generate income through recruiting new members * "Get rich quick" or "overnight wealth" schemes * Products that guarantee investment returns or make clearly unrealistic income promises * Fake endorsements, fake reviews, or false consumer testimonials * Hidden prices, hidden subscriptions, or misleading free trials * Deceptive or predatory lending, investment, or business opportunities * Selling fake or artificially generated social media engagement, including followers, likes, views, comments, or other fake traffic * Document forgery services * Other businesses that Anyway reasonably considers deceptive, unfair, predatory, or seriously harmful to consumers ### 5. Gambling and betting Prohibited businesses include: * Online casinos * Poker and other games of chance * Sports betting * Sports predictions involving cash or rewards with real economic value * Lotteries * Paid-entry sweepstakes * Penny auctions * Games or contests that are centered on money or rewards with real economic value and primarily depend on chance or random outcomes ### 6. Firearms, weapons, explosives, and dangerous goods Merchants may not sell: * Firearms, handguns, rifles, shotguns, or other regulated weapons * Firearm parts and regulated accessories * Ammunition * Explosives * Illegal knives and other regulated weapons * Toxic, flammable, radioactive, biological, or other hazardous materials * Goods prohibited by arms control, sanctions, or export control laws ### 7. Illegal or high-risk financial services Prohibited businesses include: * Unlicensed money transmission or funds transfer services * Unlicensed currency exchange services * Unlicensed lending or credit services * Paying loans with credit cards * Check cashing * Illegal debt collection * Shell banks * Unapproved payment aggregation or payment facilitation services * Collecting payments on behalf of undisclosed third-party merchants * Other financial services that require a license but do not hold the appropriate license ### 8. Cryptocurrency and high-risk digital asset businesses Prohibited businesses include: * Unlicensed cryptocurrency exchanges or related financial services * Initial Coin Offerings (ICOs) that violate applicable securities laws * Cryptocurrency mining or staking investment products * NFT secondary markets primarily used for speculative trading * Other unlicensed digital asset financial activities Lawful and appropriately regulated digital asset businesses still require separate review by Anyway. Anyway does not guarantee that such businesses will be approved. ### 9. Stored value, top-ups, and cash equivalents Unless explicitly approved in writing by Anyway, the following are prohibited: * Prepaid cards or reloadable payment cards * Virtual credit card (VCC) top-ups or fund loading * Stored-value balances issued or accepted by third parties * Virtual points that are broadly redeemable or transferable * Converting credit card funds into cash, cash equivalents, or other payment instruments * Other businesses that may constitute money transmission, cash-out, or cash-equivalent transactions Merchant-issued points or credits that can only be used to purchase the merchant's own goods or services and cannot be cashed out or transferred may be reviewed separately based on the specific business model. ### 10. Malware and cybercrime-related services Merchants may not sell, distribute, or provide: * Malware * Ransomware * Spyware * Credential theft tools * Tools used for unauthorized access to third-party systems * Software or services used for cyberattacks, fraud, or other illegal activity ## Sanctioned and high-risk jurisdictions Anyway must not be used, directly or indirectly, to violate applicable economic sanctions, export controls, or other trade restrictions. Anyway does not support transactions involving countries, regions, individuals, or entities prohibited by applicable laws, regulations, or financial partner policies. This includes, but is not limited to, individuals, entities, and regions restricted by the U.S. Department of the Treasury's Office of Foreign Assets Control (OFAC) and other applicable sanctions regimes. Merchants must not: * Provide products or services to sanctioned parties; * Process transactions on behalf of sanctioned parties; * Knowingly conceal the actual parties to a transaction or ultimate beneficial owners; * Evade sanctions restrictions through agents, third-party companies, or other means. The specific scope of restrictions may change at any time based on laws, regulations, and financial partner requirements. ## Charitable, political, and religious organizations Charitable organizations, political organizations, religious organizations, and organizations that primarily accept donations rather than sell goods or services are generally not suitable for Anyway's Merchant of Record model. Unless explicitly approved by Anyway, merchants may not use Anyway to: * Accept charitable donations; * Accept political contributions; * Conduct political fundraising; * Conduct religious donations or fundraising; * Process donations on behalf of nonprofit organizations. This restriction does not mean that the relevant organizations or activities are themselves illegal. Rather, the transaction nature of these activities is generally not suitable for Anyway's Merchant of Record service model. ## Prohibited misuse of Anyway Regardless of the merchant's industry, the following conduct is prohibited: * Using false, forged, or misleading identity or business information to register for Anyway; * Impersonating another individual, business, or organization; * Concealing the actual business model, website, product, or service; * Changing to another high-risk business after approval without authorization; * Processing payments on behalf of third-party merchants not disclosed to Anyway; * Using one approved website to collect payments for another unreviewed website; * Using Anyway for card testing or fake transactions without genuine goods or services; * Splitting, structuring, or manipulating transactions to evade fraud, chargeback, transaction monitoring, or reporting thresholds; * Creating fictitious orders, transactions, or customers; * Using, or directing affiliates to use, cards to create fake transactions; * Processing, selling, or sharing cardholder payment information without authorization; * Using Anyway for money laundering, terrorist financing, sanctions evasion, or other financial crimes; * Distributing malware, ransomware, spyware, or other malicious programs through Anyway. The above conduct may result in immediate account suspension or termination and may trigger further compliance investigations. ## Business changes and ongoing review After a merchant is approved by Anyway, the merchant remains responsible for ensuring that its actual business continues to comply with this policy. If any of the following material changes occur, the merchant should notify Anyway promptly: * Website domain changes; * Material changes to the products or services actually sold; * Addition of new business lines; * Addition of user-generated content or marketplace features; * Addition of adult, high-risk financial, virtual asset, or other restricted features; * Changes to the business entity, actual controller, or ultimate beneficial owners; * Material changes to target sales countries or regions. Anyway may conduct ongoing monitoring or periodic re-review of merchants and may require supplemental information. ## Anyway's review and enforcement rights The categories listed on this page are not exhaustive. Even if a product or service is not expressly listed in this policy, if Anyway determines based on applicable laws and regulations, card network rules, acquiring bank or other financial partner requirements, consumer protection requirements, fraud risk, chargeback risk, reputational risk, or other reasonable risk factors that the business is not suitable for processing through Anyway, Anyway may: * Require additional information; * Impose additional restrictions on the business; * Set transaction or settlement limits; * Require reserves or extend settlement periods; * Suspend specific products or features; * Suspend transaction processing; * Refuse or terminate service. Merchants may not assume that a business has been approved merely because the category is not expressly listed in this policy. ## Questions and compliance If you are unsure whether your business, product, or service falls into a restricted or prohibited category, please contact Anyway before launch or before you begin selling. For restricted categories, please provide truthful and complete business information to Anyway. **You may begin processing relevant transactions only after receiving explicit confirmation from Anyway.** Do not use the current self-service application to request that approval. [support@anyway.sh](mailto:support@anyway.sh) # What is a Merchant of Record? Source: https://docs.anyway.sh/mor/what-is-mor How Anyway acts as the Merchant of Record for eligible sales, including current payment, subscription, refund, and tax limitations A **Merchant of Record (MoR)** is the legal entity that sells goods or services to the consumer. When a SaaS or digital product company uses Anyway, the consumer pays Anyway, which appears on the invoice as the contractual counterparty of the sale. ## Anyway's role as MoR For eligible MoR transactions, Anyway is the seller of record and the buyer's contractual counterparty. The current product supports platform-collected payments, recurring Card / USD subscriptions, refunds, and chargeback handling. Availability depends on the payment method and market. Tax treatment depends on the transaction and applicable law. Automated per-order tax calculation, collection, and remittance has not launched. Current orders do not include a separate tax amount. Supports hosted payment links, one-time payments, recurring Card / USD subscriptions, renewal order tracking, and cancellation at the end of the billing period. Handles refund and chargeback workflows for eligible MoR transactions. For the full legal terms, see the [Anyway MoR Buyer Terms](https://anyway.sh/terms/mor-buyer). ## Next steps Transaction, refund, payout, and dispute fees Supported payment methods, countries, and payout currencies What can and cannot be sold through Anyway What Anyway reviews before you can accept payments # Business Quickstart Source: https://docs.anyway.sh/quickstart Open the Business view, create a product, take your first payment, and prepare a payout. This guide starts at sign-in, shows how to enter the Business view, and then takes you to a shareable payment link and your first sales record in Finance. This quickstart follows the Card / USD path, so merchant verification comes before product creation. Open the [Anyway app](https://app.anyway.sh) to begin. Business and Agents are two views in the same app, and you can switch between them at any time. ## 1. Enter the Business view Open [app.anyway.sh](https://app.anyway.sh) and sign in. On first use in a browser, the app opens in the **Business** view by default; later visits in that browser restore the last view you used. Check the product name at the top of the left sidebar. If it shows **Business**, continue. If a previous session remembered **Agents**, open the product switcher and select **Anyway Business**. A brand-new account is taken once to **Settings → Setting up** — the **Payment setup** checklist. It tracks everything required to accept payments and get paid out, grouped by the capability each section unlocks: * **Merchant verification** — unlocks Card / USD products and payment links; * **Payment integration** — API keys and webhooks, usable from day one; * **Settlement** — payout accounts and tax information. Payment setup — fresh account at 0/7 with the corner progress card At the top of Payment setup, choose whether you apply as a **Business** or a **Sole proprietor**. This determines which information merchant verification asks for — a business also adds its business details. The company-documents row shown for businesses is marked **Awaiting backend**: it cannot be submitted in the app yet and does not count toward completion. The same checklist stays available as a card in the bottom-right corner on every Business page. Minimise it and the progress count remains visible; it disappears once everything is complete. The left sidebar includes **Home**, **Products**, **Customers**, **Sales** (Subscriptions, Orders), **Finance** (Income, Payout), and **Settings**. To return to Agents, open the same switcher and select **Anyway Agents**. Switching views does not require another account or a page rebuild. ## 2. Complete merchant verification Complete the **Merchant verification** section of Payment setup and wait for the status to reach **Approved** before creating a Card / USD product. Go to **Settings → Setting up**. Actions that start, continue, or update the application lead here. While the application is under review, the Payout page offers **Refresh status**. A rejected application offers **Contact support** instead. Complete **Tell us what you sell**, **Add your business details** (business accounts), **Confirm your site is ready**, and **Verify your identity**. Each row opens its form in place. Review the information and submit it for verification. If more information is requested, update the application and submit it again. The verification items belong to one reviewed application. After approval, editing any of them sends the whole application back to review. Until it is approved again, new Card / USD products, payment links, and payout accounts are unavailable. Existing payment links and payouts keep working. See [Business verification](/features/business-verification) for the application workflow and statuses. ## 3. Create a product In the Business view, select **Products**, then **Create product**. Add a product name, description, price, currency, and pricing configuration. Choose a payment method and complete the setup shown in the form. Select **Create Product**. Anyway opens a success dialog with **Copy payment link**, **Preview checkout**, and **Done**. Selecting **Done** returns to Products. You can also open the product and copy its payment link from the overview. ## 4. Take the first payment Open the public payment link in a separate browser session to preview the buyer experience. After a successful payment: * the order appears in **Orders**; * a platform-collected Card / USD sale appears in **Finance** after a short processing delay. ## 5. Prepare payouts Adding your first payout account is the **Settlement** item of Payment setup. Merchant verification must be **Approved** before you can add it. The verification action on the Payout page changes with the application state, and the add-account flow stays locked until approval. Payout page on a fresh account — verification banner, zero balance, no payout accounts yet Confirm that merchant verification is **Approved**. In **Finance → Payout** (or from the Settlement section of Payment setup), add a US ACH, UK bank, Hong Kong bank in USD or HKD, Alipay, or China bank payout account. Save additional payout accounts if your organization needs them. When your available USD balance is at least **\$50**, select a saved account and submit a payout request. Learn how balances, transactions, fees, and payout states work. Match a checkout to its order and Finance transaction. # Anyway CLI Source: https://docs.anyway.sh/sdk/cli Use supported Business and Agents workflows from a terminal. ## Install and update ```bash theme={null} npm install -g @anyway-sh/cli anyway update --check anyway update ``` Use `anyway --help` for the installed version's authoritative command list. ## Authentication modes | Mode | Use it for | | ------------------------- | ------------------------------------------------------------------------------------------ | | `anyway login` | Products, orders, wallet ownership, Credits, Dashboard, traces, and developer settings | | `ANYWAY_AGENT_WALLET_KEY` | Agent identity, policy, history, signing, direct payment authorization, and SuperAPI calls | | Local agent record | Selecting a saved Agent Wallet Key without exporting an environment variable | ```bash theme={null} anyway login anyway whoami anyway whoami --refresh anyway logout ``` ### Create an Agent Wallet during login Start the combined Agent Wallet flow: ```bash theme={null} anyway login --agent-wallet ``` For SSH, CI, or an agent runtime, begin the flow and then complete both milestones: ```bash theme={null} anyway login --agent-wallet --non-interactive anyway login --continue anyway wallets agents create --continue ``` Repeat a continuation command while it reports `pending`. ## Products and payment links ```bash theme={null} anyway products list anyway products get PRD_EXAMPLE anyway products create --name "My Product" --price 29.99 anyway products create --name "Crypto Tip" --provider crypto anyway products update PRD_EXAMPLE --name "New name" anyway products publish PRD_EXAMPLE anyway products archive PRD_EXAMPLE anyway products payment-links PRD_EXAMPLE anyway products payment-links PRD_EXAMPLE create --provider crypto --price 9.99 ``` Creating a product or link returns `paymentLinkUrl`. Share the complete Anyway URL exactly as returned; do not parse, reconstruct, or modify it. ## Orders and Dashboard ```bash theme={null} anyway orders list --status paid --page 1 --size 20 anyway orders list --product PRD_EXAMPLE --page 1 --size 20 anyway orders list --format csv anyway dashboard templates anyway dashboard query TEMPLATE_ID --days 30 ``` CSV and JSON output use the same result page and filters as table output. ## Organization wallets and Credits ```bash theme={null} anyway wallets balance anyway wallets transactions anyway wallets credit balance anyway wallets credit ledger anyway wallets credit topup ``` Organization Credits and wallet USDC are different assets. A Credit balance is not withdrawable wallet USDC. ## Agent Wallet management Merchant-login commands manage the organization's wallets: ```bash theme={null} anyway wallets agents create --name "Research Agent" anyway wallets agents create --non-interactive anyway wallets agents create --continue anyway wallets agents list anyway wallets agents reset AGENT_ID anyway wallets agents reset AGENT_ID --non-interactive anyway wallets agents reset AGENT_ID --continue ``` Runtime and local-key commands use an Agent Wallet Key: ```bash theme={null} export ANYWAY_AGENT_WALLET_KEY="" anyway wallets agents import --token "" anyway wallets agents import --token-file ./agent-wallet-key.txt anyway wallets agents list --local anyway wallets agents list --local --offline anyway wallets agents default AGENT_ID anyway wallets agents whoami [AGENT_ID] anyway wallets agents policies [AGENT_ID] anyway wallets agents history [AGENT_ID] --limit 50 anyway wallets agents credit-balance [AGENT_ID] anyway wallets agents forget AGENT_ID --yes ``` `default` and `forget` only change local CLI records. They do not rotate or delete the server-side wallet. ### Sign or authorize a payment ```bash theme={null} anyway wallets agents pay --to 0xRECIPIENT --amount 1.5 anyway wallets agents sign --typed-data-file ./typed-data.json ``` The server enforces the selected wallet's spending policy before signing. ## SuperAPI ```bash theme={null} anyway superapi call "" anyway superapi call "" \ --method POST --body '{"query":"payment APIs"}' ``` Useful flags include `--body-file`, `--header`, `--headers-json`, `--agent`, `--validity-seconds`, and `--yes`. `--yes` skips the quote confirmation; use it only when automatic approval is intentional. ## Setup and wallet initialization ```bash theme={null} anyway setup --check anyway setup anyway setup -y anyway init wallets --type crypto anyway init wallets --type agent ``` `setup` installs the Anyway agent skill for detected compatible agents. ## Traces, developer settings, CLI telemetry, and feedback ```bash theme={null} anyway traces status anyway traces list --limit 20 anyway developer keys list anyway developer keys list --type payment_key anyway developer keys create --name "Production SDK" anyway developer keys delete KEY_ID anyway telemetry anyway telemetry off anyway telemetry on anyway telemetry reset anyway telemetry inspect superapi call anyway feedback "Describe the issue" anyway feedback "Describe the issue" --category bug --attach-last anyway feedback "Describe the issue" --dry-run ``` CLI usage telemetry is separate from the application traces described in the Agent Tracing SDK guide. `telemetry inspect` previews the redacted command event without sending it. Run a command with `--help` before scripting a subcommand whose exact flags matter. ## Automation Global automation flags: | Flag | Behavior | | ---------------- | ------------------------------------------------ | | `--format table` | Human-readable default | | `--format json` | Structured output on stdout | | `--format csv` | CSV for commands that return rows | | `--timeout 10s` | Stop after a deadline; accepts `ms`, `s`, or `m` | | `--yes`, `-y` | Skip a supported confirmation prompt | Stable process exit classes are `0` success, `1` unknown, `2` validation, `3` authentication, `4` timeout, `5` network, `6` server error, `7` rate limited, and `8` other client error. Keep login tokens and Agent Wallet Keys out of shell history, CI logs, telemetry, screenshots, and model prompts. Prefer secret injection and delete temporary key files after import. # Agent Tracing SDKs Source: https://docs.anyway.sh/sdk/quickstart Install, configure, and structure JavaScript or Python traces for Dashboard and Agent Traces. Create an **Agent Traces API key** under **Business profile → Developers**, then select **Connect SDK** in the app. Agent-tracing keys are distinct from Merchant API and Agent Wallet keys. ## Install and initialize ```bash theme={null} npm install @anyway-sh/node-server-sdk export ANYWAY_API_KEY="" ``` ```typescript theme={null} import { initialize } from "@anyway-sh/node-server-sdk"; initialize({ appName: "support-app", apiKey: process.env.ANYWAY_API_KEY, baseUrl: "https://collector.anyway.sh", }); ``` ```bash theme={null} pip install anyway-sdk export ANYWAY_API_KEY="" ``` ```python theme={null} import os from anyway.sdk import Traceloop Traceloop.init( app_name="support-app", api_key=os.environ["ANYWAY_API_KEY"], api_endpoint="https://collector.anyway.sh", ) ``` The HTTPS collector uses OTLP/HTTP. A custom endpoint without `http://` or `https://` is treated as gRPC by the Python SDK. ## Environment configuration | Variable | Meaning | | ------------------------- | ------------------------------------------------------------- | | `ANYWAY_API_KEY` | Agent Traces API key | | `ANYWAY_BASE_URL` | Collector endpoint; defaults to `https://collector.anyway.sh` | | `ANYWAY_HEADERS` | Optional exporter headers when using custom authentication | | `ANYWAY_TRACE_CONTENT` | Control JavaScript prompt and completion capture | | `TRACELOOP_TRACE_CONTENT` | Control Python prompt and completion capture | Prefer `apiKey` / `api_key` over constructing an `Authorization` header yourself. When custom headers are required, send the collector key as `Authorization: Bearer `. ## JavaScript tracing Use function wrappers for explicit trace hierarchy: ```typescript theme={null} import { withWorkflow, withAgent, withTask, withTool, } from "@anyway-sh/node-server-sdk"; await withWorkflow( { name: "support-reply", associationProperties: { userId: "usr_opaque", sessionId: "session_opaque", }, }, async () => withAgent({ name: "support-agent" }, async () => withTask({ name: "draft" }, async () => withTool({ name: "knowledge-search" }, async () => { // Call the tool here. }), ), ), ); ``` TypeScript class decorators are also supported: ```typescript theme={null} import { workflow, task } from "@anyway-sh/node-server-sdk"; class SupportFlow { @workflow({ name: "reply" }) async reply() { return this.draft(); } @task({ name: "draft" }) async draft() { return "response"; } } ``` ### ESM and Next.js Require-based automatic instrumentation cannot see normal ESM imports. Pass imported provider modules explicitly: ```typescript theme={null} import { initialize } from "@anyway-sh/node-server-sdk"; import OpenAI from "openai"; initialize({ appName: "next-app", apiKey: process.env.ANYWAY_API_KEY, instrumentModules: { openAI: OpenAI }, }); ``` `instrumentModules` supports the providers exposed by the installed SDK, including OpenAI, Anthropic, Cohere, Bedrock, Google Vertex AI, Pinecone, Together, LangChain, LlamaIndex, ChromaDB, Qdrant, and MCP. ## Python tracing Decorators support synchronous and asynchronous functions: ```python theme={null} from anyway.sdk.decorators import workflow, task @workflow(name="support_reply") async def reply(): return await draft() @task(name="draft") async def draft(): # Call the model or tool here. return "response" ``` Keep decorators on the application boundary that has a useful business name. Provider instrumentation records nested model calls, token use, and supported tool or streaming behavior. ## Configuration reference | Capability | JavaScript | Python | | --------------------- | ----------------------- | ------------------------------- | | Application name | `appName` | `app_name` | | API key | `apiKey` | `api_key` | | Collector | `baseUrl` | `api_endpoint` | | Disable batching | `disableBatch` | `disable_batch` | | Custom exporter | `exporter` | `exporter` | | Custom span processor | `processor` | `processor` | | Content tracing | `traceContent` | environment/instrument controls | | Custom pricing | `pricingJsonPath` | `pricing_json_path` | | Disable pricing | `pricingEnabled: false` | `pricing_enabled=False` | Both SDKs can export through custom OpenTelemetry exporters and processors. JavaScript additionally exposes conversation tracking, association properties, explicit provider modules, batching controls, and custom model pricing. Python additionally accepts samplers, resource attributes, instrument allow/block sets, and span post-processing. ## Custom exporter If your organization already operates an OpenTelemetry pipeline, pass its exporter instead of the Anyway collector exporter. Authentication and delivery then follow that exporter and collector configuration; Dashboard only receives spans that ultimately reach Anyway's collector. ## Data safety * Keep the Agent Traces API key in environment or secret storage. * Decide whether prompt and completion content may be captured before production. * Never record payment credentials, Agent Wallet Keys, identity documents, or payout details. * Use stable pseudonymous IDs in association properties instead of customer email or legal identity. * Apply redaction before values enter SDK attributes or model/tool spans. Disabling prompt capture in your own spans does not automatically redact arguments recorded by third-party provider instrumentation. Test the emitted trace payload with non-sensitive data before enabling production export.