BePay AI — Agent Documentation

Everything an autonomous agent needs to connect to, understand and operate this governed payment-operations layer over the Model Context Protocol. This is not a mock: every tool below wraps a live function on this server.

Connection

MCP endpointhttps://sidai.live/bepay/mcp

MCP directhttps://mcp.sidai.live/mcp

TransportStreamable HTTP · JSON-RPC 2.0 · session id issued on initialize

Agent cardhttps://sidai.live/bepay/.well-known/agent-card.json

Authnone (demo surface; reasoning managed server-side)

POST JSON-RPC requests to the endpoint. Single requests and batch arrays are both accepted; responses are plain application/json.
GET opens a server-sent-events stream carrying periodic pings (for clients that expect the streamable-HTTP GET channel).
Methods: initialize, notifications/initialized, ping, tools/list, tools/call. Resources and prompts are empty capabilities.
Sessions: the server issues an Mcp-Session-Id on initialize (also CORS-exposed). Send it back on later calls; strict clients need it, lenient ones work without.

What this system is

BePay AI is a governance operating layer for payment agents, built on BePay Money rails. The principle: AI proposes. Policy governs. Humans approve. Every task runs a seven-stage governed loop:

Understand→ Plan→ Govern→ Act→ Approve→ Execute→ Prove

Reasoning — the analysis, planning and reporting inside a run are produced by a live, gateway-managed inference chain. No client keys needed.
Policy — six deterministic rules (threshold, KYB validity, FX drift, aging, velocity, currency) resolve to BLOCK > HOLD > FLAG > PASS. Worst verdict wins. Policy is code, not model opinion.
Control plane — each run is admitted as a mission on a real mission-operating platform (create_requirement → approve_mission → store_evidence).
Approval — payments above 10,000 USD (or under any hold rule) pause the loop for a human decision, recorded on two layers: the payment rail and the mission.
Proof — every event lands in a SHA-256 hash chain. bepay.get_audit_proof verifies it end-to-end.
Rails — money movement is a clearly-labeled reference sandbox (deterministic golden dataset). No real funds move. Everything else is live.

Recommended agent loop

1. initialize                       → orient (returns instructions)
2. bepay.overview                   → current system state, health, chain head
3. bepay.list_scenarios             → pick a scenario
4. bepay.start_run {scenario}       → returns run_id (async execution)
5. poll bepay.get_run {run_id}      → watch stages progress
   - state=awaiting_approval        → the human gate is armed:
       bepay.approve_run / bepay.reject_run {run_id, approver}
6. terminal states: completed | blocked | rejected | failed
7. bepay.get_audit_proof            → verify the whole run cryptographically

Real BePay Money integration bepay_money.*

Beyond the reference sandbox, six tools talk to the live BePay Money dev API under our own test merchant. This is how an agent mints real wallets and raises real payment intents — the demo turning into the real thing.

What BePay Money is — a multi-chain crypto payment gateway (EVM, Bitcoin, Solana, Tron). Merchants hold an API key, authenticate with a 6-digit PIN for a JWT, mint one wallet per chain, and raise payment intents (amount + currency + QR code + hosted pay link) that customers pay.
Who you are here — our test merchant. Start with bepay_money.status: it confirms the API, names the merchant, and counts tracked wallets. Keys, PINs and JWTs live server-side only and never appear in any response.
Wallet lifecycle — bepay_money.create_wallet {walletType} mints a real on-chain address (plus derivation path and supported chains). bepay_money.list_wallets shows everything minted through this integration. Nothing is funded and no funds move — minting only creates addresses.
Managing money in — bepay_money.create_intent {amount, currency, walletType?, network?, description?} raises a real intent and returns its QR payload and hosted pay link in the same response (auto-enriched, no second call). network selects the EVM settlement chain; specific wallet-address targeting is unsupported upstream (intents route to the merchant default address). bepay_money.get_intent {intentId} reads live status (created → paid → expired); bepay_money.list_intents lists them all.
Staying in sync with governance — every mint and raise is appended to the same SHA-256 audit chain as governed runs. Pass run_id to act under a live run (terminal runs refused), or reference_run_id to cite a finished run — e.g. raising the real intent after an approval gate closes — as provenance, never authority.

Safety boundaries (enforced in code, not just documented). Dev test rails only — production is unreachable by construction. One fixed test merchant, no switching. Amounts must be positive numbers inside the per-intent cap (negatives, zero and non-numbers are rejected before any API call). No merchant onboarding, no PIN changes, no fund movement — and wallet-creation responses are scrubbed of mnemonics and private material server-side.

mint → manage → track:
  bepay_money.create_wallet {walletType:'evm'}
  bepay_money.create_intent {amount:25, currency:'USDC', description:'demo invoice #1'}
  bepay_money.get_intent    {intentId:'pi_...'}
linked to governance:
  bepay_money.create_intent {amount:25, currency:'USDC', run_id:'run_...'}

Troubleshooting a fresh connection

Session terminated / 32600 — re-run initialize and send back the Mcp-Session-Id from its response headers. Confirm the URL is https://sidai.live/bepay/mcp (single e) or https://mcp.sidai.live/mcp — the double-e path returns a 404 page, and some clients report that as an auth/startup failure.
401 or empty responses — this server needs no API keys. A 401 means the wrong host (api.sidislab.com is a separate OAuth-gated system) or a non-MCP path. POST JSON-RPC to /mcp only.
Rate limit (-32063) — back off; hourly budgets: start_run 20 · approve/reject 30 · ask_agent 6 · reset 6 · money writes 20.
Intent rejected — amounts must be positive numbers inside the cap; currencies are USDC, USDT, ETH, BTC.
Write refused for a run — terminal runs (completed/blocked/rejected/failed) never accept new writes; start a new run or omit run_id.
Where am I? — call bepay_operator_guide first: its navigation section maps every task to tools, and real_money_guide explains wallet operations end to end.

Tools

Minimal client example

const rpc = async (body) => {
  const r = await fetch('https://sidai.live/bepay/mcp', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(body),
  });
  return r.json();
};

await rpc({ jsonrpc:'2.0', id:1, method:'initialize',
  params:{ protocolVersion:'2025-06-18', capabilities:{}, clientInfo:{name:'demo',version:'1'} }});
// the response headers carry Mcp-Session-Id - send it back on later calls

const tools = await rpc({ jsonrpc:'2.0', id:2, method:'tools/list' });

const started = await rpc({ jsonrpc:'2.0', id:3, method:'tools/call',
  params:{ name:'bepay.start_run', arguments:{ scenario:'hero' } }});
console.log(JSON.parse(started.result.content[0].text).run_id);

Notes & limits

Access notes. The public endpoint sits behind Cloudflare; normal browser-class HTTP clients pass automatically, but fully headless clients may be challenged by the zone's bot protection — if that happens, run from an environment that completes the browser check or ask the operator to allowlist the path. A direct origin endpoint (https://mcp.sidai.live/mcp, valid public TLS) bypasses Cloudflare entirely. Rate limits (per client, per hour): start_run 20 · approve/reject 30 · ask_agent 6 · reset_sandbox 6 · money writes 20. Exceeding them returns JSON-RPC error -32063. Tool outputs are plain JSON text inside the standard MCP content envelope.

This deployment is a live demonstration of governed agent operations for the BePay Money ecosystem. The governance stack — policy, mission admission, two-layer approval, hash-chained audit — is real and production-shaped; the money rails are a labeled reference sandbox so agents can explore safely.