Practical overview
When it fits
Use Paypercall when an HTTP service needs per-call payment requirements and you can connect it to a Lightning Charge server. Select middleware for direct integration into an Express app, or the reverse proxy for an upstream service that should remain payment-unaware.
Who it is for
- Developers who want to charge for individual HTTP API actions.
- Teams that want to add payment gating to an Express application or place it in front of an existing HTTP service.
Documented uses
- Require payment before processing a request to a selected API route.
- Set endpoint rates at a reverse proxy while keeping the upstream application payment-unaware.
- Let API callers obtain a BOLT11 invoice, pay it and retry with a returned access token.
Requirements & limits
The GitHub repository is public and identifies the project as MIT-licensed. The middleware requires a Lightning Charge access token.
- Middleware is documented for Express and Node.js applications; the proxy can front an upstream Flask service.
- Both integration paths depend on Lightning Charge, with a required access token.
- The documented caller flow requires an initial empty request, payment of the returned BOLT11 invoice, then a retry carrying the request body and X-Token.
- Middleware configuration documents SQLite storage and configurable invoice and access-token expiries.
Check current requirements in the official documentation. Source-based guidance does not mean OpenViST has run or independently tested this project.
Configure a payment-gated API through the reverse proxy
Place a payment-requiring proxy in front of an existing HTTP service and set a rate for an endpoint.
Before you start
- A running upstream HTTP application
- A Lightning Charge server URL and access token
- An endpoint and rate to configure
Steps
Run the upstream HTTP application.
Start paypercall with the Lightning Charge token, upstream URL, proxy port and a YAML endpoint rate mapping.
Send requests to the proxy endpoint, which requires payment before forwarding access to the upstream service.
Expected outcome
The upstream application remains unaware of payments while paypercall applies per-call charges at the proxy.
Guide limitations
- The example documents a Flask upstream and a POST route; it does not specify every supported server or endpoint configuration.
- The guide describes setup, not a verified deployment.
Pay for and call a protected API endpoint
Follow the documented caller sequence for an endpoint protected by paypercall.
Before you start
- A paypercall-enabled API endpoint
- A Lightning wallet capable of paying the returned BOLT11 invoice
Steps
Send an empty request to the endpoint to receive its BOLT11 payment request and X-Token header.
Pay the invoice.
Repeat the request with the required body and echo the returned X-Token header.
Expected outcome
The paid request can proceed to the API action, as illustrated by the README's SMS endpoint example.
Guide limitations
- The example's invoice and token are illustrative; callers need values returned by their own endpoint.
- The documented example uses a Lightning payment flow.
Sources & review
Source record details
- Source availability
- Active
- Sources checked
- 16 October 2026
- Original website title
- ElementsProject/paypercall · Official homepage title · retained in its source language

