Reading Manna Bitcoin Wallet's payment ledger from your own code

Manna runs three payment rails behind one balance — on-chain Bitcoin, the Lightning Network, and Liquid L-BTC — plus a merchant point-of-sale that, per its Play Store listing, gets a vendor accepting Bitcoin in under a minute. It keeps no account on a server: the maker, Manna Open Economy, LLC, describes it as self-custodial and open source, with no KYC and no personal data collected, not even an email. That shape decides how you reach the data. There is no portal to log into; there are payment events, invoices, and on-chain records to read, and open protocol standards that describe every one of them.

The honest read: a self-custodial wallet is mostly a client over public ledgers and open Lightning standards, so most of what an integrator wants is reachable without ever touching the seed. We build clients against those standards and confirm Manna's exact invoice and POS shapes by watching the live app under your authorization. On-chain and Liquid history come from watch-only descriptors; Lightning payments and a hosted Lightning Address come from the documented LNURL and BOLT surfaces.

What sits inside a Manna wallet

Manna's own pages and store listing name most of these surfaces directly. Here is where each lives and what a build does with it.

Authorized ways in

Three routes genuinely fit a wallet built this way. We set up access with you as part of the work — a consenting account, a signet or testnet run, and watch-only material handed over during onboarding.

1 — Open-standard clients plus protocol analysis

Lightning, on-chain Bitcoin, and Liquid are all described by published specs: BOLT11 and LNURL-pay for invoices and the Lightning Address, BIP-21 and descriptor standards for on-chain, the Elements model for Liquid. We write clients straight against those, then confirm Manna's specific invoice memos, amount limits, and POS payloads by observing the app under your authorization. Reachable: invoices, payments, balances, the Lightning Address, and POS orders. This is the route we lean on, because open standards do not break when the app ships a redesign.

2 — User-consented watch-only access

With the account holder's go-ahead, the client reads their own wallet directly: an account xpub and the Liquid master blinding key give full on-chain and Liquid history, and Lightning payment history comes from the wallet's export. Read-only throughout — the seed stays on the device and the client never gains spend authority.

3 — Native export as a backfill

Where Manna can hand out a transaction export, we ingest it as a one-time backfill to seed history before the live watcher takes over. Useful for the first sync; not something to lean on for fresh events.

What you get

The headline is code that runs, not paperwork. For Manna that means:

• Runnable SDK clients in Python and Node.js (Go on request) that resolve a Manna Lightning Address, request and settle BOLT11 invoices, and read on-chain and Liquid history.
• An event handler that fires on Lightning settlement and a cursor-based watcher that reconciles on-chain and Liquid confirmations.
• An automated test suite that runs against signet and Liquid testnet with a mocked LNURL-pay endpoint, so a changed invoice shape shows up as a failed assertion.
• A sync design that splits the fast push path from the slower confirmation sweep, with a documented backfill for first load.

Then the supporting set: a normalized OpenAPI-style spec for the unified payment model, a protocol and auth-flow note covering the LNURL callback and session handling, interface documentation, and data-retention guidance for the records you keep.

The same idea, in code

A common first build resolves a Manna Lightning Address, asks for a BOLT11 invoice, and watches it settle. Field names below are confirmed against the live app during the build; treat the snippet as illustrative.

# Illustrative client: Manna Lightning Address -> BOLT11 -> settlement
import httpx

def request_invoice(address: str, amount_sats: int, memo: str = ""):
    name, domain = address.split("@")          # e.g. shop@mannabitcoin...
    meta = httpx.get(f"https://{domain}/.well-known/lnurlp/{name}").json()
    msat = amount_sats * 1000
    if not (meta["minSendable"] <= msat <= meta["maxSendable"]):
        raise ValueError("amount is outside the payee's LNURL limits")
    res = httpx.get(meta["callback"], params={"amount": msat, "comment": memo}).json()
    return res["pr"]                           # BOLT11 payment request

def is_settled(payment_hash: str) -> bool:
    # Lightning settles on the payment hash, not a block height.
    r = httpx.get(f"{NODE}/v1/invoice/{payment_hash}").json()
    return r.get("state") == "SETTLED"

One payment shape across three rails

Downstream code should not care which rail carried the money. We normalize every receipt to one record, where the confirmation field is null for Lightning and a depth for the chains:

{
  "event": "payment.settled",
  "rail": "lightning",            // onchain | lightning | liquid
  "amount_sat": 21000,
  "reference": "<payment_hash | txid>",
  "confirmations": null,          // null for Lightning; depth otherwise
  "pos_order_id": "ord_8842",
  "payee": { "lightning_address": "shop@…", "branta_verified": true },
  "settled_at": "2026-06-15T12:00:00Z"
}

Where teams plug this in

• Checkout settlement. A storefront asks the client for a BOLT11 from the merchant's Manna Lightning Address, then releases the order on the settlement event.
• Nightly reconciliation. The watcher backfills on-chain, Lightning, and Liquid history into an accounting ledger, each entry tagged by rail.
• Treasury monitoring. Balances across the three rails feed an alert when one side needs a Boltz swap to rebalance Lightning against Liquid.
• POS-to-till sync. Orders from Manna's merchant toolkit mirror into an existing point-of-sale or inventory system.

