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.
How it works in one picture
- Pair. Your agent opens a pairing session and shows a short code or QR. The user scans it inside the VelarumPay wallet.
- 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. - Request. Your agent uses the token to create payment requests. Each one is delivered to the wallet over WebSocket.
- 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.
MCP server
Plug VelarumPay into any MCP-capable AI agent (Claude and others) as a set of tools.
REST API
Call the endpoints directly from any language. Pairing, connections, payment requests, status.
Protocol
The open velarum.payment_request.v1 and velarum.transaction_context.v1 formats.
Core principles
| Principle | What it means for you |
|---|---|
| Non-custodial | Keys live in the user's wallet. The server and your agent never see them. |
| User approval by default | Real payments require the user to sign. Your agent proposes; it cannot self-approve. |
| Scoped & revocable | Connection tokens carry only the scopes the user approved, and can be revoked anytime. |
| Open protocol | Payment 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.