Crypto Payment SDK Comparison: Developer Tools for Digital Payments

Crypto Payment SDKs at a Glance

Developers building crypto payment acceptance face a fragmented landscape of SDKs, APIs, and open-source toolkits. Each option makes different tradeoffs between integration speed, custody model, supported payment types, and cost. Choosing the wrong SDK early can mean months of rework when requirements shift.

This comparison covers the major payment gateway and SDK options available to developers in 2026: Circle's USDC APIs, Stripe's crypto onramp, BTCPay Server, OpenNode, LDK (Lightning Dev Kit), Breez SDK, and the Spark SDK. The table below provides a high-level snapshot before we examine each option in detail.

For a broader look at wallet development toolkits, see our crypto wallet SDK landscape and wallet SDK comparison.

Circle USDC APIs

Circle provides a suite of APIs focused on USDC payments. The core products include Circle Mint (for enterprise minting and redemption of USDC), programmable wallets (smart contract wallets with gas abstraction), and CCTP (Cross-Chain Transfer Protocol) for moving USDC between 16+ supported chains without wrapped tokens.

The developer experience is polished: Circle offers testnet USDC faucets, comprehensive API documentation, and official SDKs for Node.js, Python, and Go. A free tier covers basic API access and testnet usage, while production volume pricing requires contacting Circle's sales team. CCTP itself is free to use at the protocol level, with only standard gas fees for on-chain transactions.

Circle's APIs are best suited for developers building stablecoin-first payment flows: merchant checkout accepting USDC, cross-chain treasury operations, or programmable payouts. The tradeoff is scope: Circle's tooling is centered entirely on USDC. If you need to accept Bitcoin, Lightning, or other assets, you will need a second SDK. For more on Circle's API pricing relative to alternatives, see our crypto API pricing comparison.

Stripe Crypto Onramp

Stripe's crypto onramp lets developers embed a fiat-to-crypto purchase flow directly into their applications. Users buy BTC, ETH, SOL, USDC, or AVAX using credit cards, debit cards, or bank transfers, and receive tokens in their connected wallet. Stripe acts as the merchant of record and assumes liability for fraud and disputes.

Integration follows Stripe's standard pattern: create a session via POST /v1/crypto/onramp_sessions on the server, then render the client-side component using Stripe's hosted, embedded, or embedded-components options. Developers already using Stripe for traditional payments will find the API conventions familiar.

The onramp is in public preview, and access requires an approved application (most reviewed within 48 hours). Fees include a per-transaction charge plus a spread between the market price and the displayed price. In Stripe's own examples, a $100 USDC purchase carried a $4.99 fee. Note that this is a separate product from Stripe's stablecoin payment acceptance (which charges 1.5% per transaction for merchants accepting USDC at checkout). The onramp is specifically for converting fiat to crypto, not for merchant payment acceptance.

BTCPay Server API

BTCPay Server is an open-source, self-hosted payment processor that charges zero transaction fees at the software level. All payments settle directly to the merchant's own wallet, making it fully self-custodial. The only costs are server hosting (roughly $10 to $70 per month for a VPS) and Bitcoin network fees paid by the sender.

BTCPay exposes two APIs: the Greenfield API (a modern RESTful interface recommended for new projects) and a legacy BitPay-compatible API for migrating from BitPay. Official client libraries exist for C#, Python, and Node.js, with community-maintained PHP and Ruby forks. The platform supports both on-chain Bitcoin and Lightning payments, handles multi-store configurations, and provides built-in webhook notifications.

The tradeoff is operational overhead. Developers must provision and maintain the server, manage updates, handle backups, and ensure uptime. BTCPay does not offer fiat settlement, stablecoin acceptance, or managed compliance tooling. For a direct comparison with hosted alternatives, see our BTCPay vs OpenNode comparison.

OpenNode API

OpenNode is a hosted Bitcoin payment gateway that provides a REST API covering charges, withdrawals, refunds, exchange rates, and static addresses. It supports both on-chain Bitcoin and Lightning payments with LNURL support. The API uses a simple charge-creation pattern: pass an amount and currency, and OpenNode returns a payment request that the payer fulfills.

OpenNode charges a 1% transaction fee on payments processed through its platform. This is competitive for low-volume merchants who cannot justify self-hosting BTCPay Server. The platform handles Lightning node management, channel liquidity, and optional automatic fiat conversion. Webhook notifications are included for payment status updates.

The downside is custodial risk: funds are held by OpenNode until withdrawn. OpenNode does not support stablecoin acceptance natively, and its SDK ecosystem is narrower than Circle's or Stripe's. Developers building exclusively on Bitcoin and Lightning will find it sufficient, but multi-asset payment flows require additional integrations.

Lightning-Native SDKs: LDK and Breez

