Feedback
Sign in./start

Site navigation

Theme

Learn

  • Roadmaps

Build

  • Projects
  • Developer Tools

Contribute

  • Open Source Projects
  • Issues
  • Reviews
  • First Contribution
  • BountiesSoon
  • Feedback

Prove

  • Builders

Ecosystem

  • Partners
  • Get Funded↗
  • HackathonsSoon
Sign in./start-building

Become an Open Source Builder. Learn. Build. Contribute. Prove.

Feedback welcome — open a GitHub issue.

Learn

RoadmapsStart Building

Build

ProjectsDeveloper Tools

Contribute

Open Source ProjectsIssuesReviewsFirst ContributionSupportFeedback

Prove

Builders Directory

Account

Sign in

Legal

PrivacyTermsCredits

© 2026 Pull // code MIT · curriculum CC BY-SA 4.0

PrivacyTermsCredits

lesson // lightning

Lightning POS

Build a point-of-sale app that creates invoices and tracks settlement.

advanced2 weeksproject // lightning-pos

Public lesson — sign in to track progress on this roadmap.

./sign-in

On this page

Learning objectives

  • Create invoices from a backend node
  • Subscribe to invoice settlement events
  • Design a cashier UX for pending vs paid

study // plan

Lessons are primers. Start with Step 1 (required reading) when present, then follow the numbered steps in the article. Depth comes from primary sources, labs, reflection, and evidence.

Research on Bitcoin Search

Step 1 // Required reading

Complete these before the numbered steps in the lesson body. Links are listed here once — not repeated below.

  • docsProject Spec: Lightning POS

    Pull project page — acceptance criteria and submit flow.

  • boltBOLT11

Reflection prompts

  1. Explain Lightning POS to a teammate without jargon - what problem does it solve?
  2. What would break in production if you misunderstood Lightning POS?
  3. Which BOLT (or implementation doc) is the source of truth for this topic, and what did you verify there?

Lab // Project milestone evidence

Complete Steps 2–4. Ship create invoice → QR → settle (or expire) on Polar/regtest and capture demo evidence before marking complete.

evidence required

  • ·Link to public repo or branch
  • ·Screenshots or commands proving charge → paid (and expiry path)
  • ·Short note of one failure case (duplicate charge, late pay, node down)
  1. 01

    Worked mental model

    Re-read the diagrams in this lesson once out loud in plain language. If you cannot explain the flow to a friend without jargon, pause and revisit the Mastering Bitcoin / Mastering Lightning chapters linked in Resources. Chapter references are intentional, not decorative.

  2. 02

    Hands-on habit

    Every protocol idea should be paired with one local experiment. That habit turns reading into builder instinct.

    1. Reproduce the happy path on regtest (or Polar for Lightning)
    2. Break it on purpose (wrong fee, expired invoice, offline peer)
    3. Write down what error you saw and which layer produced it (wallet, node, mempool, peer)
  3. 03

    Glossary check

    Pick three terms from this lesson and define them in one sentence each without opening notes. Weak definitions mean the lesson is not finished yet.

  4. 04

    Resource order

    Use Resources in order: narrative book chapter first, then BIP/BOLT for precision, then implementation docs for commands. Jumping straight to RPC flags without the mental model creates brittle knowledge.

A Lightning POS turns protocol knowledge into a merchant tool: show QR, wait for payment, print/mark paid.

Complete Step 1 // Required reading in the study plan above, then continue here. This opens Lightning Projects.

Step 2 — Goal

  1. Create invoice for cart total
  2. Display BOLT11 QR
  3. Detect settlement via websocket/webhook/RPC subscribe
  4. Handle expiry and cancel

Loading diagram…

POS mints invoices and listens until settled or expired.

Done when: You can narrate pending vs paid vs expired without opening the code.

Step 3 — Milestones

PhaseShip
Milestone ABackend mint invoice + return bolt11
Milestone BCashier UI: QR + pending/paid states
Milestone CSubscribe to settle; expiry/cancel; idempotent charge keys

Idempotent tickets

Bind each charge to an idempotency key so refreshes do not create duplicate invoices accidentally.

Done when: Milestone A works before you polish UI chrome.

Step 4 — Build & evidence (lab)

Implement against /projects/lightning-pos. Capture repo link, happy-path demo, and one failure case.

Common mistakes

  • Creating a new invoice on every UI refresh
  • Treating “invoice created” as paid
  • Blocking the cashier UI on synchronous pay RPCs without a pending state

Done when: Lab evidence is filed.

Next lesson

Node Ops Dashboard — channels, peers, balances, and routing revenue.

further reading

  • docsLND invoices API
  • bookMastering the Lightning Network

    Ch. 15: Payment Requests

build // challenge

project // lightning-pos

./open-spec./submit

Apply what you learned in a focused build session. Ship something small, test it on regtest, and document your approach before moving on.

progress // sign in

Reading is public. Sign in to mark lessons complete, sync across devices, and unlock your roadmap.

./sign-in-to-track

discussion

Discussion

prevWatchtowersnextNode Ops Dashboard

On this page

Press Shift + ? for keyboard shortcuts.

Press R to research on Bitcoin Search.

No questions yet — be the first to ask.