Choose an integration

Make three choices: how your agent calls Conto, who signs the transfer, and which payment method the recipient accepts. The choices are independent. For example, an SDK integration can use an external wallet to pay an x402 API.

1. Connect your runtime

Your task	Recommended starting point
Build a backend or custom agent in TypeScript	TypeScript SDK
Build in another language or need raw HTTP	REST API
Give an MCP-compatible assistant payment and read tools	Install MCP
Connect OpenClaw or Hermes with an existing wallet	Agent skills
Provision or inspect resources from a terminal or CI	CLI
Review activity and manage controls as a human	Dashboard assistant

For your first integration, use the Tempo Testnet quickstart. An autonomous agent can start with the simulated sandbox, which needs no signer or funded wallet.

2. Choose who signs

Managed wallets use request, then execute. External wallets use approve, your own transfer, then confirm. Conto cannot block a transfer your signer sends outside that flow. Use a managed wallet if you want Conto to sign. Use an external wallet if you already run a signer. See wallet ownership and custody. A contract-enforced wallet needs a deployed contract and an independently configured authorization and signing path. Conto provides policy evaluation only. Managed execute cannot pay from a smart-contract wallet.

Hybrid integrations

In a hybrid integration, your app owns the wallet, protocol client, or settlement path, and Conto decides before your app pays. Choose hybrid when you already run a wallet or treasury layer, handle x402 or MPP in your own runtime, or embed paid actions inside a larger workflow. Call Conto before your app pays. If your app pays first and reports later, Conto only records the spend and cannot stop it.

Example: your own wallet

import { Conto } from '@conto_finance/sdk';

const conto = new Conto({ apiKey: process.env.CONTO_API_KEY! });

export async function payProvider(
  amount: number,
  recipientAddress: string,
  // Your wallet or provider code. Returns the transaction hash.
  send: (to: string, amount: number) => Promise<string>
) {
  // 1. Ask Conto before paying.
  const approval = await conto.payments.approve({
    amount,
    recipientAddress,
    senderAddress: process.env.APP_WALLET_ADDRESS!,
    chainId: 42431,
    purpose: 'Provider settlement',
  });

  if (approval.status !== 'ready_to_send' || !approval.approvalId || !approval.approvalToken) {
    // declined: do not pay. review_required: pay only after a reviewer approves.
    return { paid: false, status: approval.status, reasons: approval.reasons };
  }

  // 2. Pay through your own path.
  const txHash = await send(recipientAddress, amount);

  // 3. Record the settled spend.
  const receipt = await conto.payments.confirm(approval.approvalId, {
    txHash,
    approvalToken: approval.approvalToken,
  });
  return { paid: true, transactionId: receipt.transactionId };
}

The approval token expires after 10 minutes. For x402 and MPP, the same shape uses x402.preAuthorize() or mpp.preAuthorize(), then x402.record() or mpp.record() with the returned grant. For a card, use cards.approve(), then cards.confirm().

Hybrid checklist

Each actor in your app maps to one Conto agent with its own SDK key, kept server-side and encrypted at rest.
Spending settings live in Conto policies, or sync into them. Only the owner or authorized budget managers edit them.
Your executor requires a Conto approval before it signs or uses credentials. A model instruction alone does not enforce this boundary.
Denied payments never reach the execution layer.
Every settled payment is recorded back to Conto: payments.confirm() with the transaction hash, x402.record() or mpp.record() with the grant, or cards.confirm().

Map product controls to policies

Product control	Conto primitive
Max spend per action	`SPEND_LIMIT`
Budget per period or project	`BUDGET_ALLOCATION` with a `BUDGET_CAP` rule
Budget per x402 or MPP session	`X402_SESSION_BUDGET` or `MPP_SESSION_BUDGET` rules
Allowed providers or vendors	`COUNTERPARTY` or `WHITELIST`
Human review threshold	`APPROVAL_THRESHOLD`
Time-based restrictions	`TIME_WINDOW` or `BLACKOUT_PERIOD`

