Developer guide

AI Platform

13 min read

The AI Platform is the conversational side of the product: the assistant that reads a message from a Partner's user, works out what they are asking for, collects what is missing, gets an explicit confirmation and only then moves money.

Available today An assistant runs against the B2B API now, with an operational console for reading its conversations. Both were adapted from the ones the consumer product already ran, so a Partner starts from a channel that works. Roadmap The runtime underneath is being rebuilt; that part is described further down.

What a Partner gets today

The assistant is its own service, and it reaches the platform the way any integrator does — over the public API, with a catalogue of functions that turns a sentence into a call. A transfer asked for in a conversation is created under the same idempotency key, the same tenant limits and the same reconciliation as one asked for by a backend. The channel never signs and never writes to the ledger.

Message
→ Assistant
→ B2B API
→ Operation
→ Signer, adapter, ledger
→ Signed webhook, and the reply in the same thread

What belongs to a Partner lives in that Partner's own database: the function catalogue, cut to what the B2B API offers; the modes; the prompts; the message templates. Adapting the assistant to a Partner is a database, and the code is the same one. That is what lets a second Partner be a configuration rather than a fork.

Beside it, an operational console reads that same database — the conversations, and the modes, functions and templates behind them. It reads them today; what is still open is its access model for a Partner: the roles, and the deployment that separates one Partner from another.

The channel a conversation arrives on is separate from what the assistant does with it. A console client stands in for WhatsApp while a deployment has no number, and the portal talks to the same assistant over a web channel of its own. See Webhooks and channels for how a channel carries authorization, and how results are delivered.

MCP server

A person can operate a ChatterPay account by talking to an AI client. The ChatterPay MCP server publishes the account's operations as tools of the Model Context Protocol (MCP), the open protocol AI clients use to call external tools. Once a client is connected to it, the client reads balances, deposit addresses and history, prices a transfer or a swap, shows that quote to the person, and executes it when the person approves it.

Available today In the sandbox: the sandbox MCP server operates one demonstration account on Arbitrum Sepolia and Base Sepolia, which are test networks, and anyone can connect to it to try the flow end to end. Roadmap Connecting each Partner's users to their own account comes next, and is described at the end of this section.

What the server does

The server offers ten tools. The AI client picks the tool that answers what the person asked; the person writes in their own words and never has to name a tool.

Tool	What it does
`get_supported_assets`	Lists every asset and network pair the account can use, with each asset's decimals
`get_balance`	The available, pending and reserved balance, for every asset or for one asset and network; available is the current balance, what the account can send now
`get_deposit_address`	The account's address on a network, and the assets that address receives there
`get_deposit_addresses`	The account's address on every network, or on the networks that receive one asset
`quote_transfer`	Prices sending an amount to an address or to a phone number with its country code: fee and its breakdown, what the recipient receives, total debited and the instant the quote expires
`create_transfer`	Executes a transfer quote the person approved
`quote_swap`	Prices converting one asset into another on the same network: amount received, rate, fee, total debited and expiry
`create_swap`	Executes a swap quote the person approved
`get_transactions`	The account's latest transfers, swaps and deposits, newest first, optionally of one kind
`get_transaction`	One transaction: its status, amounts, fee, total debited, network cost, transaction hash and explorer link

A transaction's status is processing, completed or failed. It reads completed once the platform reports the operation completed on chain, and the explorer link opens the transaction on the network's public explorer.

The sandbox account

The sandbox MCP server serves one demonstration account, and every person who connects shares it: the same balances, the same deposit addresses and the same history.

