Developer Preview · Test and pilot use only · View program boundaries
V VelarumPay Docs
Platform API v0.1

Let your AI agent request payments — the user always signs.

VelarumPay is a non-custodial wallet and payment-request platform. Your agent asks for a payment; the person reviews and signs it in their own wallet. The server never holds private keys.

New here? The fastest path is the Quickstart: pair once, then create payment requests with a connection token.
Machine-readable contracts: OpenAPI 3.1, Payment Request JSON Schema, and Transaction Context JSON Schema.

How it works in one picture

  1. Pair. Your agent opens a pairing session and shows a short code or QR. The user scans it inside the VelarumPay wallet.
  2. Approve. The user approves the requested scopes. The wallet hands back a connection token — that token is the authorization. There is no developer API key.
  3. Request. Your agent uses the token to create payment requests. Each one is delivered to the wallet over WebSocket.
  4. Sign. The user reviews the human-readable context and signs locally. Status flows back: pending → signed → broadcasted → confirmed.

Why there is no API key

Most payment APIs give developers a secret key that can move money. VelarumPay is different on purpose: authority comes from the user approving a pairing in their wallet, not from a key you hold. You get a scoped, revocable connection token instead. The user can pause or revoke it at any time.

Pick your integration

JavaScript SDK

Use @velarumpay/sdk-js for pairing, transaction contexts, payment requests, and event polling.

Go to Quickstart →

MCP server

Plug VelarumPay into any MCP-capable AI agent (Claude and others) as a set of tools.

Set up MCP →

REST API

Call the endpoints directly from any language. Pairing, connections, payment requests, status.

REST reference →

Protocol

The open velarum.payment_request.v1 and velarum.transaction_context.v1 formats.

Read the protocol →

Core principles

PrincipleWhat it means for you
Non-custodialKeys live in the user's wallet. The server and your agent never see them.
User approval by defaultReal payments require the user to sign. Your agent proposes; it cannot self-approve.
Scoped & revocableConnection tokens carry only the scopes the user approved, and can be revoked anytime.
Open protocolPayment facts are carried in a documented, validated format — no hidden fields.

Asset registration and schema validation do not prove wallet signing or broadcast support. Use only the network and asset paths explicitly listed as supported for your wallet build; the v0.1 quickstart uses labeled test data.