Payper — P2P micro-payments for the Open API Economy
This article describes a peer-to-peer (disintermediated) payment processing concept for APIs as it was presented at Hedera18 Hackathon organized by Hedera Hashgraph. The team that delivered the presentation in London: Alex Males, Alex Popa, Vlad Suciu and Eugen Males.
Introduction
An Open API Economy cannot work on the Internet when micro-payments infrastructure is missing at the fundamental communication layers. API Consumers need to go through the inconvenience to manually subscribe to payment models with individual API providers or intermediaries, while the best option for providers is to use payment processing embedded in API Management Tools, but tailored for the enterprises.
Payper (as in “pay per click” or “pay per view”) is an open-source tool that you download and configure yourself. You, as an API Provider, have 100% control. Technically, it is a request router that you place in front of your API (following your own networking rules). The API user is granted access to your API endpoints if he/she included the payment proof in the HTTP request.
Use case
A REST API provider needs to sustain its service, so they decide to charge small amounts for each API response with valuable data that they provide. The provider’s team installs the Payper Gateway as proxy to the API.
They create a price list with all API requests they want to be payed for and they input the price list with a configuration file. Each entry in the list specifies the API endpoint and amount in HBAR (Hedera cryptocurrency) to be charged. Being satisfied with the price list, they start the Payper Gateway that will now proxy all the requests coming from the Internet.
A user (customer) tries to access the API via Payper Gateway and gets a “402 Payment Required” HTTP status code. The API user must transfer the amount configured by the provider’s to its account in order for the access to be granted.
After having submitted the request for payment to the Hedera Hashgraph network, the receipt (or transaction ID) is added by the user to the request headers and the API request is attempted again.
The Payper Gateway verifies the receipt with Hedera Hashgraph network and, if the transaction shows that the requested amount has been deposited and confirmed, the access to the API is granted.
The sequence diagram below depicts the interactions in-between components as seen in the demo video.
The same sequence of actions is captured in the drawing below.
User Receives Payments From API Provider
Another use case is when the API User is rewarded for uploading content or for contributing in some way to the API.
The Payper Gateway can be configured to make payments to user’s account after the proxied API has successfully accepted a request (e.g. after the API responded with “201 Created”).
Principles
In author’s view, Payper is compatible with decentralization and censorship resistance principles promoted in cryptocurrency / blockchain space.
In an API Economy that is open on the Internet, and with the use of decentralized cryptocurrency networks, the API Users can benefit from an ecosystem that is anonymous and inclusive.
The exchange (money for API response) is not trustless and is entirely controlled by the provider, but assuming that the API User sends micro-payments, and puts at risk small amounts, the trust can be naturally established. It has not been studied yet how a malicious actor can benefit from an ecosystem where the API / crypto-currency micro-transactions are not atomic.
Striving for Non-blocking Payment Processing
The question arises how much overhead does the payment request (on client side) and payment proof verification (serverside) have on the API request execution time?
It certainly depends on the transaction confirmation latency of the DLT/Blockchain network, but there are mechanisms that can be put in place to minimize the resulted delay in API delivery of the response to the client.
Escrow Smart Contract
An API User deposits a larger amount to a smart contract and goes through a handshake process with the API Provider. That deposit is intended to “buy” a bulk of API requests, but does not put at risk the deposited funds, as the API User has full ownership over the unspent or not yet reserved amounts.
The API User (owner of account private key) issues expiring “tickets” that are passed along (e.g. HTTP headers) with the API requests that require payment.
The Payper Gateway stores the tickets after it verifies the signer and expiry time, but does not make requests to the network to verify each payment . The Gateway carries on with forwarding the request to the targeted API endpoint. On another thread, the stored tickets are redeemed (in bulk) with a network round trip.
Presentation Slides
https://docs.google.com/presentation/d/1W1UJ6xowGc8HutmLAzP1RHnlKLP5lUlzwhOF2gqLr5E/edit?usp=sharing
What’s Next?
The solutions described in this article are evidently free to use by any person or business for their own applications. Any feedback that improves the solution or points out security risks is greatly appreciated!
The intent for Payper is to evolve the project into an open-source tool set to aid in adoption of API micro-payments on the Internet. More details to come in a series of future articles.
Special Thanks
To Hedera Hashgraph Team for the cool global Hackathon! BeMyApp (especially to the team in London) for organizing the event and for providing valuable feedback and guidance for pitching and presentations! Thanks to all the participating teams for their inspiring DApp ideas!
