DEV Community: send21

We built a white-label P2P money app on send21: here's how to rebrand it with one file

send21 — Fri, 16 Oct 2026 09:31:54 +0000

Disclosure: this is written by the team behind send21, and dewby is built on send21.

dewby is a small P2P money app for paying friends back. It's a testnet demo: test money on test networks, nothing in it has value. It's a white-label version of our open-source example app, send21 pair: the same payments engine with its own name, logo, colors and UI. And the whole brand lives in one file.

What it does

Friends connect once by scanning a code. Then there are three things to do:

Pay back. Ask a friend for 120 in your own currency, or pay them. They get a request with the amount, a note and an Open wallet button.
Split. Pick two or more friends, enter the total, and everyone gets their share as a separate request.
QR anyone can pay. Show a QR for an amount. Whoever scans it pays from their own wallet, with no app and no account.

Each payment goes straight to the receiver's own wallet address. The payer signs in their own wallet. send21 never holds keys or funds, never signs and never broadcasts, and neither does dewby.

You can try it alone: tap Try it alone with a demo friend, send the prefilled request, tap Let Demo friend pay, and watch it go from waiting to paid. On desktop, the app sits in a phone frame next to a QR code you can scan to open it on your phone.

How it works

Every request is a send21 draft: payment instructions for one amount, asset and network, addressed to the receiver. Four details carry most of the safety:

The receiver address is fixed on the server. The client sends who to ask and how much. The server creates the draft with the receiver's saved address, and fails if the draft comes back with a different one. A tampered client can't change where the money goes.
V2 signed webhooks. send21 reports status (draft.seen, draft.confirmed, …) by webhook. dewby verifies the x-send21-signature-v2 header: an HMAC over the timestamp, the delivery id and the raw body. It turns off the legacy body-only signature and refuses deliveries more than five minutes old, so an old delivery can't be replayed.
Its own dedupe, on top of send21's. dewby stores each delivery id in the same transaction as the status change, so a repeated delivery is a no-op and can't confirm twice.
A check against the stored request. On draft.confirmed, dewby compares the asset, network and amount with what it stored when it created the request. If anything differs, the request goes to review instead of Paid.

The app is a vanilla PWA: no framework, no build step, a service worker and Web Push.

Three modes

mock: no key and no network. It runs on a local server, or fully in the browser like the GitHub Pages demo, where links and QR codes carry the data between phones.
demo: real testnet drafts from send21's public demo API, with status checked by polling.
api: your own scoped send21 key and webhooks. send21 accounts use live networks, so this mode refuses to start unless you set APP_ALLOW_LIVE=1.

Rebrand it with one file

Everything brand-specific is in web/brand.js:

window.BRAND = {
  name: "dewby",                 // UI name and wallet memo prefix
  tagline: "Pay friends back. Fresh.",
  storagePrefix: "dewby",        // keeps two apps on one origin apart
  siteUrl: "https://…/dewby/",   // share card URLs
  poweredBy: true,               // a small "powered by send21" line in Settings
  light: { bg, surface, ink, mint, lime, sea, pop, link, ok, warn, bad },
  dark: { … },
  forcedDark: { … },             // palette for browsers that force dark mode
};

theme.js turns the palette into CSS variables before first paint, so the stylesheet never hard-codes a brand color. The server reads the same file, so the memo in the payer's wallet shows your app's name. To rebrand:

Edit web/brand.js and swap web/icons/mark.svg.
Run npm run brand. It rewrites the manifest, title, theme color and share-card meta, and redraws the icons from your mark.
Run npm test. It checks every text color for WCAG AA contrast, that the manifest and HTML match the brand file, the share card size, and that no stray send21 branding is left in the UI.

The lesson: keep the brand as data, and let tests check what's easy to forget when you rebrand, like contrast, storage keys and leftover strings.

Honest limits

Testnet only. The demo uses Solana Devnet and Base Sepolia with test tokens. Nothing has value.
A prototype. It's an example to read and fork, not a product.
One extra tap on phones. A notification can open a web page but not a wallet, so the payer taps Open wallet to sign.

Try the demo friend, then open brand.js and change the colors. Questions or ideas: info@send21.io.

