Paid ATM app ID provisioning via Lightning invoice #9

New issue

Open

opened 2026-02-28 16:21:53 +00:00 by padreug · 0 comments

padreug commented

2026-02-28 16:21:53 +00:00

Owner

Summary

Allow ATM operators to purchase an app ID by paying a Lightning invoice, removing the need for admin API access during provisioning.

Motivation

Currently, creating an ATM app ID requires:

Admin credentials (ADMIN_TOKEN)
Calling POST /api/admin/app/add manually or via the provisioning script

This is fine for self-hosted setups, but doesn't scale for third-party ATM operators who want to connect their machines to an existing Lightning.Pub instance. We need a self-service flow.

Proposed Flow

ATM operator (or the machine itself) calls a public endpoint: POST /api/atm/purchase
LP returns a Lightning invoice for 10,000 sats (configurable)
Operator pays the invoice
On payment confirmation, LP:
- Creates a new app via AddApp
- Generates a unique ATM keypair (or accepts a provided pubkey)
- Returns the app_id, connection credentials, and any other info needed for .env
The ATM can now connect using the returned credentials

API Sketch

POST /api/atm/purchase
Request:  { "name": "my-atm-01", "pubkey"?: "<optional nostr pubkey>" }
Response: { "invoice": "lnbc100u1p...", "payment_hash": "abc123" }

GET /api/atm/purchase/:payment_hash
Response (pending):  { "status": "pending" }
Response (paid):     { "status": "paid", "app_id": "...", "credentials": { ... } }

Configuration

New LP config options:

ATM_PURCHASE_PRICE_SATS — cost per app ID (default: 10,000)
ATM_PURCHASE_ENABLED — toggle (default: false)

Considerations

The purchase endpoint should be unauthenticated (the invoice payment is the auth)
Rate-limit the creation endpoint to prevent spam
Consider whether app IDs should expire or require renewal
Could integrate with the existing extension system (withdraw extension already handles LNURL)
The 10k sats price point is a starting suggestion — should be operator-configurable

Context

This came up while setting up the Douro ATM. The current provisioning script (provision-atm.sh) works but requires SSH + admin token access. A paid self-service flow would enable a marketplace model where LP operators can sell ATM connectivity.

## Summary Allow ATM operators to purchase an app ID by paying a Lightning invoice, removing the need for admin API access during provisioning. ## Motivation Currently, creating an ATM app ID requires: 1. Admin credentials (`ADMIN_TOKEN`) 2. Calling `POST /api/admin/app/add` manually or via the provisioning script This is fine for self-hosted setups, but doesn't scale for third-party ATM operators who want to connect their machines to an existing Lightning.Pub instance. We need a self-service flow. ## Proposed Flow 1. ATM operator (or the machine itself) calls a **public** endpoint: `POST /api/atm/purchase` 2. LP returns a Lightning invoice for **10,000 sats** (configurable) 3. Operator pays the invoice 4. On payment confirmation, LP: - Creates a new app via `AddApp` - Generates a unique ATM keypair (or accepts a provided pubkey) - Returns the `app_id`, connection credentials, and any other info needed for `.env` 5. The ATM can now connect using the returned credentials ## API Sketch ``` POST /api/atm/purchase Request: { "name": "my-atm-01", "pubkey"?: "<optional nostr pubkey>" } Response: { "invoice": "lnbc100u1p...", "payment_hash": "abc123" } GET /api/atm/purchase/:payment_hash Response (pending): { "status": "pending" } Response (paid): { "status": "paid", "app_id": "...", "credentials": { ... } } ``` ## Configuration New LP config options: - `ATM_PURCHASE_PRICE_SATS` — cost per app ID (default: 10,000) - `ATM_PURCHASE_ENABLED` — toggle (default: false) ## Considerations - The purchase endpoint should be **unauthenticated** (the invoice payment is the auth) - Rate-limit the creation endpoint to prevent spam - Consider whether app IDs should expire or require renewal - Could integrate with the existing extension system (withdraw extension already handles LNURL) - The 10k sats price point is a starting suggestion — should be operator-configurable ## Context This came up while setting up the Douro ATM. The current provisioning script (`provision-atm.sh`) works but requires SSH + admin token access. A paid self-service flow would enable a marketplace model where LP operators can sell ATM connectivity.

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: aiolabs/lightning-pub#9

No description provided.

Rows
Columns