Best Bitcoin API for Payment Processors and Merchant Gateways

Search for the best Bitcoin API for payment processing and you get a list of payment gateways: BitPay, CoinGate, NOWPayments, OpenNode, BTCPay Server. Those are real products and several of them are good. They also answer a different question from the one you asked. They tell you who will accept bitcoin on your behalf. If you are the one building the acceptance layer, whether that is a marketplace crediting seller balances, a broker funding accounts, or an exchange taking deposits, you need the layer underneath, and the roundups do not cover it.

This is about that layer. Everything below was measured against live endpoints on 16 September 2026 and is reproducible.

What layer are you actually buying?

Four different things get called a Bitcoin payment API, and picking the wrong category costs more than picking the wrong brand within a category.

Most production payment systems end up paying for two of these: something that broadcasts, and something that answers questions about the chain. The gateway comparison articles cover the first row thoroughly and the fourth row not at all.

The broadcast half is smaller than it looks, and easy to get wrong. Every public broadcast endpoint we tested on 25 September 2026 answered HTTP 400 both for a payment that had already confirmed and for bytes that were not a transaction, so retry code that reads only the status can pay a customer twice. Our Bitcoin broadcast transaction API page shows the responses side by side and the rule that prevents it.

What is the most important feature in a Bitcoin API for payments?

Whether it can tell you that a payment has been replaced. Everything else on a feature list, webhooks, address generation, fee estimation, exchange rates, is available from several vendors at similar quality. Replacement detection is where they genuinely differ, and it is the feature that maps directly to money you can lose.

Here is the situation it covers. A customer pays. Your system sees the transaction in the mempool and shows the order as received. Before it confirms, the same customer broadcasts a competing transaction that spends the same coins back to themselves with a slightly higher fee. Nodes relay the replacement, the original never confirms, and you have shipped against a payment that no longer exists.

Does the RBF flag protect a merchant?

No, and the numbers are not close. The common advice is to refuse transactions that signal replace-by-fee. We tested what that policy would actually do. On 16 September 2026 we pulled 260 transactions from the live mempool and parsed each one individually, checking the sequence value on every input. 232 of them signalled opt-in RBF. That is 89.23 percent.

We checked it a second way to make sure it was not an artifact of our parsing. BlockCypher publishes its own opt_in_rbf boolean, computed independently. On a separate sample it reported true on 15 of the 17 transactions it could see, 88.24 percent. Two providers, two samples, two methods, the same answer.

A property that nine in ten transactions share cannot rank risk. Refusing RBF-signalling payments would reject most of your legitimate volume, because signalling is simply what modern wallets do by default now.

It also does not close the hole. Full-RBF relay means a transaction that never opted in can be replaced anyway. Reading the live replacement feed on mempool.space the same day, between 1 and 5 of the 25 replacement trees visible carried the fullRbf marker depending on the minute we looked, which means the evicted transaction had not signalled.

How much does it cost an attacker to replace a transaction?

Almost nothing, which is the part that should shape your policy. Across those 25 replacement trees, the median fee-rate increase from the original transaction to its replacement was 2.28 percent on one read and 5.5 percent on a read minutes earlier, with the full range running from 1.89 to 7.56 percent. The protocol requires a replacement to pay more. In practice it pays barely more.

So there is no risk score that makes an unconfirmed credit safe. Treat a 0-conf credit as an unsecured advance with a loss budget attached, and size the budget deliberately. The detection layer shortens the window in which you are wrong; it does not remove the exposure.

Which Bitcoin APIs actually expose a replacement signal?

We asked four sources the same question on 16 September 2026 and read the response bodies rather than just the status codes.

The Esplora REST format, served by both Blockstream and mempool.space and by far the most widely used free Bitcoin API, carries no replacement information at all. The transaction payload has exactly these top-level keys: fee, locktime, size, status, txid, version, vin, vout and weight. No double_spend, no rbf, no replaced_by. If you build on Esplora you are deriving the signal yourself from input sequence values, and as shown above that signal is not worth much.

mempool.space does have a per-transaction replacement endpoint at /api/v1/tx/{txid}/rbf. It answered in 62 milliseconds and returned replacements and replaces both set to null. That is the trap. Null is what you get for a transaction that was never replaced, and it is also what you would get for one the service simply has not cached. The companion cached endpoint returned HTTP 204 No Content for the same transaction. If your payment logic reads null as safe, it is treating "we do not know" as "nothing happened".

