Migrating to Credit Backed Payments

drop your lnd node entirely send and receive payments through the voltage payments api backed by a line of credit prerequisites you've read migration guide docid 7szaymjg8lkjcmiwjkub (auth changes, concept mapping, status mapping, amount handling) your business is eligible for a voltage line of credit (us based, approved states) migration steps apply for a line of credit post collateral create payments environment and wallet set up webhooks migrate sending migrate receiving implement reconciliation loop parallel run cut over and decommission node step 1 apply for a line of credit follow the credit backed setup docid\ kd563u5vevsbcaymvcan guide to submit your application you'll need organization structure and tin beneficial owner information (25%+ ownership) officer/director details estimated monthly send and receive volumes after submitting, voltage reviews your application if approved, you'll receive an email with your approved credit amount, billing cycle, and collateral requirements step 2 post collateral if collateral is required navigate to your billing dashboard in the voltage ui send btc to the provided multi sig address (secured by distributed keys) once the required amount confirms, your account is enabled for mainnet payments step 3 create payments environment and wallet go to the payments product in the voltage dashboard create a new environment create a new wallet — do not check "i want to use a team infrastructure node" choose your wallet currency btc — payments denominated in bitcoin, no quotes needed usd — payments denominated in us dollars, requires the quotes api for every payment generate an api key for the environment after this step you'll have organization id , environment id , wallet id your x api key (if usd) your line of credit id for the quotes api usd wallets require a quote before every send and receive see sending (usd line of credit) docid 1qzxwddcqh5wuzv6qf 0a and receiving (usd line of credit) docid\ jymho26n377vgern3on i for the full workflow step 4 set up webhooks this step is identical to the node backed path register a webhook to receive real time payment events curl "https //voltageapi com/v1/organizations/{organization id}/environments/{environment id}/webhooks" \\ \ request post \\ \ header "content type application/json" \\ \ header "x api key your api key" \\ \ data '{ "id" "b0fc9829 f139 4035 bb14 4a4b6cd58f0e", "organization id" "{organization id}", "environment id" "{environment id}", "url" "https //your domain com/webhook", "name" "migration webhook", "events" \[ { "send" "succeeded" }, { "send" "failed" }, { "receive" "generated" }, { "receive" "completed" }, { "receive" "expired" }, { "receive" "failed" } ] }' save the shared secret from the response implement signature verification using the x voltage signature and x voltage timestamp headers see the webhooks docid\ pdeh 4et9aqawca5q91na guide for full details step 5 migrate sending the payments api send endpoint is the same regardless of whether your wallet is node backed or credit backed lightning payment (btc wallet) before (lnd rest) curl cacert tls cert \\ \ header "grpc metadata macaroon $(xxd ps u c 1000 admin macaroon)" \\ https //your node voltage cloud 8080/v2/router/send \\ \ request post \\ \ data '{ "payment request" "lntbs1500n1p ", "timeout seconds" 60, "fee limit msat" 1000, "no inflight updates" true }' after (payments api) curl 'https //voltageapi com/v1/organizations/{organization id}/environments/{environment id}/payments' \\ \ request post \\ \ header 'x api key your api key' \\ \ header 'content type application/json' \\ \ data '{ "id" "68d00852 8dd8 4c71 94d2 91c84695da78", "wallet id" "{wallet id}", "currency" "btc", "type" "bolt11", "data" { "payment request" "lntbs1500n1p ", "amount" { "currency" "btc", "amount" 150000, "unit" "msats" }, "max fee" { "currency" "btc", "amount" 1000, "unit" "msats" } } }' usd wallets you must first obtain a quote via post /quotes , then include the quote id and set currency "usd" in the payment request see sending (usd line of credit) docid 1qzxwddcqh5wuzv6qf 0a for the full two step flow on chain payment before (lnd rest) curl cacert tls cert \\ \ header "grpc metadata macaroon $(xxd ps u c 1000 admin macaroon)" \\ https //your node voltage cloud 8080/v1/transactions \\ \ request post \\ \ data '{ "addr" "tb1pzkhtj4ld86g9c49du5yagnncfrm0s489t76vmrwmt2ecxfnf7spsvjte49", "amount" 15000, "sat per vbyte" 10 }' after (payments api) curl 'https //voltageapi com/v1/organizations/{organization id}/environments/{environment id}/payments' \\ \ request post \\ \ header 'x api key your api key' \\ \ header 'content type application/json' \\ \ data '{ "id" "2ec1e783 19b4 4c10 8181 66336a6232bd", "wallet id" "{wallet id}", "currency" "btc", "type" "onchain", "data" { "address" "tb1pzkhtj4ld86g9c49du5yagnncfrm0s489t76vmrwmt2ecxfnf7spsvjte49", "amount" { "currency" "btc", "amount" 15000000, "unit" "msats" }, "max fee" { "currency" "btc", "amount" 1000000, "unit" "msats" }, "description" "test payment" } }' step 6 migrate receiving lightning invoice (btc wallet) before (lnd rest) curl cacert tls cert \\ \ header "grpc metadata macaroon $(xxd ps u c 1000 admin macaroon)" \\ https //your node voltage cloud 8080/v1/invoices \\ \ request post \\ \ data '{ "value msat" 150000, "memo" "test payment", "expiry" 3600 }' after (payments api) — step 1 create the receive payment curl 'https //voltageapi com/v1/organizations/{organization id}/environments/{environment id}/payments' \\ \ request post \\ \ header 'x api key your api key' \\ \ header 'content type application/json' \\ \ data '{ "id" "11ca843c bdaa 44b6 965a 39ac550fcef7", "wallet id" "{wallet id}", "currency" "btc", "payment kind" "bolt11", "amount" { "amount" 150000, "currency" "btc", "unit" "msats" }, "description" "test payment", "expiration" 3600 }' after — step 2 fetch the invoice curl 'https //voltageapi com/v1/organizations/{organization id}/environments/{environment id}/payments/11ca843c bdaa 44b6 965a 39ac550fcef7' \\ \ header 'x api key your api key' the data payment request field contains the bolt11 invoice string usd wallets obtain a quote first, then include quote id and set currency "usd" with the amount in cents see receiving (usd line of credit) docid\ jymho26n377vgern3on i for the full workflow on chain receive before (lnd rest) curl cacert tls cert \\ \ header "grpc metadata macaroon $(xxd ps u c 1000 admin macaroon)" \\ https //your node voltage cloud 8080/v1/newaddress?type=taproot pubkey after (payments api) curl 'https //voltageapi com/v1/organizations/{organization id}/environments/{environment id}/payments' \\ \ request post \\ \ header 'x api key your api key' \\ \ header 'content type application/json' \\ \ data '{ "id" "11ca843c bdaa 44b6 965a 39ac550fcef8", "wallet id" "{wallet id}", "currency" "btc", "payment kind" "onchain", "amount" { "amount" 150000000, "currency" "btc", "unit" "msats" }, "description" "on chain deposit" }' fetch the payment to get data address step 7 implement reconciliation loop same as the node backed path set up a cron job (every 1–5 minutes) that lists recently updated payments and upserts them into your database see the webhooks docid\ pdeh 4et9aqawca5q91na guide under "reconciliation loop" for the full implementation step 8 parallel run run both integrations side by side since you're migrating off the node entirely, focus your verification on the payments api path verification checklist send a lightning payment via the payments api → completed receive a lightning payment via the payments api → invoice generated, completed send an on chain payment via the payments api → completed receive an on chain payment via the payments api → address generated, completed webhooks fire for all events reconciliation loop catches all payments step 9 cut over and decommission node decommission only after the payments api path has passed the parallel run checks and the operating owner has approved the change 1\ stop all direct lnd api calls disable your old integration all payment traffic should now flow through the payments api 2\ confirm recovery readiness before changing channels or moving funds recovery material current approved workflow → current owner → last validation date → storage location recovery validation current approved workflow → current owner → validate current recovery artifact do not rely on an unverified dashboard path or an untested backup 3\ plan channel closure inventory open and pending channels, on chain funds, unsettled payments, and automated liquidity workflows use the current supported node tooling and an approved runbook prefer cooperative closure when operating conditions allow it runbook checkpoint \# verify the current supported closure command before execution use an approved node tool to review channels → record each approved closure treat force closure as an exception review the current timelock, recovery implications, and approval requirements before proceeding 4\ wait for closures to confirm on chain use the current supported node tooling to monitor pending resolutions do not rely on an unverified command syntax wait for the confirmation depth required by your policy before proceeding 5\ withdraw remaining on chain balance move remaining on chain funds only through the approved treasury workflow \# verify the approved destination and current fund movement command before execution record the destination, amount, operator, and transaction identifier 6\ verify zero balances confirm there are no pending payments, unresolved channels, or balances that still require custody action \# use the current approved reconciliation workflow retain final reconciliation evidence 7\ deprovision through the approved process confirm the current voltage product workflow with your account owner or voltage support before changing the infrastructure product state or deleting the node 8\ confirm billing impact confirm the current billing workflow before changing the infrastructure plan, and record the completion evidence what you no longer manage responsibility before (direct lnd) after (credit backed) node uptime you monitor and restart not applicable channels you open, close, rebalance not applicable liquidity you manage capacity + treasury not applicable routing lnd pathfinding or custom not applicable tls certificates load, rotate, distribute not applicable macaroons bake, secure, inject not applicable backups and recovery you maintain approved recovery procedures not applicable node access you operate credentials and availability not applicable billing with a line of credit, you're billed on a regular cycle based on your approved terms your billing dashboard shows current credit utilization billing cycle dates payment history confirm current utilization, billing cycle, and payment record details in the dashboard or with your account owner technical documentation does not define pricing or contract terms