Build a Lightning payment lab.
Build one small checkout that you can explain, reproduce and deliberately break. The goal is evidence of engineering judgment.
This is an original project brief, not a production deployment tutorial. A useful first version has one item, one test invoice and a clear record of what happened. Keep real customer money and production credentials out of the experiment.
1. Define the demonstration.
Choose a simple user story: “A customer can request a test invoice, see whether it has been paid and get an accurate result after reopening the page.” Write down what the app owns and what the node owns. A browser should not become the authority on whether a payment settled.
2. Make the environment reproducible.
Polar can create local Bitcoin and Lightning regtest networks. Follow its current installation instructions and your chosen node’s API documentation. Record the operating system, Docker requirements, node versions and network configuration in the project README.
Use separate test configuration. Include sample environment-variable names, never working credentials. Keep the node integration behind a small server-side adapter so the UI can also run against predictable test fixtures.
3. Model payment states before adding polish.
| State | What the user sees | Evidence to capture |
|---|---|---|
| Invoice requested | A visible loading state and a way to recover from a request failure. | A deliberately failed invoice request. |
| Awaiting payment | Amount, payment request and status in plain language. | A test invoice tied to the correct order. |
| Payment confirmed | A durable confirmation derived from the backend’s verified status. | Reopening the page retains the correct outcome. |
| Expired or unavailable | A clear explanation and an appropriate retry action. | An expired request and an unavailable node. |
4. Test more than the happy path.
Create a three-node network if your chosen setup supports it. Demonstrate one successful payment, then make a route unavailable and show the resulting behavior. Record the actual error returned by the implementation. Do not label every failure “insufficient funds.”
- Refresh while waiting for payment: does the order retain its status?
- Deliver the same status event twice: does fulfillment still happen once?
- Disconnect the node: does the UI distinguish an unknown status from an unpaid order?
- Request another invoice: can the backend distinguish the old request from the new one?
The exact event names and invoice behavior depend on the implementation. Consult its documentation; the Lightning specifications provide protocol context, not a substitute for the API you are using.
5. Package the work for a reviewer.
Publish a concise README, setup instructions, a diagram of the browser/server/node boundary, a short demo and your test results. List known limitations such as single-node dependencies or incomplete reconciliation. Include the commit that produced the demonstration.
A strong CV bullet names the result and its limits: “Built a local Lightning checkout prototype with persistent order state and duplicate-event tests.” Link the repository and test evidence. Do not describe a regtest prototype as a production payment service.
For a commerce-oriented next project, explore BTCPay Server’s documentation. For a deeper Lightning integration, compare LDK and its related tools.
Keep the evidence.
Download a worksheet to record what you tried, what happened and what you would improve.
Download evidence worksheet ↓