Bitcoin, Merchant Risk, and the Need for Speed

by George Peabody on July 17, 2013

in Bitcoin, George Peabody, Merchants

George Peabody - Glenbrook Partners

Bitcoin’s volatility continues to swing with the mood of investors, speculators, and the economic travails of countries like Argentina where Bitcoin usage is up sharply as concerns over the peso rise. The btc currency has swung between $70 and $100 since its astonishing mid-April high of $230.

In other words, if you’re a bitcoin holder, you’re on a ride you can’t control. As the wiser Bitcoin proponents put it, Bitcoin is still an experiment. For a lengthy description of Bitcoin’s many risks (as well as the risks of their proposed investment vehicle) the Winklevoss Trust SEC filing is a great start.

Bitcoin’s twin roles as “medium of exchange” and “store of value” will remain in flux and, among a few aficionados, continues to stimulate a fervor normally reserved for politics or religion. I’ll leave politics and religion for others to contemplate.

It is in another of Bitcoin’s roles, as a set of rails for moving value, that Bitcoin’s design and execution demonstrates it is past the experimental stage.  Sending a bitcoin from one peer to another on the Bitcoin network is a reliable activity. As we’ve written before, it’s been amateur hour if we want to move funds between bitcoin and fiat currency.  But within the Bitcoin Network, transaction reliability is high.

But that’s only part of what a competent electronic payment network must do. It must be secure. That appears to be the case for what happens within the Bitcoin P2P network and in the block chain ledger. Yes, security concerns abound at the exchanges, in the vaults for bitcoin storage, and in digital wallets, but the network itself has a good track record.

Another performance characteristic of an electronic payments network is transaction speed. And that is where the Bitcoin network and block chain ledger fall down when compared to the sub-second performance of the payment card networks’ authorization process.  While there is a real difference between an authorization and value transferred between accounts, merchants care first about payment certainty and then cost.

Bitcoin transaction certainty is, it turns out, a function of speed.

As a consumer or a merchant accepting a bitcoin transaction, you have a few choices to make regarding transaction confirmation, essentially the time it takes for a quorum of nodes on the network to write the transaction to the block each is currently processing. It all depends on your needs and risk tolerance.

Fast, Medium, Slow, and Cheapskate

Merchant processor BitPay offers its merchants three speed settings to choose from:

1. Slow.  This speed setting waits for six nodes on the network, an indisputable quorum, before BitPay reports to the merchant that the transaction has been confirmed. This currently takes 10 minutes on average. The transaction requires a payment of 0.0005 btc to the first node processing the transaction, at today’s exchange rate a cost of less than a nickel. The other nodes don’t require compensation because the first node does much of the computationally intensive work, making it easier for the others to solve for and record the transaction in their respective blocks.

2. Medium. The Medium speed setting waits for a single node, the one that does the hard work, to confirm the transaction by writing it to the block it is currently processing. Again, the 0.0005 btc fee applies.

3. Fast. At the Fast setting, BitPay will inform the merchant that a customer has made an unconfirmed payment. The risk is entirely on the merchant as to whether or not to deliver the product in advance of transaction confirmation.

Risk, therefore, is inversely proportional to product or service delivery speed. The shorter the delivery speed, the higher the payment risk.

A fourth best effort option exists that requires no fee but it relies on the generosity of a miner / processor to pick up the transaction and write it, for free, to its current block. If transaction volume is light on the network, the time required may be shorter as transaction processing helps miners complete block processing faster but the cheapskate merchant should plan on an hour for receiving a transaction confirmation.

Where This Works—And Doesn’t

At these speeds, Bitcoin cannot address the most important use case, point of sale, with anywhere near the same certainty as card network rails. While there are merchants taking bitcoin at the point of sale, for the vast majority, accustomed to a few seconds of waiting for the authorization receipt to print and a high degree of payment certainty, a Bitcoin transaction would be unacceptably slow.

E-commerce, on the other hand, is an obvious sweet spot. Purchase of airline tickets, hotel and rental car reservations, mobile minutes, and physical goods to be shipped or picked up later, are all candidates as each has a built-in lag between order and delivery. There’s time for the payment to complete or for the order to be placed in a queue for review by customer service representative, fraud detection tools, or a fraud analyst.

A potential gap in the e-commerce scenario does exist.  Many digital goods require near instantaneous payment approval and product delivery. For example, customers of music, apps, and other lower cost digital goods expect instant delivery via download.  With Bitcoin’s lengthy confirmation time, that’s a concern. Firms like Kount have assembled complex service sets to reduce payment risk for card payments of digital goods, especially where instant delivery is required. But as a digital equivalent of cash, acceptance of Bitcoin for these purchases is a risk that the merchant must calculate as the cost of trust.

If the marginal cost of delivering a digital good is small and speed of delivery expectations are high, then the merchant may be willing to assume the payment risk.  Given that the merchant’s cost is 1% for converting a Bitcoin transaction into USD, it may come out ahead considering its comparable payment cost may be 3% or more for a typical card not present transaction. The 2% spread could fund fraud losses.

Under those conditions, taking the gamble that the payment is good could be acceptable provided the merchant also employs some of the tools it’s used for card payment risk mitigation such as white lists, black lists, device fingerprinting, and other methods. After all, giving away material to fraudsters presenting bogus Bitcoin values will get tiresome if not expensive.