Let your agent get paid without holding keys

send21 — Thu, 15 Oct 2026 19:42:47 +0000

Sooner or later an agent you build has to deal with money. A booking agent hits a deposit. A freelancing assistant needs to send an invoice. A support bot has to collect a fee before it ships a replacement part.

The quick answer is to hand the agent a wallet. Fund it, put the private key in an environment variable, let the model call a send tool. That works in a demo. In production it means a single prompt injection, a confused tool call or a leaked log line can empty the wallet, and nothing in the stack can tell a legitimate payment from a manipulated one, because the agent is the one signing.

There is a simpler split that removes most of that risk: the agent prepares the payment, and a human signs it in their own wallet. This article shows how to do that with send21, a non-custodial service that prepares payment instructions, over its MCP server.

The split: preparing is not paying

A payment has two halves:

Preparing: who gets paid, how much, in which asset and network, with what reference, and at which exchange rate if the price is in euros or dollars.
Authorising: signing a transaction with a private key and broadcasting it.

Agents are good at the first half. It is structured data, it benefits from context, and mistakes are cheap if someone checks before signing. The second half is where the risk lives, and it is exactly the part an agent does not need.

send21 only does the first half. It never holds keys or funds, never signs and never broadcasts. Funds go straight from the payer's wallet to the receiver's wallet. Since there is no signing code on the server, an API key you give an agent cannot move money, however it is misused. The worst an abused key can do is create payment instructions that a human then has to approve in their own wallet.

What the agent can do

The send21 MCP server runs at https://send21.io/mcp over Streamable HTTP and is listed in the official MCP Registry as io.github.send21io/mcp. It exposes 11 tools, including:

create_payment_request: create a pay link where you are the receiver. Price it in a fiat currency, list the assets you accept with your own receiving addresses, and get back a link.
get_payment_request: read its status (Open, Completed, Cancelled, Expired).
create_draft and get_transaction_template: the other direction, where the owner pays someone. The template gives the wallet everything it needs to fund, review and sign.
get_rate and get_fee_schedule: rates with their source, and the public fee table.

Listing the tools and reading the fee schedule work without a key. Everything else needs a scoped API key that the account owner creates. For an agent that only issues pay links, drafts:write plus drafts:read is enough.

Supported today: BTC on-chain and over Lightning (paid to the receiver's own Lightning address), USDC on Solana, Ethereum, Base, Arbitrum and Polygon, USDT on Solana and Ethereum, EURC on Solana, Ethereum and Base, plus native SOL and ETH. Prices can be set in 161 fiat currencies.

Connect it in one block

In Cursor, .cursor/mcp.json from the send21-examples repo looks like this:

{
  "mcpServers": {
    "send21": {
      "url": "https://send21.io/mcp",
      "headers": {
        "Authorization": "Bearer ${env:SEND21_API_KEY}"
      }
    }
  }
}

Claude Desktop needs a stdio bridge, so the example uses mcp-remote:

{
  "mcpServers": {
    "send21": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://send21.io/mcp",
               "--header", "Authorization:${SEND21_AUTH_HEADER}"],
      "env": { "SEND21_AUTH_HEADER": "Bearer s21_your_key_here" }
    }
  }
}

Then ask: "Create a pay link for 40 EUR for invoice 1042, payable in USDC on Solana to my address." The model fills in create_payment_request and hands you a link.

Doing it from code

Inside your own agent you can call the same tool with the MCP TypeScript SDK. This is trimmed from examples/mcp-payment-request in the examples repo:

import { randomUUID } from "node:crypto";
import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { StreamableHTTPClientTransport } from "@modelcontextprotocol/sdk/client/streamableHttp.js";

const client = new Client({ name: "my-agent", version: "1.0.0" });
const transport = new StreamableHTTPClientTransport(new URL("https://send21.io/mcp"), {
  requestInit: { headers: { Authorization: `Bearer ${process.env.SEND21_API_KEY}` } },
});
await client.connect(transport);

