In all industries, there is a trend towards personalization. Clients want a product or service that is personalized to their needs and don’t accept anymore to pay for all kinds of whistles and bells, which they never use.

The current pricing model of many digital companies is a (monthly) license/subscription model, where you get a pre-defined package of features. Alternatively, a lot of digital companies provide free services, but gain revenues through advertisement and selling (all or not anonymized) user data.
The first model provides customers a single choice, between paying nothing (thus getting nothing) and paying a large fee (thus getting everything, but also a lot of unused features). The 2nd model restrains the usability (all kinds of adds popping-up and not enough advertising in the world to make all the Web sites profitable) and comes at the expense of privacy and personal data control.

A potential new alternative is to put the consumer in control, allowing him to pay at a more granular level (pay by single service unit) for what he actually needs (consumes), i.e. a la carte service. For example, on a newspaper website, the customer would pay for each article he wants to read a very small fee, which is invoiced immediately. This could also be used as an alternative to blocking users with ad-blockers, i.e. when reader is an ad-blocker a pop-up will appear asking him to disable ad-blockers or pay a small amount to view the content. This alternative gives users the ability to support high-quality content without having to subscribe to a long-term, expensive, all-including subscription or to cope with ads or privacy issues. The visited websites make a profit out of numerous, tiny transactions.

Mixed models could also be interesting, i.e. pay a subscription model for a base package and be able to get additional content by paying a separate payment or by allowing the service provider to push you adds or collect your personal data. The customer could decide himself, how much he wants to pay himself versus how much advertisement he wants to see or how much personal data he wants to share.

Although this flexible pricing model (pay by service unit) sounds very appealing both to the producer and the consumer, a number of restrictions currently burden this way of pricing:

The small payments are too costly to invoice separately (due to the cost structure of the financial institutions), i.e. the fee paid to the payment provider (bank) would be higher than the money received by the actual service/content provider from the user.

There is at the moment no smooth way to execute a payment, without passing by a complex and lengthy digital signing process. Furthermore, setting up a payment account on a website, just to see 1 article, would result in a high bounce rate.

Such small payments (when this model would become successful) would increase the transaction volumes enormously, giving severe technical challenges to the payment network. E.g. suppose you have to pay a fraction of a eurocent per website access. This would add billions of transactions to the existing payment network.

Solution for refunds are required. E.g. allow a user to get a refund if he closes the browser window within 15 seconds. This would avoid a user paying for a page on which he clicked by accident. Of course, mechanisms also need to be foreseen at that moment to avoid abuse of this refund mechanism (e.g. users or bots quickly downloading the page and afterwards closing page, allowing them to capture the content but still get a refund).

Huge amounts of payments appearing in customer account history, making it difficult for the user to find relevant information in his account history. A PFM solution correctly categorizing and allowing easy filtering of (certain) micro-payment can give a solution here.

Frequent customers are penalized when paying per service unit. This could be solved by a variety of payment schemes, but this could make pricing even more complex and intransparent for users.

Those hurdles exist already since the rise of the internet and can be considered as a real flaw in today’s internet. In the first version of the specifications for HTML, the founders of the modern internet, had already envisaged such micro-payments and even foresaw a specific HTTP return code, i.e. 402 stands for "Payment Required". Since the 90’s several online start-ups (e.g. Hashcash, Millicent, Cybercoin, CyberCash, Beenz, DigiCash…​) have tried to provide a solution, but the usability of these solutions remained very poor.

This is where micropayments come in the picture, as they aim to provide a modern solution to these technical and usability limitations. Typically, micro-payments have following requirements:

Small amount (different definitions exist for this, but a common definition is less than $10)

Large volumes

Online payment

Small transaction fees (minimal costs to execute the transaction - significantly smaller than the already small amount of the payment). E.g. Stripe charges $0.30, plus roughly 3% of the transaction to execute the payment. This is way too much if the payment is less than $1.

Instant payment (i.e. instantaneous debiting and crediting of the 2 involved accounts)

while still meeting very high non-functional requirements:

Anonymity / Privacy: avoid companies to derive personal details from the payment instruction

Scalable: elastic scalability of the transaction volumes

Reliable / Available: 24/7 available

Secure: automatic prevention and detection of attacks and fraud attempts

Usability: easy to use (e.g. avoid downloading software, avoid authentication of bank accounts, avoid setup of relationship between the involved parties)

Most likely the above limitations will best be overcome by having an integrated wallet in your browser. The user would setup a single link with his bank for this wallet, after which the different online websites only have to connect with the wallet and don’t need to have any account information (only a cryptographic payment token). The user would just get a pop-up to confirm payment, after which wallet takes care of the payment instruction.

Nonetheless even if the above barriers are overcome, customers still need to get familiar with these types of services/payments. Currently customers are still hesitant to pay for content (they expect web content to be free), even if it is a fraction of a euro. Furthermore, studies show that consumers dislike micropayments, as they make people think too much and they result in a payment trace of every action the user has taken on the internet.

Micropayments can be used in several use cases, of which some of the most promising:

Paying for content on the internet, e.g. pay to read an article (cfr. the Dutch startup Blendle), pay by message sent on social media, pay by viewed video (e.g. pay $0.04 to skip that 30 second YouTube ad)…​ This could be especially interesting for smaller players, which have difficulties to convince customers to pay a monthly subscription.

Incentivizing / gamification:

A government could pay a micro-payment each time you use a garbage bin (incentivizing to avoid waste)

Insurance companies could pay their customers each time they take in their medicines or each time they make a walk or go running

Granular metering:

Instead of paying by kilometer driving, governments could opt to install devices on every crossroad. Each time passing by such a device, a micro-payment is done.

Pay for Wi-Fi internet metered by the minute (or second), e.g. for WiFi on the airplane or a traveler in a hotel, who just wants to send a message he has well arrived.

Pay for compute power, i.e. sell the compute power of your PC

Blockchain: currently most blockchains are linked to a crypto-currency to let users pay for transactions and reward users, who validate and verify a blockchain transaction. With micropayments, Blockchains could be linked to a standard currency instead of a crypto-currency.

Security and fraud detection: when accessing a website costs a fraction of a eurocent, this would not really burden a real physical user, but for hacking attacks, content scraping and bots (e.g. for online advertisement fraud), this would give an issue as they make thousands of connections per second, ultimately leading to high bills. Therefore, linking a micro-payment to the possibility to access a website, would significantly increase security, as those automated "attacks" would no longer be financially viable.

IoT devices paying directly: users could authorize IoT devices to make payments on their behalf. As long as these amounts are small enough this could be fully automated. However specific mechanisms will need to be setup to manage in a safe way the restrictions and authorizations for the payments.

Support someone with a tip, e.g. your favourite artist/auteur (e.g. start-up Patreon), a coder who fixed a bug in open source software, an auteur of an interesting blog, an online chef for a helpful online recipe, a Quora respondent who helps you solve a problem, pay for every like/upvote in Quora, Facebook, LinkedIn…​

Microfinancing of (charity) projects in emerging countries via micro-payments (cfr. German start-up Rocket or donate to charities via Facebook Causes)

Pay for someone’s time, e.g.

Pay someone (e.g. venture capitalist, celebrity, recruitment mailing) for reading your mail, as an incentive to read the mail (cfr. start-up Earn.com)

Pay a contribution to perform certain tasks, such as testing beta versions

Pay someone for watching advertisement

Gambling, e.g. a million people making a $0.10 payment and a random selection of 1 person winning (assuming a profit of 10% for the gambling company, this would give a pay-out of $90,000)

Gaming: this use case is currently the most-used case of micro-payments, i.e. a lot of games allow you to get extra lives, moves, in-game gold/diamonds, levels, tools, weapons…​ for a small micro-payment (e.g. Fortnite, FarmVille, Grand Theft Auto, Candy Crush…​). Even though this accounts for hundreds of millions of dollars, the downside is that half of all this money is only coming from 0.19% of the users, showing the small number of users actually wanting to pay for these features.

Usage of different APIs, i.e. pay by API call

Where payments are currently still the exclusive domain of the financial services industry (even though many Fintechs are challenging this position), the financial services industry might not necessarily be the best positioned to manage those micro-payments, as other players might have a more advanced offering:

Telcos:

More experience in the domain of micro-payments, e.g. premium SMS, mobile content billing, pay per telephone call, pay per telephone minute, pre-paid cards, mobile payments via SIM cards like in Africa (e.g. M-Pesa in Kenya).

Strong link with IoT devices and the resulting payments from it

Big Tech giants like Facebook, Google, Amazon, Tencent or Alibaba:

Already a worldwide presence and IT skills to cope with the challenging non-functional requirements (like volume, performance, security…​).

Most of them already do micro-payments (e.g. to download an app or song), which are charged in a consolidated way on a monthly basis (or paid upfront), i.e. virtual pooling. This type of virtual pooling requires however trust in the central party and is not instant. Furthermore, the user loses the detailed transaction information in his bank statements (some tech companies offer an API to get the details, but this requires a specific integration per vendor). All parties are however working on improved solutions, e.g. Google is building a micro-payments platform based on Google Checkout, Facebook is launching (together with 27 other partners, like Visa, Mastercard, eBay, Paypal…​) a new crypto-currency Libra in 2020…​

FinTech players or payment facilitators like Paypal or Stripe, as they are already providing very similar services

Blockchains with associated crypto-currencies: Bitcoin and other crypto-currencies have great potential as a platform for enabling micropayments, as they (automatically) establish trust and avoid any intermediaries. Even though the current crypto-currency networks aren’t capable of processing large volumes of micro-payments, solution are being investigated (e.g. payment channels, Lightning Network, "off-blockchain" transactions…​), even though those still face significant limitations.

As with any emerging technology, micropayments will have their challenges in being adopted, but once adopted they will significantly change our way of doing business and impact financial institutions. Banks will have to adapt their IT infrastructure to cope with the exponential rise of payment volumes, they will need to foresee (PFM) tools to support customers managing their account history, fraud and AML detection systems will need to be adapted…​ It is therefore in the best interest of every large bank to prepare itself for this shift.