For developers building Lightning Network applications rather than wrapping a third-party API, two open-source SDKs dominate: LDK (Lightning Dev Kit) and Breez SDK. Both are free to use and self-custodial, but they target different levels of abstraction.

LDK (Lightning Dev Kit)

LDK, maintained by Spiral (a Block subsidiary), is designed to be embedded into existing applications. Unlike monolithic Lightning node implementations such as LND or Core Lightning, LDK does not bundle its own networking stack, storage layer, or chain data backend. Developers supply these components, gaining full control over the architecture. The higher-level ldk-node package bundles sensible defaults (BDK for on-chain, SQLite for persistence) and provides Swift and Kotlin bindings for mobile development.

LDK supports BOLT11 invoices, BOLT12 offers, anchor outputs, keysend, and multi-path payments. Production deployments include Cash App and Bitkit. In 2026, Spiral unveiled LDK Server at Bitcoin 2026 in Las Vegas: a deployable daemon built on LDK that requires minimal configuration. For a detailed comparison of Bitcoin development toolkits, see our Bitcoin dev kit comparison.

Breez SDK

Breez SDK abstracts Lightning complexity behind a high-level API that handles channel management, liquidity, and routing through an LSP (Lightning Service Provider). It ships in three implementations: Greenlight (native Lightning via Blockstream), Liquid (nodeless, using submarine swaps with the Liquid sidechain), and a newer Spark-based implementation for Bitcoin-native payments.

The SDK supports BOLT11, BOLT12, BIP-353 addresses, LNURL-Pay, LNURL-Withdraw, and Lightning addresses. Client bindings cover Rust, Swift, Kotlin, React Native, and Flutter. Breez SDK charges no SDK-level fees, though LSP services incur channel-opening fees that vary by provider. As of mid-2026, the SDK also supports outgoing stablecoin payments, converting users' Bitcoin balances to USDC or USDT across 30+ blockchain networks.

Spark SDK

The Spark SDK enables developers to build self-custodial Bitcoin and stablecoin wallets using a single integration. The SDK wraps Spark's Layer 2 infrastructure, handling statechain transfers, FROST threshold signing, and key management behind a SparkWallet class that covers wallet lifecycle, balance queries, Spark transfers, Lightning sends, L1 deposits and withdrawals, and token operations.

Key design decisions set Spark apart for payment developers. User keys derive from a client-side mnemonic, and operators never access private key material. Pre-signed exit transactions allow users to withdraw to Bitcoin L1 even if Spark operators go offline. The SDK supports USDB and USDT natively on Spark without bridges or wrapped tokens, making it possible to build apps that handle both Bitcoin and dollar-denominated payments in a single flow.

Bindings are available for JavaScript, Swift, Kotlin, and React Native. Tether has integrated Spark into its open-source Wallet Development Kit (WDK), and Breez has announced a Spark-based implementation of the Breez SDK for Lightning-compatible payments. For a deeper technical walkthrough, see our research on building on the Spark SDK.

Developer Experience Compared

Integration complexity varies dramatically across these SDKs. The table below compares key developer experience metrics for building a basic payment acceptance flow.

Which SDK for Which App Type

The right SDK depends on what you are building. Here is a practical framework organized by application type.

E-commerce checkout

For traditional e-commerce, BTCPay Server and OpenNode are the most direct options. BTCPay integrates with WooCommerce, Shopify (via plugins), and other platforms out of the box. OpenNode offers a similar plugin ecosystem with less operational burden but a 1% fee. If your checkout needs stablecoin acceptance, Circle's APIs handle USDC natively across multiple chains. The Spark SDK is a strong fit for merchants who want to accept both BTC and stablecoins without custodial intermediaries.

Mobile wallets

Breez SDK and the Spark SDK are purpose-built for mobile wallet development. Breez handles Lightning channel management through its LSP model and ships with Swift, Kotlin, and React Native bindings. The Spark SDK provides the same mobile bindings with native stablecoin support (USDB and USDT) and self-custodial key management. LDK via ldk-node is viable for teams that need deeper control over the Lightning implementation but requires more development time. See our embedded wallets guide for architectural considerations.

SaaS billing and subscriptions

Recurring crypto billing remains underdeveloped compared to traditional subscription payments. Stripe's crypto onramp can handle one-time purchases but does not support recurring charges in crypto. BTCPay Server supports basic recurring invoices. For stablecoin-based SaaS billing, Circle's programmable wallets can automate periodic USDC transfers. Lightning-based recurring payments are possible via BOLT12 offers, supported by LDK and Breez SDK.

Marketplace payouts

Platforms that need to split payments and disburse funds to multiple sellers have limited options. Circle's APIs support batch payouts in USDC across multiple chains. OpenNode handles Bitcoin payouts via its withdrawals API. The Spark SDK can facilitate instant, near-zero-fee payouts in both BTC and stablecoins to sellers running Spark-compatible wallets, with each party maintaining self-custody.

Integration Complexity and Tradeoffs

