Adoption of micropayments on websites solely relies on “how many clicks users have to do for a payment”. On news websites where the user’s buying window is super small (~1–5 seconds) the overall flow should be completed in few clicks with the minimum waiting time, before he or she switches to another website or changes his or her thoughts.
What Is a Micropayment?
A micropayment is a small transaction done online that can be just a dollar or even just some cents. Micropayments in a way have made online distribution of royalties, game purchases , pay per click jobs much easier and faster.
User Authentication Micropayment System
The integration of a micropayment system in websites requires the “User Authentication” to confirm the identity of the user before generating a payment request.
Currently, most of the micropayment systems are using username-password based authentication protocol which can be frustrating and time consuming from a user perspective. Most of the online users prefer to have one or two-click flow for micropayments for example digital content they want to access and read.
Ideally, a two-click payment flow for micropayments should cover user authentication and generating a payment request to the digital wallet (internal or third party). Leaving the payment request part for later, here we will be talking about the one-click flow for user authentication.
What Is a web3.js Library?
web3.js is a collection of libraries that allow you to interact with a local or remote Ethereum node using HTTP, IPC or WebSocket.
Pre-requisites: Injection of web3.js Library
We can build our own external plugin or extension which injects the web3.js stance into the website. There are also multiple standalone browsers that inject web3.js and extensions like Metamask which can easily be added on chrome or firefox browser and that can inject web3.js stance on every website that the user visits. Just by typing window.web3 in dev tools of browser, we can learn more about this object.
For one-click authentication flow in micropayments, using one of the functions sign messages with the private key serves the purpose.
One-Click Login Flow
Once we have our extension ready and installed on the user browser, all we need to do is do some changes in our application code. Let’s go stepwise:
1. Setting up a new user model: In the first step, we will be adding a new user model in our web application’s backend which needs only two fields —: publicAddress and nonce. This model can also coexist with the traditional username-password model.
The signup process is also super simple and time-saving as it just requires to fill only one field publicAddress as compared to multi-tab registration forms in the traditional model.
For each user in the database, the backend needs to generate a random string, for example, a random integer in the nonce field. To improve the security of the flow, the backend should generate a new random nonce after each use and update it in the database. So even if the user’s nonce gets comprised, it will require a new nonce every time to authenticate.
If the previous request doesn’t return any result, it means that the current public address hasn’t signed up yet. On the other hand, if there’s a result, then we should store its nonce.
3. Signing of the nonce: Once the front end receives nonce in the response of the previous API call, the extension will pop up a confirmation window for the user to sign the message, and the user can be also sure that she or he isn’t signing unwanted data.
When the user accepts it, the callback function will be called with the signed message (called signature) as an argument. The front end then makes another API call to passing a body with both signature and publicAddress.
4: Signature verification: When the back end receives a POST /API/authentication request, it first fetches the associated nonce in the database corresponding to the publicAddress given in the request body.
Having the nonce, the public address, and the signature, the backend can then cryptographically verify that the user signed the nonce means he or she is the owner of the requested public address hence authenticated. Further, a JWT or session identifier can also be returned to the front end.
Overall this flow can change the course of how we authenticate the users on the web applications. Especially online systems like micropayments, where users want to execute the whole payment in fewest clicks while expecting the highest security and data protection. This flow provides some edges over traditional protocols like:
- More secure flow as it mostly stores the user data on the local browser and machine as compared to online databases.
- Simplified sign up process and one-click password less authentication.
- User don't need to provide personal information like email address or contact number.
In the end, it will be interesting to see how efficiently we integrate this flow in our application while putting minimum action parts on the user.
Want to dig deeper?
What’s the biggest thing you’re struggling with right now that we as a technology consulting company can help you with? Feel free to reach out to us at email@example.com. We hope our assistance will help!