const result = await client.callTool({
  name: "create_payment_request",
  arguments: {
    fiatCurrency: "EUR",
    fiatAmount: 40,
    options: [
      { currency: "Usdc", network: "Solana", address: process.env.MY_SOLANA_ADDRESS },
      { currency: "Btc", network: "Mainnet", address: "name@wallet.com", method: "Lightning" },
    ],
    orderId: "inv-1042",
    memo: "Logo design, round 2",
    idempotencyKey: randomUUID(),
  },
});

The response carries an id, a payPath and an expiry. Join payPath with https://send21.io and send it to the payer. They open the page, pick a currency (the rate locks for 15 minutes at that point), scan one QR code with any wallet and sign.

The example also has a dry-run mode that needs no key. It connects, fetches the live tool list and checks your arguments against the published input schema without creating anything:

npm run dry-run -- 25 EUR --option Usdc:Solana:<your-solana-address>

That is a cheap way to catch a wrong enum value before an agent does.

Three details that matter for agents

Fix the addresses in code, not in the prompt. The receiving address is the one field an attacker would want to change. If your app passes its own addresses into options and ignores whatever the model suggests, a prompt injection can at worst change the amount or memo on a link that a human still has to pay.

Retries are safe. Agents retry. Every create call can carry an idempotency key: the same key with the same parameters returns the original request, and the same key with a different amount, currency or address is refused with a 422 and creates nothing. If your agent might retry with a new key, set reuseOpenForOrder: true with an orderId, and you get the existing open link back instead of a second one for the same order.

Say what happens if nobody pays. When an agent hits a purchase over its budget and hands it to a human, the pay link can carry a declineNote, shown on the pay page as "If you don't pay: the booking is released at 18:00." The human gets the context the agent had.

Knowing when it was paid

You do not need to poll. send21 sends HMAC-signed webhooks with your orderId, for example draft.confirmed when the payment has its confirmations. Verify the X-Send21-Signature-V2 header: t=<timestamp>,v1=<hex>, an HMAC-SHA256 of "<timestamp>.<delivery id>.<raw body>" keyed with your signing secret. Because the time and the delivery id are signed too, refuse anything older than 5 minutes and a copied delivery cannot be replayed. The webhook receiver in the examples repo does this in constant time:

import { createHmac, timingSafeEqual } from "node:crypto";

export function verifySignatureV2(rawBody, header, deliveryId, secret) {
  if (!secret || typeof header !== "string" || typeof deliveryId !== "string" || !deliveryId) return false;
  const parts = Object.fromEntries(header.split(",").map((p) => [p.slice(0, p.indexOf("=")).trim(), p.slice(p.indexOf("=") + 1).trim()]));
  if (!/^\d+$/.test(parts.t ?? "") || !parts.v1) return false;
  if (Math.abs(Date.now() / 1000 - Number(parts.t)) > 300) return false; // older than 5 minutes
  const signed = Buffer.concat([Buffer.from(`${parts.t}.${deliveryId}.`), rawBody]);
  const expected = Buffer.from(createHmac("sha256", secret).update(signed).digest("hex"));
  const received = Buffer.from(parts.v1);
  return received.length === expected.length && timingSafeEqual(received, expected);
}

The original X-Send21-Signature (HMAC of the raw body only, no timestamp) is still sent so existing integrations keep working; use it only as a fallback when no V2 header is present. The webhook guide at send21.io/docs/webhooks describes both. Deliveries are retried with the same X-Send21-Delivery id, so skip one you have already handled.

Real payments are messy, and the events reflect that. A transfer from an exchange often arrives a little short because the exchange took its withdrawal fee. When a transfer within 10% of the billed amount reaches the address, send21 does not mark it paid; it sends draft.amount_mismatch and the receiver accepts or declines it, with a reason. Your agent can surface that to a human instead of guessing.

What a human sees before signing

The person who signs is the safety net, so the pay page tries to make the unusual visible. It shows a short "what changed" line only when something is out of pattern, such as a first payment to an address or an amount about three times the usual. Agents get the same signals through get_payment_request as changeSignals and changeNotes, so an agent can stop and ask before forwarding a link that looks off. Addresses are shown with the characters a look-alike address would have to copy highlighted, so the payer can compare them with their wallet.

What this is not

To be precise about the boundaries:

It is not an agent wallet. An agent cannot sign or pay on its own through send21.
There is no escrow and no "pay now, release later". Money moves once, wallet to wallet.
There are no payouts to bank accounts and no conversion to fiat.

If you need fully autonomous spending, this is the wrong tool. If you want an agent that does the paperwork while a human keeps the keys, it fits.

Try it

Fees are 0.49% on small payments, falling by size to 0.01%, capped at $100, and the receiver always gets the exact amount. You can try a real payment with test coins at https://send21.io/demo without an account or email, and the configs and examples above are in https://github.com/send21io/send21-examples. MCP setup details are at https://send21.io/docs/mcp. Questions go to info@send21.io.

What should an AI agent do when it hits its budget?

send21 — Sat, 10 Oct 2026 18:26:28 +0000

Give an agent a budget and sooner or later it reaches the edge of it. A research agent has spent 4.20 of its 5.00 USD cap, and the next step (one more paid API call, a dataset, a GPU minute) costs 1.50. What should happen now?

This post looks at three options and shows one way to build the third, with a small open-source example you can run offline.

Disclosure: I'm with send21. The example uses send21 to prepare a payment request, but the pattern works with any approval channel.

The problem

Spend caps exist because agents are not good judges of when something is worth paying for. A loop, a bad plan, or a prompt injection can turn "one more call" into a large bill. So we put a hard number in front of the agent.

The cap is the easy part. The hard part is what the agent does when the cap says no, because that is exactly the moment when the task is often nearly done and the extra spend is often justified.

Option 1: raise an error

The simplest thing: throw, log, stop.

It is safe. Nothing gets spent. But the run is lost, the context is gone, and someone has to notice the failure, read the logs, bump a config value and start again. In practice people respond by setting caps high enough that they never trigger, which defeats the point.

Option 2: overspend

Let the agent go over "just this once", maybe with a soft limit and an alert.

This keeps the task alive, but now the cap is a suggestion. If the agent can decide to exceed it, so can a buggy plan or an injected instruction. Any limit the agent can talk itself past is not a limit.

Option 3: hand off to a human

The agent stops at the cap, explains what it needs and why, and waits. A human decides. If they approve and pay, the agent continues from where it paused, with its state intact.

This keeps the cap hard and the task alive. It needs three pieces:

A guard that says "ok" or "handoff" before each paid step.
A way to ask a human for exactly the shortfall, with a link they can act on.
A way to resume the paused run safely when the human has acted.

Building option 3

The example repo is send21-over-budget-handoff: Python, MIT, a LangGraph adapter, an offline mock mode and 25 tests. It is an example, not an official LangGraph integration.

1. The guard

The cap check is deliberately boring:

@dataclass
class BudgetGuard:
    cap: Decimal
    spent: Decimal
    currency: str = "USD"

    def check(self, cost: Decimal) -> Literal["ok", "handoff"]:
        return "handoff" if self.spent + cost > self.cap else "ok"

4.20 + 1.50 > 5.00, so the step does not run.

2. The ask

On "handoff", the agent calls the send21 MCP tool create_payment_request with an amount, a payee address, a memo and an orderId. It gets back an id and a payPath, prints the pay link, and pauses with LangGraph's interrupt():

def wait(s: State):
    run = store.get_run(s["run_id"])
    data = interrupt({"pay_link": run["pay_link"], "order_id": run["order_id"]})
    # Resumed by a verified draft.confirmed. Raise the cap by the confirmed amount.
    cap = Decimal(s["cap"]) + Decimal(str(data.get("fiatAmount", run["pending_cost"])))
    return {"cap": str(cap), "handoff_step": None}

The important part is what the agent's key can do. It is created with the drafts:write scope only. send21 prepares payment instructions; the human opens the link and signs in their own wallet, and funds go straight from the payer's wallet to the receiver's wallet. send21 never holds keys or funds, and the agent's key cannot move funds. There is no signing code and no private key in the repo. The only way past the cap is a human signature.

3. The resume

When the payment is confirmed, send21 sends an HMAC-signed draft.confirmed webhook. The receiver checks X-Send21-Signature-V2 in constant time before parsing anything. It is an HMAC-SHA256 of "<timestamp>.<delivery id>.<raw body>", so the time and the delivery id are signed too: deliveries older than 5 minutes are refused and a copied delivery cannot be replayed. The legacy X-Send21-Signature (raw body only, no timestamp) is still sent for compatibility and is used only when no V2 header is present:

def verify_signature_v2(raw: bytes, header: str | None, delivery_id: str | None, secret: str) -> bool:
    if not secret or not isinstance(header, str) or not delivery_id:
        return False
    parts = dict(p.split("=", 1) for p in header.split(",") if "=" in p)  # t=<timestamp>,v1=<hex>
    t, v1 = parts.get("t", "").strip(), parts.get("v1", "").strip()
    if not t.isdigit() or not v1 or abs(time.time() - int(t)) > 300:  # refuse > 5 minutes old
        return False
    mac = hmac.new(secret.encode(), f"{t}.{delivery_id}.".encode() + raw, hashlib.sha256).hexdigest()
    return hmac.compare_digest(mac.encode(), v1.encode())


def verify_delivery(raw: bytes, headers: dict, secret: str) -> bool:
    v2 = headers.get("X-Send21-Signature-V2")
    if v2 is not None:  # V2 first; no fallback when a V2 header is present
        return verify_signature_v2(raw, v2, headers.get("X-Send21-Delivery"), secret)
    return verify_signature(raw, headers.get("X-Send21-Signature"), secret)  # legacy fallback

Then it stores the delivery id so retries do nothing, matches orderId to the paused run, and resumes it with Command(resume=...). Run status only moves forward, so a late or out-of-order event cannot undo a resume. A draft.amount_mismatch event marks the run for review instead of resuming.

Try it without paying anything

python3.11 -m venv .venv && . .venv/bin/activate
pip install -e ".[dev]"
python scripts/run_demo.py --mock
pytest

Mock mode uses a fake client and a locally signed fake webhook, so it needs no network and no account. The output is the same every run, and it is what the GIF above shows.

Using another framework

The core in handoff/ has no LangGraph imports. To port it, keep the guard, the client and the webhook receiver, and replace the adapter: pause at the handoff, and call resume(run_id, event_data) when the webhook arrives.

What is still open

The README lists what is not yet verified against the live API, for example testnet support for API keys and the exact payPath format. Live mode keeps checkpoints in memory, so use a persistent checkpointer for anything beyond a demo.

Takeaway

A spend cap is only useful if hitting it is a normal, recoverable event. Erroring throws work away, overspending makes the cap meaningless. Handing off keeps the cap hard and puts the decision with a person, who approves with a signature the agent cannot forge.

Repo: https://github.com/send21io/send21-over-budget-handoff
More examples: https://github.com/send21io/send21-examples
send21 MCP: https://send21.io/mcp
Questions: info@send21.io

How to invoice in EUR or SEK and get paid in EURC to your own wallet

send21 — Tue, 06 Oct 2026 09:36:24 +0000

Disclosure: this is written by the team behind send21.

You have a client in another country who is happy to pay in stablecoins. You invoice in EUR or SEK, because that is what your books are kept in. Then the questions start. Which rate turns the invoice into a stablecoin amount? What exactly should the client send? What if the amount that arrives is a little short?

This guide shows how to handle that with send21, non-custodial software that creates pay links and prepares payment instructions. The payer signs in their own wallet, and the funds go from their wallet straight to yours. send21 never holds keys or funds.

The problem

Card and bank fees on cross-border payments add up. Stablecoins avoid some of that, but bring bookkeeping questions:

The invoice says 10 000 SEK. The client pays in EURC. What rate was used?
When was that rate taken, and from which source?
Which document goes into your books?

A wallet address pasted into an email answers none of these.

What you need

A self-custody wallet that can receive EURC or USDC on Solana, Ethereum or Base.
A send21 account. You sign in with a passkey, or with email and password plus a second factor.
A client who can pay in EURC or USDC from a wallet or an exchange.

If you want to see the whole flow first, the testnet demo at send21.io/demo runs a real payment with test coins. No account and no email needed.

Step by step: a pay link priced in EUR or SEK

New accounts start on a "Get paid" screen. It helps you create your first pay link. The steps:

Start a new payment request from the "Get paid" screen.
Set the price in your invoice currency, such as EUR or SEK. Prices work in 161 fiat currencies.
Choose where you want to be paid: your own wallet, on the network you use for EURC or USDC.
Create the link and send it to your client together with your invoice.

For clients in the EU, EURC is the natural first choice, with USDC as the alternative. EURC and USDC both work on Solana, Ethereum and Base.

What your client sees

The client opens the link and picks a currency. They scan one QR code and pay from any wallet. They do not need a special wallet or a send21 account.

The client signs the payment in their own wallet. send21 does not sign anything and does not broadcast anything.

The rate is locked and recorded

The fiat price is converted at an exchange rate that is locked for 15 minutes. send21 records the rate source and the time.

send21 also creates a branded PDF with the payment details. Keep it with your invoice. Rules for recording stablecoin payments differ between countries, so check your bookkeeping with your accountant.

When an exchange withdrawal arrives a bit short

Exchanges often deduct a withdrawal fee from the amount sent. Your invoice says one amount and slightly less arrives.

send21 flags this. When a payment within 10% of the billed amount reaches your receiving address after the pay link was created, send21 alerts you by email, in the app and by webhook. You decide what happens next. You can accept it as paid with one click, or ask the client for the difference. The client sees a notice not to pay again, so they do not pay twice.

This has limits. A payment more than 10% off is not flagged, and neither is one that could belong to several open payments on the same address. Then you check your wallet yourself.

What it costs

The fee is 0.49% on payments under $10, falling by tier to 0.01% above $100,000. The minimum is $0.01 and the maximum is $100 per payment. On pay links the fee is billed to your account and settled later in one payment. It is never taken out of the client's payment, so you receive the exact amount. There is no subscription, no setup fee and no exchange-rate spread. The full schedule is at send21.io/pricing.

For developers

If you build tools for freelancers, the same flow is available in code:

MCP server at https://send21.io/mcp (Streamable HTTP), with tools for drafts, payment requests, rates and fees. An AI agent can create and track a pay link. It cannot pay, because no key send21 issues can move funds. A human signs.
REST API with scoped keys, idempotency keys and batch creation of up to 25 per call. Docs are at send21.io/swagger.
Webhooks signed with HMAC, so your backend can verify that an event came from send21 before marking an invoice as paid.
A machine-readable overview at send21.io/llms.txt.

The public examples repo at github.com/send21io/send21-examples has a script that creates a pay link through MCP and a webhook receiver that verifies the signature.

Honest limits

Know what send21 does not do:

No payouts to bank accounts and no conversion to fiat. You receive stablecoins in your own wallet.
A human always signs. Neither send21 nor an agent using its API can pay on anyone's behalf.
Payments that are more than 10% off, or that could match several open payments, are not flagged and need a manual check.
This guide covers EURC and USDC, the stablecoins we suggest for EU clients.
It is for people who are comfortable holding stablecoins and looking after their own wallet.

Try it

Run a test payment in the demo at send21.io/demo. No account needed. Then create a real pay link from the "Get paid" screen for your next invoice.

Questions, or a workflow we do not cover yet? Write to info@send21.io.

An agent creates a payment draft; a human signs

send21 — Sun, 06 Sep 2026 05:26:25 +0000

If you are building an AI agent that needs to move money, you have a custody problem the moment the agent can sign.

That is the quiet part of most "agent payments" demos. The agent can create an invoice. The agent can call an API. The agent can even assemble a transaction. Then someone asks the only question that matters:

Where do the keys live?

If the answer is "in the agent," you did not build a payment agent. You built a hot wallet with a chat UI.

The problem

Agents are good at structured work: create a draft, attach a memo, lock a rate, wait for a webhook, book the order. They are terrible at being custodians.

A model can be jailbroken. A tool loop can be tricked into calling the wrong endpoint. A compromised server can dump process memory. A "scoped assistant" that still holds a seed is not scoped at all — it is a custodian that also writes poetry.

So the product question is not "can an agent pay?"

The product question is:

Can an agent prepare a payment without ever being able to spend?

That single constraint changes the architecture. It also changes what you are allowed to claim in marketing.

Wrong patterns (keys in the agent)

A few patterns show up again and again.