Hosted APIs (Circle, Stripe, OpenNode) minimize time to first transaction but introduce custody dependencies, ongoing fees, and platform risk. Coinbase Commerce, which shut down on March 31, 2026, is a cautionary example: merchants who built on it lost their payment infrastructure and were given limited migration options (Coinbase Business, available only in the US and Singapore).

Self-hosted and self-custodial options (BTCPay, LDK, Spark SDK) avoid platform dependency but require more upfront engineering. The spectrum runs from LDK (maximum flexibility, weeks of integration work) to the Spark SDK (high-level abstraction, hours to first transaction) to BTCPay (battle-tested but server ops required).

Breez SDK occupies a middle ground: self-custodial by design, but with the LSP handling liquidity and channel management. This reduces complexity for Lightning payments at the cost of depending on the LSP for channel opens and routing.

Stablecoin Payment SDK Options

Stablecoin acceptance is increasingly important for developers building payment applications. The options break down by chain ecosystem and custody model:

• Circle APIs: the most mature stablecoin SDK, supporting USDC on Ethereum, Solana, Arbitrum, Base, Polygon, Avalanche, and more via CCTP
• Stripe: supports USDC purchases through the onramp and 1.5% merchant acceptance via its checkout suite, but limited to Stripe-supported chains
• Spark SDK: native support for USDB and USDT on Bitcoin's Spark layer, enabling self-custodial stablecoin payments without EVM chains
• Breez SDK: outgoing stablecoin payments to 30+ chains (converting from BTC), with incoming stablecoin support planned

For a detailed comparison of stablecoin API providers and their pricing models, see our stablecoin payout API comparison.

Frequently Asked Questions

What is the easiest crypto payment SDK to integrate?

For developers already using Stripe, the Stripe crypto onramp is the fastest path: the API conventions mirror standard Stripe integrations, and most developers reach a working sandbox in under an hour. For Bitcoin-specific payments, OpenNode offers a simple REST API with minimal configuration. The Spark SDK provides a similarly fast integration path for self-custodial Bitcoin and stablecoin payments.

Which crypto payment SDK has the lowest fees?

BTCPay Server and LDK charge zero platform fees since they are open-source and self-hosted. The only costs are server hosting (BTCPay) or Lightning routing fees (LDK). The Spark SDK and Breez SDK also charge no SDK-level fees, though Lightning Service Providers and network fees still apply. Among hosted options, OpenNode's 1% is the lowest flat rate. Stripe's onramp fees run approximately 5% per purchase, and Circle's enterprise pricing is volume-dependent.

Can I accept both Bitcoin and stablecoins with one SDK?

The Spark SDK is the most direct option for accepting both BTC and stablecoins (USDB, USDT) through a single integration, with self-custodial key management for both asset types. Breez SDK supports Bitcoin natively and can convert outgoing payments to stablecoins. Most other SDKs specialize in one asset class: Circle handles USDC only, while BTCPay and OpenNode handle Bitcoin only.

Is Coinbase Commerce still available for developers?

No. Coinbase Commerce shut down on March 31, 2026. The self-custodial merchant payment platform was discontinued, and dashboard access was permanently closed. Coinbase is directing merchants to Coinbase Business, which is currently available only in the United States and Singapore. Merchants outside those regions need to migrate to alternative providers such as BTCPay Server, OpenNode, or Circle.

What is the best SDK for self-custodial crypto payments?

BTCPay Server, LDK, and the Spark SDK are all fully self-custodial. BTCPay requires running your own server but is battle-tested for merchant use cases. LDK gives maximum control over Lightning implementation but demands significant development effort. The Spark SDK offers self-custodial Bitcoin and stablecoin payments with a higher-level API, making it the fastest path to self-custodial payment acceptance without server infrastructure.

Do crypto payment SDKs support webhooks?

Yes. All major crypto payment SDKs and APIs provide notification mechanisms for payment status changes. Circle, Stripe, BTCPay Server, and OpenNode use standard webhook patterns with HTTP POST callbacks and signature verification. LDK, Breez SDK, and the Spark SDK use event-based callback systems within the application runtime, which is more appropriate for mobile and embedded wallet architectures where there is no server to receive HTTP callbacks.

Which SDK should I use for Lightning Network payments?

For a hosted solution with minimal setup, OpenNode provides Lightning acceptance through its REST API. For self-custodial Lightning, Breez SDK offers the fastest path with LSP-managed channels. LDK provides the most control but requires building your own node logic. BTCPay Server includes Lightning support alongside on-chain payments. The Spark SDK supports outgoing Lightning sends and provides an alternative Layer 2 approach that avoids Lightning's channel capacity constraints.

This tool is for informational purposes only and does not constitute financial or technical advice. SDK features, pricing, and availability change frequently. Always verify current documentation, fees, and terms directly with each provider before making integration decisions.