Networks: Arbitrum Sepolia, Base Sepolia, Cardano Preprod and Bitcoin Testnet4.
Assets: USDC, USDT, WETH and WBTC on Arbitrum Sepolia and Base Sepolia, ADA on Cardano Preprod, and BTC on Bitcoin Testnet4.
Transfers go to an address on the network named in the request (0x followed by 40 hexadecimal characters on Arbitrum Sepolia and Base Sepolia, an addr_test1… address on Cardano Preprod, a tb1… address on Bitcoin Testnet4) or to a phone number with its country code, such as +5491123456789; a number written without + needs at least 11 digits. Each transfer settles within that one network.
Phone numbers: a transfer to a number credits that number's account on the network, which the platform creates when the number has none yet, so every valid number receives the same answer. The quote shows the number in full; the shared history shows it masked, as in +54911 •••• 6789, because everyone connected reads the same history. The account sends to at most 10 new phone numbers per hour. A transfer to a number has the same limits, budget and quote, approval and execution as a transfer to an address.
On Cardano Preprod the account pays each transfer's network fee in ADA, and the quote says so. The chain sets a minimum amount per transfer, close to 1 ADA, and a quote below it states the amount to send instead.
On Bitcoin Testnet4 the account pays each transfer's network fee in BTC, on top of the quote's total, and the quote says so; the fee charged appears on the transaction once it settles. A transfer reads completed once its transaction is broadcast, and the transaction is in a block about 10 minutes later on average, sometimes much later, as its explorer link shows. Until then the BTC the account keeps is unconfirmed change, so the available balance reads lower, often 0, and the account's next Bitcoin transfer waits for that confirmation. Each transfer sends at least 0.00001 BTC.
Swaps convert one asset into another on the same network, on Arbitrum Sepolia and Base Sepolia. They settle on chain through the platform's pool at a fixed rate, and the quote states the rate and its kind.
Limits: each transfer has a maximum per asset, and the account has a budget per hour, both for the number of transfers and swaps and for the amount transfers send out per asset. A request beyond a limit is refused with a message that states the limit.

Because the account is shared, anything sent from it leaves for everyone, and what one person reads in the history includes what other people did.

Add the server in Claude.ai

The server's URL is:

https://mcp.partners.chatterpay.net/mcp

Claude.ai adds an MCP server as a custom connector.

In Claude.ai, open Customize → Connectors.
Select + Add, then Add custom connector.
Give it a name, for example ChatterPay B2B (Sandbox), and paste the URL above.
Choose No sign in as the authentication.
Start a new chat, open + → Connectors and enable the connector. A chat that was already open keeps the tools it loaded when it started.

A connector added this way is available in Claude.ai, in Claude Desktop and in the Claude mobile apps. The Free plan allows one custom connector. On a Team or Enterprise plan, an owner adds it for the organization under Organization settings → Connectors, and members then enable it in their chats.

Other MCP clients

Any MCP client that speaks the Streamable HTTP transport connects to the same URL, with no authentication. The server describes its tools, their inputs and the rule for moving funds to the client when it connects, so the client learns how to use it from the server itself.

Moving funds: quote, approval, execution

Every movement of funds takes two steps with the person's approval between them.

The client calls quote_transfer or quote_swap, and shows the person the quote: the amounts, the fee, the total debited and the expiry.
The person approves that quote explicitly.
The client calls create_transfer or create_swap with the same quoteId.

What executes is exactly what the quote froze: asset, network, amount, destination and fee. A quote expires, and an expired quote asks for a new quote and a new approval. A transfer or a swap is irreversible once executed, and the tools that execute them are marked as destructive, so a client that asks for confirmation before destructive actions asks before each one.

Try it

Once the connector is enabled, ask in plain language:

"How much USDC do I have on Base Sepolia?"
"Swap 100 USDC for WETH."
"Send 10 USDC to 0x…"
"Send 1 USDT on Base Sepolia to +5491123456789."
"What are my latest transactions?"

For a transfer or a swap, the client answers with the quote first and waits for your approval before it executes anything.

Refusals

A refusal reaches the client as a tool error with a stable code and a message that says what to do instead. The ones a person meets most often:

Code	Meaning
`TRANSFER_LIMIT_EXCEEDED`	The amount is above the per-transfer limit for that asset; the message states the limit
`BUDGET_EXHAUSTED`	The account reached its budget for the current hour, or its hourly maximum of new phone numbers; the message states the bound and, for the budget, what already left
`INSUFFICIENT_BALANCE`	The account holds less than the total the quote debits on that network
`NETWORK_CANNOT_COVER`	The named network cannot send the whole amount on its own; `get_balance` shows where the funds are
`INVALID_RECIPIENT`	The recipient must be an address on the network or a phone number with its country code
`RECIPIENT_UNAVAILABLE`	That recipient is blocked from receiving transfers
`QUOTE_EXPIRED`	The quote is past its expiry; the client checks the history, then asks for a new quote and a new approval
`OUTCOME_UNKNOWN`	The answer to an execution was lost; the client checks the history first, and requests nothing new until it shows whether the operation ran