BlockCypher is the one that does this properly at the schema level. Its transaction objects carry double_spend and opt_in_rbf as first-class fields, available without an API key, answering in about 180 milliseconds. Credit where it is due: that is the right shape. The limitation is coverage. We took 30 txids that mempool.space was serving from its mempool at that moment and asked BlockCypher about each one. It knew 17 and returned 404 for the other 13. A double_spend field is only meaningful for transactions the provider has seen, and no provider sees the whole mempool.

That last point is worth stating plainly, because it is not a criticism of any vendor. There is no single mempool. Every node keeps its own set, shaped by uptime, memory limits, minimum relay fee and which peers reached it first. Even on one host the number moves: the mempool summary endpoint reported 70,803 transactions while the txid list returned 72,906 and, minutes later, 76,053. All of those readings were correct at the instant they were taken.

How should a payment processor detect a double spend?

Stop reading flags and start comparing outpoints. Take every input of the transaction you are waiting on and record its prev_txid and prev_vout pair. Then watch the unconfirmed set for any other transaction claiming the same pair. If one appears, the two conflict and only one of them can ever confirm.

That single rule catches opt-in replacements, full-RBF replacements and outright malicious double spends, because at the outpoint level all three are the same event. It does not depend on a vendor exposing a boolean, it does not silently return null, and it works the same way on every transaction regardless of how the sender configured their wallet.

It does require a data layer shaped for it. The query is a join from an outpoint to every transaction spending it, across confirmed and unconfirmed data at once. That is exactly how our Bitcoin double spend detection API is keyed, and the unconfirmed side is covered on the Bitcoin mempool API page. If you want the event pushed to you rather than polled, the Bitcoin webhook API page covers the notification side, and watching for transaction notifications without a node walks through the pattern.

How many confirmations should a payment processor require?

One confirmation removes replacement risk entirely, because a mined transaction can only be undone by a chain reorganisation, which is a different and far rarer problem. Everything below one confirmation is a commercial decision about exposure, not a technical one.

Set the threshold by what you are handing over. Digital goods you can revoke, small amounts, and repeat customers tolerate 0-conf with a detection layer behind it. Irreversible delivery, cash-out, and large amounts should wait for a block, and high-value settlement usually waits for several. Write the thresholds into code rather than leaving them to an operator, and log the block height at which each payment crossed its threshold so the decision is auditable later. Our guide to how many Bitcoin confirmations are safe works through the trade-off by amount.

What should you ask a Bitcoin data vendor before you sign?

Five questions, in this order. Can I query the unconfirmed set and the confirmed chain in the same request path, or are they two different products? Can I look up every transaction spending a given outpoint, including unconfirmed ones? When you do not know something, do you return an error rather than null or zero? What is your mempool coverage, and are you honest that it is partial? And can I reproduce any figure you show me from the rows you hand me?

The third question catches more real incidents than the other four combined. Silent nulls and silent zeros are the failure mode that survives testing and shows up in production, because nothing throws. We have hit the same pattern elsewhere in this category: a historical balance parameter that gets ignored and returns the current balance instead, and a before parameter that returns every numeric field as zero rather than an error. The vendor comparison on our BlockCypher alternative page goes through the rate-limit and coverage side in more detail.

Where the money actually lands

One practical note on the back half of a payment flow, because the chain side is not where most processors lose time. Once bitcoin payments settle, the fiat leg arrives from a banking or liquidity partner as a statement rather than a feed, and someone has to get those payouts into the books before month end. Turning those PDF settlement statements into QuickBooks-ready entries is usually the difference between a close that takes an afternoon and one that takes a week, and it is worth solving at the same time as the on-chain side rather than after.

On the chain side, BitcoinDatabase covers confirmed blocks along with the live unconfirmed set, and exposes addresses, transactions, inputs, outputs and UTXOs at satoshi precision over REST, with address history back to 2009, and over SQL on the indexed chain, which grows with every new block. Start with the Bitcoin transaction API, or query the chain directly from the API documentation.

Measurements in this article were taken on 16 September 2026 against live public endpoints, with response bodies read rather than status codes assumed. Sample sizes are stated inline. Provider behavior, coverage and pricing change; re-run the checks before relying on them. This is informational on-chain data and engineering guidance, not financial, legal or investment advice.