Overhide widgets are now generally available. Developers can integrated them into their Web products and leverage them for logins and in-app purchases.
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 overhide-status component. It also shows three purchase buttons. Clicking any of these will open up the overhide-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:
A logged in user can check their previous payments in new browser tabs — UI experiences vary by currency/wallet.
All upsells are via overhide-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:
The widgets are Web components you incorporate in your Web product.
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.
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.