Partner accounts

Roadmap The next phase connects each Partner's users to their own account. The person signs in from the AI client with OAuth and consents to what the client may do; the server then serves that person's account alone, under the Partner's limits and policies. Reading and moving funds are separate permissions, every execution keeps the quote and the explicit approval described above, and each one is recorded in the audit trail.

What the rebuild is for

The runtime in use was written around a single model, with most of the work happening synchronously. That is enough to prove a flow and not enough to run a Partner's support and payments on. Four properties are what the rebuild is for.

A model is a dependency, not a foundation. Which model answers becomes configuration per task, with a spending ceiling of its own, so a provider that fails, changes its terms or prices itself out is replaced without touching the assistant.

A conversation is durable. A message being processed when the service dies is picked up again; one already answered is not answered twice; turns of the same conversation are handled in the order they arrived. What could not be delivered after every retry is set aside for review rather than disappearing.

What the assistant may do is declared. Capabilities become a list with arguments, permissions and limits, checked before the call runs. A model cannot reach an operation it was not granted, and every invocation is recorded with what it asked for and what came back.

A person can step in. An operator takes a live conversation over, answers as themselves and hands it back. Whatever was pending resumes exactly once.

On top of those come the parts a real support conversation needs: the whole WhatsApp channel — media, voice transcribed to text, interactive forms, the service window and approved templates — answers drawn from the Partner's own knowledge base, and campaigns bounded by a budget, a stop and an opt-out that outlives the campaign that prompted it.

Capabilities in this area

This area covers the capabilities below. The Roadmap states the current availability of each one.

A bot instance running against the B2B API — The assistant runs as its own service against the public API, with a catalogue of functions that turns a message into a call. It was adapted from the assistant the consumer product already ran, so what a Partner gets on day one is a channel that works rather than one being written.
A transfer asked for in the conversation — The assistant creates the operation through the same public API any other caller uses, under the same idempotency key, the same tenant limits and the same reconciliation. Asking twice moves the money once, and what happened is visible in the ledger and in the webhooks rather than only in the chat.
A chat widget in the portal on the same bot — The portal talks to the same bot through a web channel of its own, so a visitor can try the conversational flow without a phone number. It runs under the same limits and the same environment budget as the rest of the Sandbox.
A console for reading the conversations — An operational surface over the assistant's own database, where the Partner reads what was said, and the modes, functions and templates behind it. It reads the conversations today; what is open is its access model for a Partner — the roles, and the deployment that separates one Partner from another.
MCP server for AI clients, in the sandbox — A public Model Context Protocol server lets Claude.ai, Claude Desktop and any other MCP client read balances, deposit addresses and history, and price and execute transfers and same-network swaps. It operates one demonstration account shared by everyone who connects, on Arbitrum Sepolia and Base Sepolia, and every movement of funds executes the quote the person approved, within per-transfer and per-hour limits.
Each Partner's users connect their own account to the MCP server (OAuth sign-in) — A Partner's user signs in from the AI client with OAuth and consents to what the client may do, and the server then serves that user's account alone. Reading and moving funds are separate permissions, every execution follows the Partner's limits and policies and the person's approval of the quote, and each one is recorded in the audit trail.
Governed capabilities instead of an open catalogue — What the assistant may do is a declared list with its arguments, its permissions and its limits, checked before the call runs. A model cannot reach an operation that was not granted to it, and every invocation is recorded with what it asked for and what it got back.
A human operator can take the conversation over — Someone from the Partner steps into a live conversation, answers as themselves and hands it back, with the assistant held while they hold it. What was pending when they took over resumes exactly once when they release it, rather than being dropped or run twice.
The whole WhatsApp channel — Images, documents and voice notes transcribed to text, the interactive forms the provider offers, the service window that governs when a conversation may be started, and the approved templates for starting one outside it. The parts of the channel a real support conversation runs on.
Campaigns with a budget, a stop and an opt-out — Reaching many people at once, bounded by a declared budget and by the provider's own limits, with a switch that stops a running campaign at once. Whoever asks to stop receiving them stops receiving them, and that decision outlives the campaign that prompted it.
Answers drawn from the Partner's own knowledge — The Partner loads its own articles and the assistant answers from them, citing which one it used. A fixed set of questions with their expected answers is run against every change, so a new model or a new prompt cannot quietly make the answers worse.