Custody, consent, and what governs this

No open-banking or account-aggregation regime applies here, and we do not pretend one does. Manna custodies nothing and, per its site, collects no personal data, so there is no covered institution holding consumer records to share under a data-rights rule. The dependable basis is simpler and stronger: the wallet holder authorizing access to their own funds and history, and open public standards anyone may implement. Bitcoin and Liquid records sit on public ledgers; Lightning and LNURL are documented specs.

How we work the data matters more than any single statute. Access is read-only, the seed phrase is never requested or stored, logs record what was read and when, and we keep an NDA in place where a build touches a merchant's customer or order data. The Branta merchant-verification layer the app added — which uses zero-knowledge proofs so it learns nothing about the addresses involved, per Bitcoin Magazine — is carried as a trust flag on the payee, not copied as new personal data.

Engineering details we handle

Two things about Manna shape the build, and we account for both up front.

Three rails, three meanings of "paid." A Lightning payment is final the instant its hash clears; an on-chain receipt firms up over confirmations; Liquid has its own short confirmation depth. We model each separately and only emit a normalized settled event when the rail's own finality rule is met, so a downstream system never treats a zero-conf on-chain spend as done.

The Lightning Address is a hosted endpoint with limits. An LNURL-pay callback advertises minimum and maximum sendable amounts and whether a comment is allowed. We map those bounds so generated invoices match what Manna will actually issue, rather than failing at the callback. And because Boltz swaps move value between Lightning and Liquid, we track each swap's two legs so a rebalance is not double-counted as two unrelated payments.

Sources

Checked on 2026-06-15 against the maker's own site, the Google Play and Apple App Store listings, and recent coverage of the wallet's merchant-verification work. Specific items — the three rails, the merchant toolkit, no-KYC posture, and the Branta integration — trace to the pages below.

• mannabitcoin.com — self-custody model, merchant toolkit, BTC map, no personal data, Manna Open Economy, LLC
• Google Play listing — on-chain, Lightning, and Liquid support; POS in under a minute
• Bitcoin Magazine — Branta Guardrails verification, BOLT11, BTCPay and Zaprite, CEO Adam Simecka
• Apple App Store listing — iOS availability and product description

OpenFinance Lab · Bitcoin protocol engineering notes, checked 2026-06-15.

Other wallets in the same orbit

If you are unifying Bitcoin payment data, these neighbours come up. They share the rails and the self-custody model, so a single integration layer can usually cover several.

• Phoenix — Lightning-first mobile wallet with automated channel management; holds payment and channel state.
• Breez — non-custodial wallet with its own POS, an SDK, and Lightning payment records.
• Muun — on-chain and Lightning in one balance, abstracting channels away from the user.
• Blue Wallet — multiple Bitcoin and Lightning wallets with import and export of transaction history.
• Zeus — connects to a user's own LND or Core Lightning node, exposing rich node and payment data.
• Aqua — privacy-focused multi-layer self-custody spanning Bitcoin and Liquid.
• Bitkit — self-custodial on-chain and Lightning wallet that provisions inbound liquidity.
• Bull Bitcoin — on-chain savings with Lightning and Liquid spending and Boltz atomic swaps.
• Blink — Lightning wallet with a Lightning Address and merchant tooling.

Screens from the app

Store screenshots, useful for spotting which surfaces a build needs to read.

Questions integrators ask

How do you tell a Lightning payment apart from an on-chain or Liquid one when both hit the same wallet?

Each rail signals settlement differently. Lightning resolves on a payment hash with no block height, on-chain Bitcoin needs confirmation depth, and Liquid carries its own confirmation count. We model the three separately so a single normalized paid event downstream means the same finality no matter which rail carried the money.

Does a paid POS invoice reach us as a real-time event, or do we have to poll for it?

For a merchant POS surface we build an event path: a Lightning invoice settles instantly, so the client emits a settlement event the moment the payment hash clears, and on-chain or Liquid receipts are picked up by a cursor-based watcher that walks new confirmations. You get a push for the fast rail and a reconciled sweep for the slower ones.

Manna is self-custodial, so can you read our balances and history without our seed phrase?

Yes. We design read paths around watch-only material such as an account xpub and the Liquid master blinding key, plus the wallet's own transaction export. The client sees balances and history but never holds spend authority, and the seed never leaves the device.

What does the Branta merchant-verification data look like to an integrator?

Branta acts as a side channel that confirms a payee's identity before money moves, surfacing a logo and company details in the wallet. For an integrator it is a verification flag attached to a payee rather than a payment rail of its own, so we carry it as an attribute on the payment record rather than a separate data feed.

Starting a build

A first working client for one rail usually lands inside one to two weeks. Take it as source you own — runnable code and documentation from $300, invoiced only after delivery once you are happy with it — or skip the build and call our hosted endpoints instead, paying per call with nothing up front. Either way you bring just the app name and what you want out of its payment data; access, a test account, and the compliance side are arranged with you as we go. Tell us what you are after at our contact page and we will scope it.