Try it live at orchestra.flashnet.xyz/onramp.
How It Works
- Your app calls
POST /v1/orchestration/onrampwith the destination chain, asset, recipient address, and amount. The amount can be BTC sats to send (exact_in, the default) or the destination asset amount to receive (exact_out). - Orchestra creates a Lightning invoice, builds the order, and returns payment deeplinks.
- The user opens the deeplink (or scans a QR code) and pays via their preferred Lightning-compatible app.
- Orchestra receives the Lightning payment, swaps BTC to the destination asset, and delivers it.
Why USDB Or Direct BTC
Every onramp route starts fromlightning:BTC. When you choose USDB, Orchestra swaps BTC to USDB and finishes on Spark. When you choose BTC on Spark or Bitcoin L1, Orchestra stays in BTC and delivers the remaining sats after fees. When you choose USDC on another chain, Orchestra must also bridge and deliver, adding cost and latency.
| USDB on Spark | BTC on Spark / Bitcoin L1 | USDC on Solana/Base | |
|---|---|---|---|
| Platform fee | Custom pricing | Custom pricing | Custom pricing |
| Fee asset | USDB | BTC | USDC |
| Pipeline shape | Verify, swap | Verify, settle BTC fee, deliver | Verify, swap, bridge, deliver |
| Delivery time | Seconds | Seconds | Seconds |
| Sweep fee | None | None | May apply (details) |
| Rewards | 3.5-6% rewards in BTC | None | None |
Fees
Many Lightning-compatible apps charge zero fees on Lightning payments. Orchestra uses custom pricing based on route and volume, significantly lower than traditional onramps (which typically charge 1.5-3.5% for card-based or 0.5-1.5% for bank transfers). No intermediary fees and no card processing fees. The/estimate endpoint returns the exact fee for each route.
For
lightning:BTC -> bitcoin:BTC, the platform fee is taken in BTC and the final on-chain withdrawal also pays the network withdrawal fee quoted by Spark at delivery time. That Bitcoin withdrawal fee is not Flashnet revenue.Lightning Payment Limits
Some Lightning-compatible apps impose their own limits on Lightning payments (for example, up to $999 per rolling 7-day window). Check your payment app’s documentation for specific limits.Supported Routes
The source is alwayslightning:BTC.
Native (fastest settlement):
lightning:BTC -> spark:USDBlightning:BTC -> spark:BTClightning:BTC -> bitcoin:BTC
lightning:BTC -> solana:USDClightning:BTC -> base:USDClightning:BTC -> base:USDTlightning:BTC -> base:ETHlightning:BTC -> solana:SOLlightning:BTC -> ethereum:USDClightning:BTC -> arbitrum:USDClightning:BTC -> tempo:USDClightning:BTC -> tempo:PathUSDlightning:BTC -> tron:USDTlightning:BTC -> plasma:USDT- Many more routes…
Integration
Get a price estimate
Use the estimate endpoint to show the user what they’ll receive before committing.Response:
Create the onramp order
A single call creates the Lightning invoice, builds the order, and returns payment deeplinks.Response:
Complete the payment
On mobile, redirect the user to the payment deeplink. On desktop, display the deeplink as a QR code for the user to scan with their phone. Use The Lightning invoice expires at
shortUrl when sharing payment links in messages or emails.expiresAt (2 minutes from creation). If the user doesn’t pay in time, create a new onramp order.Exact Output Mode
By default, you specify how many sats the user sends (exact_in) and Orchestra estimates the output. With amountMode: "exact_out", you specify the destination amount the recipient should receive, and Orchestra calculates the required Lightning payment.
This is useful when your UX needs to guarantee a specific dollar amount, for example “onramp exactly $50 USDC.”
amountIn (sats required) and a Lightning invoice for that amount. The user pays the invoice, and the recipient receives the specified output amount minus any rounding.
API Reference
POST /v1/orchestration/onramp
Requires authentication (Authorization: Bearer <api_key>) and idempotency (X-Idempotency-Key).
Request body:
| Field | Required | Type | Notes |
|---|---|---|---|
destinationChain | Yes | string | Target chain (e.g., spark, solana, base) |
destinationAsset | Yes | string | Target asset (e.g., USDB, BTC, USDC, PathUSD, ETH) |
recipientAddress | Yes | string | Destination address on the target chain |
amount | Yes | string | Amount as an integer string. With exact_in (default): BTC amount in sats. With exact_out: destination asset amount in smallest units (e.g., 6 decimals for USDC/USDB). |
amountMode | No | string | "exact_in" (default) or "exact_out". When exact_out, the amount field specifies how much the recipient receives, and Orchestra calculates the required Lightning payment. Not supported on direct BTC passthrough routes. |
slippageBps | No | number | Slippage tolerance in basis points (default: 50) |
appFees | No | array | Inline affiliate fees (mutually exclusive with affiliateId/affiliateIds) |
affiliateId | No | string | Registered affiliate ID (mutually exclusive with appFees) |
affiliateIds | No | string[] | Multiple registered affiliate IDs (mutually exclusive with appFees) |
| Field | Type | Notes |
|---|---|---|
orderId | string | Operation ID for tracking |
quoteId | string | Underlying quote ID |
depositAddress | string | BOLT11 Lightning invoice |
paymentLinks.cashApp | string | Payment app deeplink URL |
paymentLinks.shortUrl | string | Short redirect URL (302s to payment deeplink) |
amountIn | string | BTC amount in sats |
estimatedOut | string | Estimated output in destination asset smallest units |
feeAmount | string | Platform fee |
feeBps | number | Fee rate in basis points for this route |
totalFeeAmount | string | Total fees (platform + app fees) |
feeAsset | string | Fee denomination (USDB, BTC, or the destination-side stable asset depending on route) |
route | string[] | Asset path, not pipeline step names |
expiresAt | string | ISO timestamp when the Lightning invoice expires |
Affiliate Fees
The onramp endpoint supports the same affiliate fee model as the standard quote flow. Pass eitherappFees (inline), affiliateId (single registered affiliate), or affiliateIds (multiple registered affiliates) to collect fees on each onramp transaction. Affiliate fees require amountMode: "exact_in" (the default).
lightning:BTC -> spark:BTC or lightning:BTC -> bitcoin:BTC. See Affiliate Fees for registration and claim details.
Webhook Payloads
Register a webhook endpoint viaPOST /v1/webhooks to receive order status updates. See Webhooks for endpoint setup, signature verification, and delivery semantics.
Event Sequence
The events fired depend on the destination route:| Route | Events |
|---|---|
lightning:BTC -> spark:USDB | order.processing -> order.confirming -> order.swapping -> order.delivering -> order.completed |
lightning:BTC -> spark:BTC or lightning:BTC -> bitcoin:BTC | order.processing -> order.confirming -> order.delivering -> order.completed |
lightning:BTC -> solana:USDC (and other bridged destinations) | order.processing -> order.confirming -> order.swapping -> order.bridging -> order.delivering -> order.completed |
order.failed is emitted instead. If a refund is initiated, order.refunding and then order.refunded are emitted.
Payload Structure
Every webhook is an HTTPPOST with Content-Type: application/json. The payload is an envelope containing the event name, a timestamp, and a snapshot of the order at the moment the event was emitted:
Example: lightning:BTC -> spark:USDB (completed)
The native USDB route skips bridging and delivery steps. The order completes at the swap step.
Example: lightning:BTC -> solana:USDC (completed)
Bridged routes add bridging and delivery steps. The destination.txHash contains the Solana transaction signature.
Example: order.failed
When an order fails, the error object contains a code and message. All other fields reflect the state at the time of failure.
Optional Fields
These fields appear indata only when applicable:
| Field | When present |
|---|---|
priceLock | Always present for onramp orders (lightning source uses mode: "approval_required") |
swap | After the swap step completes |
paymentIntent | When amountMode: "exact_out" was used |
feePlan | When appFees, affiliateId, or affiliateIds was passed at order creation |
feePayouts | Once fee settlement transactions are recorded |
zeroconfOffer does not appear on onramp orders. It applies only to Bitcoin L1 deposits.
Unit Testing Webhooks
To verify your webhook handler, use the signature verification logic from Webhooks. Here’s a self-contained test using the payloads above:@flashnet/sdk’s verifyWebhookSignature helper instead of rolling your own HMAC.
Next Steps
- USDB Rewards for yield details
- API Overview for authentication and error handling
- Order Lifecycle for status transitions and webhook payloads
- Webhooks for real-time order updates