3. Match the recipient’s payment protocol

Recipient accepts	Flow	Guide
A stablecoin transfer to a wallet address	Request and execute, or approve and externally send	Payments
An HTTP 402 challenge for a paid API	Pre-authorize, pay and retry through your x402 integration, then record settlement with the grant	x402 API payments
MPP charges or sessions	Pre-authorize, use your MPP integration, then record settlement with the grant	MPP payments
A card checkout	A connected card: Conto releases a single-use card credential after your controls pass (Builder and Enterprise)	Connected cards
A merchant checkout your agent completes	Check the rules before Link or another payment method opens, and again before the payment is submitted	Checkout checkpoints

Checkout checkpoints need no wallet or signer. For a Link checkout, see Conto with Stripe Link. Pre-authorization returns a grant that the record call consumes. Your x402 or MPP client still signs, so a payment without a grant is flagged and the owner alerted, but Conto cannot stop it. Check the supported networks before selecting one. If a Conto payment call returns 503 PAYMENTS_PAUSED, stop the flow before signing or submitting payment and ask the owner to check availability. See error handling.

Networks

Confirm the agent’s wallet and network with GET /api/sdk/setup.

Network	Chain ID	Primary stablecoin	Environment
Tempo Testnet	`42431`	`pathUSD`	Onchain testnet, quickstart default
Tempo	`4217`	`USDC.e`	Mainnet
Base	`8453`	`USDC`	Mainnet
Base Sepolia	`84532`	`USDC`	Testnet
Ethereum	`1`	`USDC`	Mainnet
Arbitrum One	`42161`	`USDC`	Mainnet
Polygon	`137`	`USDC`	Mainnet
Solana	`solana-mainnet`	`USDC`	Mainnet
Solana Devnet	`solana-devnet`	`USDC`	Testnet

Check GET /api/chains for the live list.

Managed payment requests select the wallet with walletId and pay on that wallet’s configured chain. The wallet must be linked and funded.
External approval uses chainId. Your signer and sender wallet must be on that chain.
x402 settles in USDC only: use Base, Ethereum, Arbitrum, Polygon, or Solana (Base Sepolia or Solana Devnet for testing). Your x402 signer or client must support the service’s challenge and settlement network. Conto does not make the paid HTTP request.
MPP uses Tempo. Your MPP client and the service must agree on method, network, and session terms.

Before enabling real funds

Confirm the intended custody model is available, the wallet is provisioned and funded, and your signer can pay the network’s fees. Organization-controlled managed wallets need owner setup first. Until then, requests for that wallet type fail. See wallet custody. Run a small payment on the intended path and verify the final transaction, not only the authorization. Use separate production credentials and controls, then complete production readiness. If the selected path is unavailable, contact support before funding it.

Continue with the same payment ID

Preserve returned IDs in every integration. Human review and HTTP 402 require a next action. A submission timeout requires reconciliation. Follow track and recover a payment before treating a request as settled or creating another payment intent.

Get started

Integrate

Payments

Conto Commerce

Spending controls

Operate

Conto Pay

Choose an integration

1. Connect your runtime

2. Choose who signs

Hybrid integrations

Example: your own wallet

Hybrid checklist

Map product controls to policies

3. Match the recipient’s payment protocol

Networks

Before enabling real funds

Continue with the same payment ID

​1. Connect your runtime

​2. Choose who signs

​Hybrid integrations

​Example: your own wallet

​Hybrid checklist

​Map product controls to policies

​3. Match the recipient’s payment protocol

​Networks

​Before enabling real funds

​Continue with the same payment ID

1. Connect your runtime

2. Choose who signs

Hybrid integrations

Example: your own wallet

Hybrid checklist

Map product controls to policies

3. Match the recipient’s payment protocol

Networks

Before enabling real funds

Continue with the same payment ID