1. Seed or private key in the agent runtime

The agent "pays" by signing. It is convenient in a demo. It is catastrophic in production. Anyone who can prompt the model, call its tools, or exfiltrate the process can spend.

2. Hot wallet behind the agent with broad spend rights

Same failure mode with an extra hop. The agent does not hold the key itself; it holds the ability to move funds. That is still custody by another name.

3. "The agent pays by itself" as a feature

Auto-debit sounds magical until you need an audit trail, a human review step, or a recovery story after a bad tool call. If the agent can broadcast, the blast radius is the balance.

4. Treating "non-custodial" as a promise

Marketing that says "we never steal your funds" while the server can sign is a promise. Structure would mean the server cannot sign — even when compromised, even when an engineer is wrong, even when an agent is clever.

If your architecture needs the agent to hold keys, sign, or broadcast, you are not solving agent payments. You are moving a wallet into a less trustworthy process.

The right pattern: instructions only

A cleaner split looks like this:

An agent (or a human) creates a payment draft — receiver address, amount (exact or fiat-pegged), network, memo.
The sender's own wallet funds and signs.
The sender's own node or wallet broadcasts.
Your backend watches the chain and fires signed webhooks when the payment is seen and confirmed.

In that model, software prepares instructions. Wallets do the paying.

That is what send21 is built for.

send21 creates clean, verifiable payment instructions for BTC, USDC, USDT, and EURC. Funds move from the sender's own wallet to the receiver.

We never touch keys. We never touch coins.

Non-custodial by structure, not by promise: no hot wallets, no private keys stored, no signing code in the product path. A full server compromise cannot move a single satoshi, because there is nothing to move with.

Scoped API keys that cannot spend

Agents talk to send21 over REST — the same surface a human uses in the UI. Everything a human does in the product, an agent can do with an API key. The difference is what that key is allowed to do.

Grant only what the agent needs, for example:

drafts:write
drafts:read
webhooks:manage

No scope can ever move funds. Nobody can. That is the point.

So the agent can:

create a draft
fetch a transaction template
track status
receive draft.seen / draft.confirmed webhooks

The agent cannot:

sign
broadcast
empty a wallet
"just send it"

The human — or the wallet / HSM that holds the keys — remains the only party that can authorize value transfer.

A typical flow:

agent → create draft → fetch tx template → fund & sign in own wallet → broadcast → webhook: draft.confirmed

Idempotent creation (retry-safe Idempotency-Key), locked rates for fiat-priced drafts, and HMAC-SHA256 signed webhooks make that loop machine-readable without turning the agent into a custodian.

Payment drafts vs pay links

Same non-custodial idea. Different wallet shape.

Payment drafts (Bitcoin multi-output / PSBT path)

Need a PSBT-capable wallet such as Bitcoin Core, Sparrow, or Electrum. The sender reviews every output — including any transparent platform fee output — then signs locally.

Checkout pay links / QR

Single-transfer pay links with a standard QR (bitcoin: / Solana / Ethereum URI). Any wallet that can scan a QR and send an exact amount works. Useful for shops and "any screen" checkouts — phone, tablet, kiosk — without a branded terminal in the middle.

Either way:

instructions first
signature in the user's wallet
confirmation on-chain
webhook to book the order

Agents that prepare drafts stay on the draft API with spend-impossible scopes. Shop and stall checkouts use payment requests / pay links / QR. Do not collapse those into "the agent paid."

When send21 fits

send21 fits when you want:

Agents that prepare payments without spending rights
Humans in the loop for signing and broadcast
Fiat-priced drafts or pay links with a locked rate, paid in BTC / USDC / USDT / EURC
Direct wallet-to-wallet settlement with no platform custody
Webhook-first reconciliation for shops, agents, and backends

It is less of a fit when you need a full self-hosted store stack, Lightning as a processor product, fiat payout rails, or an agent that auto-debits without a human signature. Those are different problems — and some of them already have strong tools. Use those tools when they fit. send21 is for the slice where the agent must prepare money movement without ever being able to do it.

The short version

An agent creates a payment draft. A human signs.

That is how you get automation without handing the keys to the model.

Direct. Non-custodial. Yours.

https://send21.io