ZBD vs ln.bot: Lightning developer API comparison

ZBD and ln.bot are both hosted, custodial Lightning APIs. Each runs the nodes for you, creates invoices, pays Lightning addresses and has an MCP server. They are built for different customers. ZBD builds payments for games, from gamertags and Login with ZBD to Embedded Accounts, launched in August 2026, which hold player balances in fiat and in-game currencies. ln.bot builds wallets for software: bitcoin wallets created by API, each with its own Lightning address, key and MCP server, and tools to charge and pay per request with L402.

Checked on 23 October 2026: the ZBD details below come from ZBD's docs, npm packages and GitHub, linked where they appear.

Getting access

ZBD onboarding starts with a short sales call, followed by business verification (KYB) before production features open. Pricing depends on your expected volume and is agreed on that call. The ZBD API is available in every US state except New York, and its coverage page lists 102 countries it doesn't serve yet.

ln.bot starts with an API call: register() needs no key and no identity check, and returns the user key that creates wallets. Prices are public. Receiving is free, paying out over Lightning costs 0.25% (minimum ₿1) plus the network fee, another 0.25% and routing, and transfers between ln.bot wallets are free.

Balances for players, or wallets for agents

Embedded Accounts give each player a balance inside your game, in fiat or in a virtual currency you define and value with ZBD, with one balance per currency shared across your games. You create a player from your backend with your own identifier:

curl -X POST https://api.zbdpay.com/api/v1/users \
  -H "x-api-key: $ZBD_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"publisher_user_id": "player-1187"}'

Players can hold a balance, earn and spend without verifying their identity; loading fiat, selling for fiat and cashing out require verification. The docs don't describe a Lightning address or a bitcoin wallet for each player.

An ln.bot wallet is a bitcoin wallet. One call creates it, with a random Lightning address any Lightning wallet can pay, and a wallet key that reaches that wallet alone:

import { LnBot } from "@lnbot/sdk";

const ln = new LnBot({ apiKey: process.env.LNBOT_USER_KEY }); // uk_...

const { walletId, address } = await ln.wallets.create();
const { key } = await ln.wallet(walletId).key.create(); // wk_..., this wallet only

console.log(address); // a random address, such as x4k7m2@ln.bot

They suit different jobs. A game that wants player balances in its own currency, with cash-out to the payment methods of each player's country, wants Embedded Accounts. An agent that pays for things over Lightning, or gets paid by other agents, wants a wallet of its own.

Amounts: millisatoshi strings and integers

ZBD's official TypeScript library, @zbdpay/payments-sdk, takes amounts as strings of millisatoshis. ln.bot takes integers in bitcoin's smallest unit. The same ₿1,000 invoice on each:

import ZbdPayments from "@zbdpay/payments-sdk";

const zbd = new ZbdPayments({ apikey: process.env.ZBD_PAYMENTS_API_KEY });

await zbd.lightningCharges.create({
  amount: "1000000", // millisatoshis, so ₿1,000
  description: "Report #42",
  callbackUrl: "https://example.com/zbd/callback",
});

const invoice = await ln.wallet("wal_...").invoices.create({
  amount: 1000, // ₿1,000
  memo: "Report #42",
});
console.log(invoice.bolt11);

This is the line to check when porting code between the two: amount: "1000" on ZBD is ₿1.

ZBD reports a charge's progress by posting to its callbackUrl. ln.bot sends webhooks and also streams events, so a worker can wait for a payment without exposing an endpoint.

Reusable payment requests

A ZBD Static Charge is a reusable LNURL that takes variable amounts and, by default, doesn't expire. Every ln.bot wallet has one of these already: its Lightning address is a static LNURL-pay endpoint that accepts ₿1 to ₿1,000,000 per payment, with an optional comment.

ZBD also works in the other direction with Withdrawal Requests, single-use QR codes that someone scans to pull bitcoin out (LNURL-withdraw). ln.bot has no equivalent; to pay someone, a wallet sends to their address or invoice.

MCP and L402

Both have an MCP server, run in different places. ZBD's @zbdpay/payments-sdk-mcp, which ZBD calls its official MCP server for the Payments API, runs on your machine through npx with your API key and exposes the payments API as tools. ln.bot's is a hosted endpoint per wallet, https://api.ln.bot/v1/wallets/{walletId}/mcp, with 12 tools, three of them for L402 (see the MCP docs). Either way the tools can spend whatever the key reaches, so keep an agent's balance to what it may spend.

ZBD's current docs, SDK and MCP server don't cover L402. Early in 2026, ZBD's GitHub organisation published L402 middleware and a client under the Axo name (axobot-pay); those repositories are now archived. ln.bot covers both sides. l402.paywall puts a price on a route, l402.client pays within a per-request cap and a budget, and the C# packages do the same for ASP.NET Core:

import express from "express";
import { l402, LnBot } from "@lnbot/l402";

const app = express();
const ln = new LnBot({ apiKey: process.env.LNBOT_USER_KEY });

// ₿10 per request, paid into this wallet
app.use("/api/premium", l402.paywall(ln, { walletId: "wal_...", price: 10 }));

app.get("/api/premium/forecast", (req, res) => {
  res.json({ forecast: "sunny", paymentHash: req.l402?.paymentHash });
});

app.listen(3000);

By default a paid token buys one request. The pay-per-call guide walks through both sides.

What ZBD has for games

• Login with ZBD, an OAuth2 login that shares a player's gamertag and Lightning address, so your app can pay them.
• ZBD Earn, a Unity SDK for real-money rewards in mobile games, open to approved partners.
• Embedded Accounts, described above, which ZBD announced in August 2026 alongside Embedded Payouts and branded debit cards.
• A sandbox project for testing, limited to gamertag payments. ln.bot has no sandbox.

ln.bot has nothing game-specific. It doesn't handle fiat or cash-outs, doesn't identify end users, and works on Lightning only. It is custodial too: ln.bot runs the nodes and the channel liquidity, and balances sit on its nodes, so a wallet is an operational balance for spending rather than savings.

Side by side