We focus on solutions that makes sense. Whilst payment handling online may seem like a simple state of affairs, the regulatory landscape is constantly changing. As soon as Chat GPT and other LLM Artificial General Intelligence came out, there are discussions that it must be regulated. Small to medium sized enterprises are having to jump through larger hoops just to compete with enterprises with substantial capital. There are still substantial risks to any business such as data breaches, hacks, etc.
We have come to discover that many of the cloud based solutions offered - may work well for many businesses, but they come at a price and a lack of control. You are free to choose, so please read on.
If you wish to know more, reach out at www.inforhino.co.uk/contact
Really, these are just notes and information on who may benefit and what work has been completed. We have been testing the claims and user access on our Web Data Platform to charge fees based upon access to web content and data.
Many large businesses will already have websites. Why not have a separate data reporting solutions to charge customers for access to data? Much of our application architecture sits outside the website meaning you have better control on access to your data.
See if it makes more sense to work with our approach to adding resilience to payment processing, separating out data and validation. Certainly, we can help lower hosting costs by setting up processing architecture on cheaper kit.
Developing mobile phone apps is not the same as managing huge amounts of data and charging for it. We can set up back end data architecture to help make your payment processing more distributed and resilient.
Any businesses wishing to provide content to your customers and charge for it should get in touch with us.
We architect our solutions in many different technologies including - Microsoft .Net, ASP.Net, Dotnetcore, SQL Server, Oracle, JavaScript, Node JS, SSIS, ADF, Azure API Gateway, IIS. We work with trusted colleagues when more oomph is needed to deliver for our clients.
Our focus is on the Job To Be Done - we identify the problem and see if we can fit the technology to it.
The last article we wrote covered the basic mechanisms by which we are charging customers to access content within our cryptocurrency platform. We explained how it is important to decouple payment providers from the website itself to avoid making expensive coding changes on a live website. It is important to note, our Web Data Platform is a generic website providing a complete set of data ready content resources to take customers to the next level. Our clients can give their customers access to information without heavy website development. Much of the content you see within this and other instances of our WDP, sits outside the website and database altogether. The objective of this is to reduce the amount of time spent maintaining a CMS, offering a platform more oriented towards data engineers and data architects.
Using secure algorithms, we build tokens for linking to payments to update balances, at which point users can securely receive this information through our API or the website.
As experts in database development, we have the perfect set of data capture processes for managing user purchases, and analytics to provide reports on usage for our users.
Our data platform (ASP.Net MVC core) has services and utilities working to keep most data in plain text format only when necessary. This means we can access information for our members in isolation of other members ensuring users won't get other user's data on balance info.
We have webhooks that accept messages from payment providers. We generate secure payloads that can be interpreted offline to validate payments to manage member balances.
We ask our users to register with two or more email addresses. Whenever they sign in, everything is email based.
We don't really store sensitive information. At most we store email addresses, but even there, they are encrypted. So no passwords.
Our balance database not store encrypted data relating to balances and purchases. We hash/salt the original data meaning dictionary attacks are unlikely to be fruitful. We are planning to add additional middleware to make it almost impossible to get meaningful information from hacking the data store.
Members are given an API key which if supplied in the header will charge in the same way as if logged in. We use a combination of claims and JSON Web Tokens (JWTs) to grant access to website resources in exactly the same was as a user through the front-end.
Certain end points that deliver data offer the capability to charge the user for one or more services. We can configure these to charge for access by service.
We have a number of reports to show us what our users are consuming, to help understand how close we are to reaching capacity on the website platform.
When architecting how we may charge our customers for accessing content, we researched many decent looking payment tokenisation billing providers. The challenge we have found, these solutions only scale on their terms and gets expensive quickly. There are often limits and less ability to add more resilience. Where these billing providers do excel is giving most users a fairly decent service at a cost cheaper than most could develop it at.
Each customer contacting Info Rhino would be receiving a customised solution which can scale out to be managed on-premise.
One of the biggest challenges any data platform experiences is users can present to a platform is excessive use by overly accessing an API or website. We are planning to add optional capability to either;
This will help maintain the stability of services to customers and prevent risks to downtime.
We do this already with much of our platforms. Rather than building more technology into the website, we interact with data stores to help back up information, encrypt it, and update information.
Most websites add administration to the same website, adding roles for admin accounts. This leaves a possible way in for administration access to the website. By turning off the admin features or hosting them offline, we can manage our applications.
We are adding more analytics on our platform. Watch this space.
Having the API separate from the website, and taking this a step further and setting up gateways to data can make sense.