The invoice-based payments specification in a nutshell
Old-school Bitcoin payments work like this: the merchant gives their customer a Bitcoin address and an amount of money to transfer. The recipient then has to listen to the Bitcoin network, waiting to see if and when the payment has gone through.
There are several problems with this process. What do you do if someone overpays or underpays? What if the transaction fee is too low and it ends up stuck in the mempool? What if a merchant sells microservices to millions of clients, and they have to monitor the network to confirm each of the payments of a few cents each?
With invoice-based payments the process is flipped around to correlate with the invoice and accounting processes businesses are familiar with.
It works this way:
The merchant, by means of their service provider’s app, issues their customer an invoice that describes the terms and conditions of the payment.
The customer’s device receives the invoice, creates a transaction to fulfill the conditions and asks them to confirm the purchase. The customer’s device now relays this signed transaction back to the merchant where their application checks that the transaction meets all conditions. Only once the merchant is satisfied with the transaction will they accept it and broadcast it to the network.
Conducting payments this way has several advantages:
- The merchant can pre-check transactions before they even hit the blockchain. If the fee is too low or the invoice has expired, they can let the customer know before broadcasting the transaction. Given the built-in return address functionality, the merchant can also easily refund a customer.
- This order of events makes payments more secure for merchants. As the merchant is now responsible for broadcasting transactions to the network, the customer has no idea of the timing that would be required to get a competing payment into the mempool. Most invoicers using the current standard will connect with miners directly via the miner API (mAPI) to confirm that the transaction will be accepted. Once the merchant has the miner’s confirmation, they have a very high level of assurance that the transaction will hit the majority of the network very quickly. The merchants don’t have to run their own Bitcoin node and are able to accept secure cash payments.
- The process assists in scaling Bitcoin payment businesses, as having to listen to the blockchain and specific addresses can become quite inefficient at scale.
- Once the invoice process is standardised, applications will be able to take care of complex transaction negotiations ‘beneath the bonnet’ of their user interface. When done right, the merchant and customer will simply be able to tap ‘invoice’, ‘pay’, ‘validate’ and ‘finalise’ on their devices.
In this edition of our TTDR (Too Technical Didn’t Read) blog, we speak to Bernhard Müller, co-proposer and co-author of the invoice-based payments standard. Bernard is the General Manager and Board Chairman at Centi – the cash register of the 21st century and provider of a best-in-class payment API.
Technical Standards Committee (TSC): Did your awareness of the need for this standard arise from your business venture, Centi?
Bernhard Müller (BM): Yes, that’s very much the case. I had a certain awareness of the issues even before starting Centi. I could tell that these payment-related standards will have to be extended or refined. Although the foundational standards allowed a sort of ‘handshake’ of communication between recipients and senders, we had a lot of ideas for extending it to be more useful, and also streamlining the standards that were there before. By the time we brought it up with Bitcoin Association, there were other companies who had brought up the same need in parallel.
TSC: What needs did you detect that this standard will solve?
BM: There are two main reasons why I asked for this working-group to be formed. One is that BIP270 is described in various update statuses, but none of these define exactly how industry players are implementing it today. Payments businesses within the industry have coordinated how to implement it between themselves, but it wasn’t documented so someone who wants to implement it for the first time will know how to do it. With this standard, we’re making sure that there’s an invoice-based standards repository in place that’s maintained and owned by someone.
Secondly, we recognised the need for new extensions to the current payment standard to allow someone to invoice for BSV-based tokens (representing loyalty points, gift vouchers, etc), and not only BSV. Tokens are designed for particular use cases, and a merchant might accept a range of them in lieu of payment. In fact, we are extending the standard to allow merchants to offer customers the option of paying an invoice even in multiple types of tokens. On the user side, their wallet service will receive the invoice with all the payment options, but will probably only show its users the options that correlate with the funds in their wallet. This will make it super simple to make a transaction either in BSV or in stablecoins, or where you pay half in loyalty points and the rest in BSV.
This option to accept a combination of payment types is quite unique and can change the way that vouchers and coupon systems operate. The way it currently works, each e-commerce or loyalty system offers you vouchers and points on their own dedicated system. You might have bought, earned or received a range of them, finding it difficult to keep track of them all and to make use of them.
What we’re building at Centi is a system that integrates all these loyalty points, vouchers, coupons, tickets, etc. into one wallet. The invoice-based standard is essential to our business as we also want to be able to invoice such tokens. Some of our target markets are smaller companies who don’t have the money to develop their own consumer engagement apps, but would like to launch a promotion, loyalty scheme, etc. These small and midsize businesses can use the app to issue whatever tokens they wish, and they can also set up the terms and conditions for consumers to spend it again.
Something else that’s part of the standard is that we allow return addresses to be included into the invoice. Most of these reward programmes related to credit cards, airlines and health insurance schemes run on a separate system from their payments. Instead of simply getting cash back in the account you paid from, you get issued points that operate on an entirely different system. The advantage of using the blockchain to account for points and purchases on-chain, is that you could exchange our wallet service for another, or build your own, and still account for your entire transaction history. Although we build our business to be so efficient and user-focussed such that we keep our customers loyal, we don’t want to keep them by locking them into a system where they have no other choice.
TSC: Which Centi use cases rely most on the invoice-based payments standard?
BM: Our payment API can be used for any type of business, whether you have vending machines or an automated car rental service. Nonetheless, there are three use cases we are actively developing for.
The first is payments in retail and e-commerce that we’re integrating with a big payment service provider (soon to be announced).
The second use case is events where there’s a need for multiple tokens to be accepted – an industry that’s very underserved in terms of payments. A big music festival will be charging guests a certain fee, but they’ll also be issuing their artists and crew members vouchers, sometimes as a percentage of their fee. These vouchers can only be redeemed on premises for specific uses, like for food. There will also be sponsors who are allowed to eat and drink for free at the festival.
If you only allow one type of payment at the festival, you can’t cater for these different guests. You could ask your sponsors to collect receipts for all the refreshments they bought and then refund them, but that would be very unprofessional. With Centi, an event can issue tokens that are the equivalent of traditional paper coupons or vouchers – except they can’t get lost, get trampled on, or stolen. Centi gives the events coordinator a dashboard that shows exactly which vouchers were spent at which vendor (e.g. the hot dog stand), and how much you have to reimburse each of them.
The third major use case is selling online media for micropayments, where we also use the invoice-based payments.The idea is to have a widget that you can place within a paywall as an alternative to the subscription model. This would allow for a pay-per-read, or pay-per-view model, which is a business case we are actively developing.
TSC: Which foundational standards is this one built on?
BM: This standard covers a number of previous standards including BIP 270, BIP 271, BIP 272, BIP 273, BIP 274, BIP 275, BIP 282. Each of them is responsible for a different portion within the chain of communication between transaction senders and recipients. While they all reference BIP 270, they dive down into the granular detail of a particular part of the process, for example, the content format of a message, or providing an alternative method. We looked at the range of standards and saw the potential to streamline them by creating one document that covers them all. And that’s what we call the invoice-based payment standards group. Except for two BIPs – one that isn’t in use, and the other which is made obsolete by this standard – we’ll be able to include them all under this new umbrella.
TSC: Will the Travel Rule be included under this umbrella?
BM: The invoice-based standard allows any miscellaneous data to be included with a payment, including Travel-Rule data. And yet, the Travel Rule is a separate standard that deals with the specific message that will travel back and forth between parties.
The interesting thing about the Travel Rule is that its working group has expanded beyond the BSV ecosystem. Although it was initiated by people like Angus Brown from Centbee, companies that deal with multiple cryptocurrencies have started seeing the value of the standard and wanted in too. With the FATF’s travel rule applying to VASPs (Virtual Asset Service Providers), an appreciation of standards like these are growing.
It is a matter of current discussion if and how the travel rule information would travel within the invoice based payments standard, and it is a good option. There are clearly cases, however, where the Travel Rule can apply where a payment is not based on an invoice, e.g. when someone sends money to support their relatives abroad or other private transactions.
TSC: Which kind of businesses and transactions does the Invoice-based standard apply to?
BM: If you look at BIP 270, it’s mostly used for customer to business payments. It could also suit business-to-business or machine-to-machine scenarios, and many others we haven’t thought of. Basically wherever one party provides an invoice to another party. Frankly speaking, we’re not limiting the standard’s use cases. That’s why it was so important to bring in all these reviewers from other businesses – to make the standard generally usable.
TSC: How can someone get involved in the process of standardising this process?
BM:. The standard is currently in review state or in version 0.2, and it’s already received enormous interest. We have 25 reviewers from all around the globe, so we had to do three separate kick-off meetings to accommodate the different time zones.
We’re also getting closer to the end of this internal phase, as there are fewer comments and concerns. Soon we’ll go into the public review phase, and that will open another opportunity to get involved and comment for subject matter experts from outside the working group.
Once the standard has reached the published phase, you can already start implementing it. Once enough entities have implemented it and it’s shown to work, it will become a recommended standard. So if you’re interested in piloting the standard, keep an eye out for more information.