An intriguing use case, one that’s been in search of a viable solution for years, is online micropayments. Card-backed micropayments have been too expensive, even with transaction aggregation, for many content providers and publishers, especially those wishing to monetize single recordings, articles and back catalog material in the sub-$1 range.

Bitcoin continues to excite, confuse, and deserve evaluation.  If your payments team is wondering what the fuss is about, and where the opportunities may be, ask us about our private Bitcoin workshop, an extension of Glenbrook’s Payments Boot Camp.

4 Responses to “Bitcoin, Merchant Risk, and the Need for Speed”

  1. I think you are comparing apples and oranges between authorization and settlement.

    The ‘slow’ method actually takes usually between one and three hours to acquire six confirmations before there is pretty much complete settlement.

    You really just have to use Bitcoin to start understanding the settlement envelope.

    For almost all transactions the ‘fast’ method will be sufficient for reliable settlement, especially if a miners fee is included. This is because the probability that there will be a double spend is extremely low and most likely not worth the cost to the double spender of executing the attack since you could either reclaim the goods or bring suit for non-payment or fraud by the inducement.

    And all of these methods are far superior from a settlement perspective to the ‘sub-second performance of the payment card networks’ authorization process’ since those transactions are not irrevocable. With my AMEX Business Platinum I initiated a chargeback for a $1,000+ transaction against a merchant over a year after the transaction. And the merchant thought those funds were settled, when after over a year they get sucked back, to the degree that they actually probably filed their taxes using those figures! Sure, there may be ‘authorization’ but there is no settlement.

    With one confirmation you are pretty much guaranteed the Bitcoin funds are irrevocably settled. Sure, there may be a black swan every hundred thousand blocks like the hard fork a few months ago that might possibly affect a tiny percentage of users. But the probability of being personally affected, the effect being material and there not being other recourse is essentially nil.

    Therefore, I think the 2% fraud fund you suggestion is grossly over estimating the probability of the risk and the cost from it being carried out. Personally, I would allocate 0% if there were transactions with a minimum miners fee included. And if I were running a business like Bitpay then I would allocate less than 0.1%. After all, in the first 10,000 transactions Bitpay processed they had no losses from these types of hypotheticals.

    So you really are talking about transactions that are well outside the general envelope.

  2. Ashok Misra says:


    Thanks for another interesting article.

    A few comments :-

    – Not sure if confirmation of 6 nodes could be considered indisputable. I believe 51% of nodes need to validate a transaction to guarantee that there is not a double spend.
    – I understand that the reality is that transactions typically complete in about 3 secs.
    – It is possible to speed up transactions dramatically using marker address ( ) . I understand that Mt. Gox used the concept.

    Thus I am not certain that one can categorically state that Bitcoin is not suited for POS applications or digital downloads. Obviously, this is just my personal viewpoint / understanding.


  3. Anonymous says:

    The decentralized consensus blockchain mechanism that Bitcoin mining provides is a radical adjustment to how any other transaction system operates so it is understandable for author to be a little confused on the workings underneath.

    The term nodes and blocks are not interchangeable. Miners are nodes on the Bitcoin network just as are most users. When a miner solves a block of transactions that miner broadcasts the block to peer nodes, each of which then relays the block to other peers and eventually (within seconds) nearly all nodes in the world are able to add the new block to their copy of the blockchain. So the miner that first includes a transaction in a block is the miner that then earns the transaction fees paid by the user when sending the funds.

    The ability for other nodes (including other miners) to accept or reject a transaction in a newly arriving block is at the block-level of granularity. Either all transactions in a block from another miner is accepted or the block is rejected and the transactions remain queued. If the transactions in the block are all valid though then any miner that rejects the block would be penalized because of the competitive nature of mining. If other miners have already begun extending the blockchain and the wayward miner is still trying to solve a block (at a lower height than the others are working) then even if that miner does solve the block that work will be dismissed by other nodes (since they already know the solution for a block at that blockchain height).

    So simply, the transaction fee is only important to get included by the first miner. Once a transaction gets mined, it no longer matters to other miners whether or not a transaction fee had been paid.

  4. Anonymous says:

    Your “fourth option” is a little confusing.

    It appears when you used the term “cheapskate merchant” you were referring to the merchant that doesn’t use a payment processor like BitPay but instead follows a DIY approach, and thus incurs no fees whatsoever to receive payment using Bitcoin (except for exchange fees if later converting those Bitcoin funds into fiat).

    That has nothing to do with risk of a payment though — a DIY merchant that accepts a payment that shows “0/unconfirmed” is exposed to just as much risk as a BitPay merchant whose account is configured with the “fast” speed setting.

    It is the existence of a transaction fee paid by the customer which can cause a transaction to hang in the ether for hours and hours or, possibly, to never complete (if no miners end up picking up the transaction).

    To-date, there really isn’t much need for a merchant to be concerned about the risks of loss from a Bitcoin payment transaction. The attack vectors in which double spending is possible are today very narrow but that could change. Bitcoin’s protocol doesn’t prohibit a miner from assisting with activity intended t defraud a merchant using BitPay’s “fast” speed setting, for example.

Leave a Reply

Previous post:

Next post:

Clicky Web Analytics