Currently tinkering with an mqtt based, high volume IoT messaging platform (subset of pain.013 / pacs.008 based messaging implemented in mqtt). Trying to look into the crystal ball for how iot billing and payments systems will work. This is a note-to-self article.
The basic premise is that transaction processing costs cannot be borne in most IoT payment use cases, so we need to use an aggregation model (think about your "EasyPass" toll payment model, or your AWS bill). As of this writing, there aren't any clearing/settlement systems that currently support millions of transactions per second, and even if such a platform were to exist, the costs of operating such a platform would far exceed the monetary motivations for implementing fractional dollar value micro-payments.
In addition, IoT micropayments need additional "features" that are not well supported using current payment mechanisms.
- Scalability (Visa can currently support ~65,000 payment transactions per second [ref: Visa ~2019]) - As we know, IoT transaction events can easily exceed this limit
- Micro-payments - Transactions can be billed in very small increments e.g. AWS "unit of measure" for requests is 1000 reqs.. Payment systems are not currently setup to efficiently handle a payment of $0.19
- Non-recourse Settlement - The volume of anticipated IoT payments also means that these type of payments will be packaged/widgetized and therefore individual "swipes" will be non-recourse and non-reversable.
- Velocity & Budgets - Such a payments system is prone to mis-use and needs to support both velocity limits ($$/second) as well as budgets ($$/hr, $$/day, $$/month) etc.
- No Authentication - There are several use cases in IoT payments where there is no authentication (and in fact, no identity) exchanged. IoT payments need to support an anonymous exchange of value.
- Messaging - I've written about ISO20022 messaging for IoT billing & payments previously; I think we need a subset or an abstraction/interface API to simplify the implementation in an IoT environment given the resource constraints in embedded devices (i.e. device with an ESP8266 chip or bluetooth low-energy BLE chip with EPROM/NFC capabilities cannot run a full stack ISO20022 implementation effectively).
Given these constraints, I've been tinkering with some of the scaffolding of an IoT payment system may need.
- Identity: Offline token based identity / authentication (this part needs a bit more thought in implementation).
- Scalability: The current messaging systems like ISO20022 are significantly expensive to operate for micro-payments. Exploring an MQTT based messaging system to track IoT consumption. MQTT is a telemetry protocol - light-weight, scalable and can be clustered (wikipedia link)
- Settlement: As mentioned earlier, As of this writing isn't any clearing/settlement system that currently supports millions of transactions per second, and even if were to exist, the costs of operating such a platform would far exceed the monetary motivations for implementing such a system/platform. This Catch-22, in turn, leads us to blockchain platforms which are now being built for high volume money movement (agnostic of the value of the money movement). There are some blockchain / side-chain projects which target this use case (abilty to support millions of txns/sec). For now, we assume that settlement will be performed on a "per block" basis (e.g. one charge / money movement per 1000 IoT "transactions" or similar; with the monetary risk being borne by the provider given the non-recourse nature of a typical IoT transaction).
- Velocity & Budgets: Currently in a micropayments environment, velocity risk concerns are being handled by defining consumption budgets. Both providers and consumers are protected by leveraging budgets, since it allows simplification of buying behavior and caps the overall perceived risk of runaway expenses (e.g. causing a gigantic AWS billing due to a out of control logging issue causing millions of requests/sec)