Introduction to our capabilities to develop secure APIs for payment handling
You landed here - welcome
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
Status Update on our payment processing technology
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.
Who will benefit from this technology?
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.
Small to medium sized enterprises
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.
Mobile Application Development companies
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.
Data Content Providers
Any businesses wishing to provide content to your customers and charge for it should get in touch with us.
About our development process
Our focus is on the Job To Be Done - we identify the problem and see if we can fit the technology to it.
Recap on our payment handling for payment processors article
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.
New features completed for securing access to content to website data for payment processing
Token creation from payments for access to services
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.
Balance linking from payment provider references such as emails and transaction references
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.
Member balance matching to permitted services based upon credit balances
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.
Payment receipt and validation of url callback data from payment providers
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.
Off website payment verification (distributed processing with containerisation)
Transactional relational database store for managing member balance status (ACID)
Email only secure access for two factor authentication
We ask our users to register with two or more email addresses. Whenever they sign in, everything is email based.
Hashed and encrypted data storage of sensitive information
We don't really store sensitive information. At most we store email addresses, but even there, they are encrypted. So no passwords.
Hash only storage of emails linked to payments
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.
API key linked to accounts
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.
Configurable billing linked to API endpoints
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.
Off-site metrics on usage of website services
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.
Ready to offer this solution to customers
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.
Fair use policy throttling through penalties
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;
- Charge clients making too many requests
- Implement delays to clients making too many requests
This will help maintain the stability of services to customers and prevent risks to downtime.
Offline data and user management
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.
Distributing services - for example, API
Having the API separate from the website, and taking this a step further and setting up gateways to data can make sense.