Operator Payment Rails

Operator-only adapters

End users should not configure Lightning nodes, Stripe secrets, or x402 wallets just to use Froglet.

Start with a free local service. The optional hosted trial is currently unavailable and its contract is free-only. These payment adapters are advanced operator integrations; they are not a complete sales and billing product. Check their implementation status before choosing one.

Customer vs operator setup

Customer path:

• Optional hosted trial: currently unavailable; no payment setup is part of its contract.
• Future hosted paid path: card checkout or a hosted invoice surface; the buyer does not run LND or manage channel liquidity.
• Self-hosted free path: payment_rail=none.

Operator path:

The recommended no-clone default is payment_rail=none. When an operator explicitly selects a paid rail, the generated bootstrap command carries that selection after the pipe, verifies the rail, and persists its private env file before activating either launchd/systemd or the Docker fallback. A decision checkpoint is still required before any real secrets are entered, and the free demo remains the safest first proof.

Use these rail names in MCP:

• none
• lightning-lnd-rest
• stripe-test
• stripe-live
• x402

stripe-live requires a fresh human approval and a tiny live payment/refund proof before public copy can claim live fiat. lightning-lnd-rest is advanced operator infrastructure: it requires the operator’s LND REST URL, macaroon, TLS cert, backups, and channel liquidity. Do not present it as normal customer onboarding.

Source helper

If you are in a source checkout or operator runbook, the repo-local helper can write env snippets and run probes:

cd froglet && ./scripts/setup-payment.sh lightning
cd froglet && ./scripts/setup-payment.sh stripe
cd froglet && ./scripts/setup-payment.sh x402

Each command:

• writes a validated env snippet
• prints the exact secrets or inputs still required
• runs a verification probe for that rail

Choosing a rail

Rail	Best first use	Verification path
Lightning	operator-controlled Bitcoin settlement, not ordinary buyer onboarding	mock mode locally, optional lnd_rest probe
Stripe	operator card-flow development and paid-staging proof	GET /v1/account with a test secret key and livemode=false
x402	operator-controlled USDC-style machine-to-machine endpoints	local Base-address/network validation plus facilitator /verify reachability

The current public Stripe and x402 adapters reuse the configured numeric service price directly on the local runtime path. They do not perform FX conversion from sats into backend-native fiat or token units.

Operator guides

• Lightning
• Stripe
• x402

Verification lifecycle

Across all three local/self-hosted adapters, the local /v1/node/* runtime helpers use the same stages:

1. descriptor exposure
2. payment prepare or reserve
3. commit or capture
4. cancellation or release

The signed Quote → Deal → Receipt flow admits configured Lightning and stripe_mpp.v1 settlement methods. Lightning’s base-fee-plus-success-fee escrow method uses an InvoiceBundle. Prepaid Lightning and Stripe do not; Stripe binds a manual-capture PaymentIntent to the signed terms and terminal Receipt. The Kernel also defines x402 artifact semantics, but the current provider Deal runtime does not admit x402. Its payment path remains a separate HTTP endpoint. The rail-specific guides explain the required authorization and lifecycle.

Native MCP run_compute defaults to free-only. Paid computation requires an explicit price ceiling, the configured wallet and cumulative spending policy. It has no caller-supplied Stripe SPT argument; advanced Stripe callers supply externally issued tokens through the requester runtime API. Froglet’s built-in SPT minting helper is sandbox-only.

A passing synchronous helper call or mock paid lifecycle test does not qualify production paid jobs. Qualify execution, acceptance, settlement and restart on the selected deployment, and record a fresh live payment/refund proof before claiming live fiat support.