overhide.io blog
— effortless login — from social to wallet — for your Web project
— authorize extras with hassle-free "in-app-purchases" (IAPs) in dollars and cryptos
— back-end code optional and front-end only OK... write minimal code once but support dollars and coins
— as unliable as possible — no custody of user data for logins and purchases
05 Jul 2021
by Jakub Ner


pay2my.app widgets are now generally available. Developers can integrated them into their Web products and leverage them for logins and in-app purchases.

Use of the widgets is documented in their repo, but you’ll likely want to jump straight to the demos.

The widgets wrap the ledgers.js library and allow quick integrations of ledger-based authorizations (LBA) into any Web offering.

High Level About

The below infographic conveys at-a-glance what you get with these widgets:

The top-left shows a sample Web app with a nav-bar housing the pay2myapp-status component. It also shows three purchase buttons. Clicking any of these will open up the pay2myapp-login component which serves as our “login widget”.

When a user wants to authorize for a feature; different UI experiences will present themselves depending on whether the feature is free, the user wants to pay in dollars, or the user wants to pay using a wallet, e.g., above, see:

  • anti-bot authentication
  • purchase for dollars
  • puchase with crypto wallet

A logged in user can check their previous payments in new browser tabs — UI experiences vary by currency/wallet.

Anatomy of a Ledger-Based Upsell

All upsells are via pay2myapp-appsell widgets sprinkled throughout your Web offering.

You do not need to use ledger-based authorizations (LBA) for upselling in-app purchases (IAPs). You can just as well use the system solely for free-of-charge authentications (logins). Regardless, you have the freedom to add paid features.

With LBA IAPs your customers pay their money to your ledger address on a supported ledger (ethereum, bitcoin, overhide — overhide ledger is not for value-transfers, just tracks receipts from Stripe.com). From then on feature authorizations are based on sums of payments to your ledger address — optionally, within some amount of time. All features can share one of your ledger addresses or have different addresses — depending on how you want to slice and dice your mapping of payments to features. All features sharing addresses become available as soon as sufficient monies are paid for any of the features.

Each IAP widget is configured with:

  • cost in US dollars
  • number of minutes within which to tally payments
    • can be months, years, your choice
    • optional, can be across all time
  • Web components slots and CSS to customize the UX look-and-feel
  • your ledger addresses — the to addresses — to tally payments from your customers against
    • customer pays to these addresses to authorize
    • for USD, payments are made to Stripe.com and overhide’s ledger just tracks receipts
    • for cryptos (ethereum, bitcoin), the actual value-transfer ledger (blockchain) is used

How Much Code Do I Need To Write?

The widgets are Web components you incorporate in your Web product.

At the very least you need to incorporate the hub component, the login component, and one or more appsell components.

For a bare minimum, that’s it. Just a bit of code in the front-end. Whether straight into the DOM or using a framework as seen in our React.js demo.

But, for some workflows, it will be prudent to have a back-end.

This is why most of the demos use a very simple back-end (see the Uses Back-End column in the demos table).

The demo back-end is just a node.js application. For the live demos off of github we actually run them as Azure functions. You should be able to easily lift that code and work off of it.