• Mohit Kumar

How to setup one-click user authentication flow for micropayments

Adoption of micropayments on websites solely relies on “how many clicks users have to do for a payment”. On websites like news where the user’s buying window is super small (~1–5 seconds) before he or she switches to another website or changes his or her thoughts, the overall flow should be completed in few clicks with the minimum waiting time.


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 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 paying the goods for example digital content they want to access and read.

Ideally, a two-click payment flow 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:

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 inject web3.js stance on every website user visit. Just by typing window.web3 in dev tools of browser, we can learn more about this object.

Web3.js is a javascript based library, mostly used for direct interaction with the blockchain network. It has many functions such as retrieving current block information, sending transactions, sign messages with the private key (web3.personal.sign), and many more that are easily accessible by the application’s front end code.

For one-click authentication flow, 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 will require 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 somehow, it will require a new nonce every time to authenticate.

2. User fetches their nonce: In our front-end JavaScript code, we have access to window.web3 object components from Web3.js injection. When the user clicks on the login button, we fire an API call to the back end to retrieve the nonce associated with their public address. Something like a route with a filter parameter GET /api/users?publicAddress=${publicAddress} should do. Since this is an unauthenticated API call, the back end should be configured to only show public information such as nonce on this route.

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 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 compared to online databases.

  • Simplified sign up process and one-click password less authentication.

  • User doesn’t have to provide personal information like email address, phone no. or others.

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.

Do you want to know more?

If you are interested to learn more about micropayments and the current state of its affairs, visit and follow me on Medium and Twitter.

  • Facebook
  • Twitter
  • LinkedIn
  • Pinterest