What is ChatterPay
ChatterPay brings blockchain operations to a conversation, built around one idea: a person should be able to send and receive money on a blockchain without having to learn what a blockchain is.
There are two products under that name. ChatterPay is the consumer experience, where a person operates a wallet from a conversation. ChatterPay B2B is the infrastructure behind it, offered to companies that want to put the same capability inside their own product. This portal documents ChatterPay B2B.
ChatterPay, the consumer product
In the consumer product, the wallet lives in a chat. A person writes what they want to do in their own words — check a balance, send an amount to a contact — and the assistant collects the intent, presents a quote and asks for an explicit confirmation before anything is executed.
What the person never has to do is the part that usually stops them: there is no app to install, no seed phrase to write down and no native token to buy before a transfer can be paid for. The wallet is created for them, and the mechanics of gas, networks and contract addresses stay out of the conversation.
ChatterPay B2B: WhatsApp infrastructure for blockchain operations
Bring blockchain operations to WhatsApp.
What a deployment covers
A white-label API and SDK over the networks a deployment enables — today EVM (Arbitrum and Base), Bitcoin and Cardano — with partner-controlled KYC.
- Blockchain operations — transfers, swaps, staking and other supported operations across multiple blockchain networks. Same-chain swaps execute today; Roadmap staking on Cardano.
- API & SDK — one integration model for accounts, operations, networks, assets and the full transaction lifecycle, with statuses, webhooks and reconciliation. The integration resource is the official backend SDK,
@chatterpay/sdk. - Multi-network infrastructure — work across supported EVM and non-EVM networks, including swaps and cross-chain routes, through a consistent integration layer. Cross-chain routing reads quotes and status live from LI.FI, whose own route coverage spans 60+ chains — a wider set than the networks this platform integrates directly; Roadmap route execution.
- Security & signing — partner-managed signing: keys stay in your environment, and Roadmap ChatterPay verifies every signature before broadcasting. Roadmap Per-transaction limits and policies. KYC stays under partner control.
- Customer engagement — complementary CRM, campaign and referral tools that run in the same conversations as your operations. Conversational agents speak in the Partner's brand voice today; Roadmap the customer console, campaigns and referrals.
ChatterPay B2B takes that engine and offers it to Partners. A Partner embeds wallets and blockchain operations in its own product without rebuilding account provisioning, signing, execution, on-chain observation, ledger, reconciliation and events.
Two things follow from that shape. The Partner keeps the relationship with the end user, the KYC and AML source of truth, and control of the production keys, so custody of those keys stays on the Partner's side. And the platform runs independently from the consumer product: separate data, contracts, credentials and deployments, so neither one can break the other.
What a Partner gets
- versioned B2B API and the official backend SDK,
@chatterpay/sdk; - one logical wallet per user with native accounts per blockchain family;
- direct transfers and composite operations;
- EVM Account Abstraction with EIP-7702 and optional ERC-4337 execution;
- Partner-controlled signing through a dedicated boundary;
- fees, operational ledger, reconciliation and on-chain evidence;
- events and webhooks for the Partner application;
- WhatsApp and future channels without duplicating financial logic;
- a self-hosted model where productive infrastructure and keys stay under Partner control.
Conceptual flow
flowchart LR
U[User] -->|1| C[Partner channel]
C -->|2| I[Partner integration]
I -->|3| API[B2B API]
API -->|4| OP[Operation]
OP -->|5| SG[Partner signer]
OP -->|6| EX[Execution router]
EX -->|7| EVM[EVM]
EX -->|7| BTC[Bitcoin]
EX -->|7| ADA[Cardano]
EX -->|7| SOL[Solana]
EX -->|7| TRX[Tron]
EX -->|7| XLM[Stellar]
EX -->|8| LF([LI.FI route provider])
OP -->|9| L[Ledger]
OP -->|10| R[Reconciliation]
R -->|11| WH[Webhook / state]
WH -->|12| IWhat each step does
- User → Partner channel. A person states what they want to do, wherever the Partner put the product: its own application, WhatsApp, or another enabled channel.
- Channel → Partner integration. The channel hands that intent to the Partner's backend, which holds the user's session and its own risk rules.
- Partner integration → B2B API. The backend calls the public contract with its own credentials, and the tenant is derived from the credential itself.
- B2B API → Operation. The request is priced, checked against the tenant's limits and persisted as an
Operation. From here the flow survives a restart. - Operation → Partner signer. A
keyReferenceand a digest go to the Partner Signer Gateway, and a signature with an audit reference come back. - Operation → Execution router. The router chooses the adapter of the network the operation settles on.
- Execution router → EVM, Bitcoin, Cardano, Solana, Tron, Stellar. Each family keeps its own addresses, transaction model, fees and finality rules behind that boundary.
- Execution router → LI.FI. A swap or a cross-chain transfer goes through the route provider, and every step of the route is validated against the accepted intent before anything is signed.
- Operation → Ledger. The financial impact is written as append-only entries.
- Operation → Reconciliation. Observers watch the chain and the reconciler contrasts what settled against what was recorded.
- Reconciliation → Webhook / state. The confirmed result becomes a durable event.
- Webhook / state → Partner integration. The signed webhook reaches the Partner's backend, which updates its own projection of the operation.
Main channels
Partner-app-first. The Partner authenticates the user, presents the quote and collects confirmation in its own app; its backend then uses the SDK/API.
WhatsApp-first. The user starts from the Partner WABA/number. The conversational channel gathers the intent, resolves the recipient, presents the quote and records confirmation. The same B2B core still enforces limits, signing policy, execution and reconciliation.
Blockchain families
Each family keeps its own native transaction model behind a common Operation, so a Partner integrates once. See the Roadmap for the current availability of each one.
| Family | Native model | ChatterPay B2B use |
|---|---|---|
| EVM | Account model + EIP-7702 | Base, Arbitrum and other enabled EVM networks |
| Bitcoin | UTXO | Native BTC transfer and input/output reconciliation |
| Cardano | EUTXO | ADA through a Cardano adapter; native assets are on the roadmap |
| Solana | Accounts owned by programs | Roadmap SOL and SPL tokens through a Solana adapter |
| Tron | Accounts with bandwidth and energy | Roadmap TRX and TRC-20 through a Tron adapter |
| Stellar | Accounts with trustlines and sponsorship | Roadmap XLM and USDC through a Stellar adapter, and escrow on Soroban |
LI.FI is a route provider the platform uses to move value between these families.
Solana · Tron · Stellar · Roadmap These three families are explicitly part of the public expansion roadmap. For every family, actual availability remains environment- and capability-gated.
Where the same token exists on more than one of these networks, chain abstraction is the direction that presents it as a single balance instead of one per network.
Let's plan your integration
Tell us about your product and your volumes, and we'll come back with an integration plan.