New Service - eCommerce content charging for users accessing content 04 Sep 2023

Recap on our article for integrating payment handling into a website

You may have read our recent article https://www.inforhino.co.uk/article/Website%20Technologies/Payments/How-do-I-integrate-cryptocurrency-payment-handling-into-my-website-24-Aug-2023.

It set the scene for our thinking behind implementing payment handling to give website content creators a buffer to payment gateways, and make their website anti-fragile. Our technology gives content creators the ability to have one or more payment providers without needing to add a single piece of vendor specific payment processor code or logic to their website.

This is achieved by decoupling the payment verification from the website and only leaving an endpoint/callback url available for webhooks to post content to.

The rest of the magic happens behind the scenes by running a small set of services off website that manages interpreting the payment notifications and updating the members balance if validated successfully.

We never store the user's email in clear text form in relation to payment. This gives a nice way for the website to simply accept requests for access to content and update the member's credit balance in exchange for content.

If you want to find out more, fill out our contact form www.inforhino.co.uk/contact

Introduction to eCommerce

The online explanation

The term "eCommerce," which stands for "electrical commerce," describes the exchange of products and services over electronic networks or the internet. The prevalence of e-commerce has increased along with the development of the internet and other digital technologies. The essential elements and traits of e-commerce are as follows:

Online Shops: The term "eCommerce" refers to a broad range of online shops and markets where companies and private individuals can list and sell goods and services. These retailers can be big e-commerce giants like Amazon or eBay or tiny, independent internet enterprises.

Electronic Transactions: Electronic transactions are the backbone of eCommerce, allowing users to explore merchandise, make selections, add goods to virtual shopping carts, and then pay for their purchases using a variety of payment methods such credit cards, digital wallets, and online banking.

How we view eCommerce

It is the availability of electronic interfaces to allow users to pay for digital and physical goods and services.

The Payment database

We have built a robust set of transaction managed payment processing logic within our database layer to increment member balances and decrement those balances when services are consumed.

The current implementation links one or more services to the payment, allocating the appropriate service to the payment. For example, we may have a gold, silver, and bronze tier. When a payment comes in, we can allocate the appropriate tier that the payment is at or above in terms of value. This was created as such to permit the possibility that payments maybe split up by a provider or payment providers fees be too high.

We have made provision for the ability to add credits to users outside of the payment provider. Perfect for new websites to test accessing content decrements balances.

Websites that can benefit from our approach

Token platforms

Platforms that issue tokens in exchange for content is perfect.

Social media platforms

Websites where customers pay for credits to contact other users are perfect for this. Dating websites are one example. Other examples are subscription based platforms where users gain access to other members and content. Startup and mentoring websites are another example. We are in discussion with a logistics provider to make our payment processing solution to their logistics website customers.

Professional Services Websites

Whether a service provider is buying a physical or virtual product, it can be useful to get credit upfront in lieu of services.

Credit sharing platforms

One of the interesting features of credit based platforms is that these credits may be given to other users without incurring taxable events in some jurisdictions (not financial advice).

Websites without the pedigree to get merchant accounts

Websites that are starting up will use an intermediary payment provider but they are still left with the risk of chargebacks.

What are the real advantages to using our payment processing tier to your business?

Avoiding taking any personal financial details on your website with regards to payments

When we first built this solution, we wanted to avoid having to capture payment details on our website. We wanted to be able to use cryptocurrency or any of the larger fiat payment providers.

De-risking your business

There is absolute value in processing payments off the cloud, on premise. Creating the validation logic off website stops all the need to change it when a payment processor changes their methodology or data.

We have seen many legitimate businesses and causes get platform bans and even deplatforming. It can make sense to facilitate switching to a different provider by decoupling your tech from the platform.

Reducing the complexity of your website

A large part of our data processing and payment processing architecture is event driven. There are rarely more than a few sequential processes. Much of our original functionality within our website solution architecture is being distributed off website. Virtually no domain specific logic exists within our website, when we do it is plugin based.

This is how all websites should be built, sever side technology as agnostic as possible, domain specific logic decoupled from the website. Of course, Web technology has many ways to bring you back in but certainly, we have sought to simplify the website.

How would you implement this for our business? Q&A

Our software runs on a Windows server. We are looking to containerise this. You may prefer to run this on the cloud or on a VM.

Our focus is on three main areas;

• Creating the payment processing build for your organisation
• Setting up the payment ivalidator for your payment provider
• Ensuring your website can communicate with the member credit store to apply charges, and retrieve balances

Are there extra options like using the payment providers API?

Many websites like their in store purchases to be seamless without leaving their site. That isn't really the case any longer as most banks will enforce PCI checks etc. Each potential vendor you may decide to use to handle your payment processing may provide APIs and we will work with you to identify the best solution.

Why use an intermediate payment layer, can't we just add plugins to our website?

Many small stores are perfectly well suited to using traditional shopping cart plugins. There are simple WYSIWYG (DIY) website builders. Many payment providers provide the ability to set up product lists and plug their shopping cart snippets into your website. Indeed, our own website is doing this at the moment. The difference is being able to decouple accepting payments from your website and therefore ensuring this information is saved off site in more secure manner.

Even small websites can get bitten by the very low server resources capacity offered by their hosting plans.

Another big reason on why to decouple most of the payment processing and content charging from the website is because it is complicated. Many website developers will simply lump more functionality into the website, threatening the stability of the website altogether.

Am not too keen on having a callback firing to my website, are there alternatives?

One option could be to distribute the callbacks against a microservice architecture or cloud based api. This would protect your website and make the endpoint less well known with whitelisting possibilities. We can work with Azure API gateways to achieve this.

System throughput, how many payments could be processed in an hour?

Currently, we are running a single machine. We think we could clear a backlog of 800 payments every ten minutes, approximately one a second. We could scale this out to process more but we have to appreciate we designed this for between 1000-10000 monthly subscribers for a website running without a distributed cache with Redis.

Another way to scale up would be to forget the webhook altogether and poll the payment provider. Be warned, payment providers can rate limit and suspend services. Intermittent checks could help validate payments and reduce the load on your website.

How do you manage the security of the data?

We have taken reasonable steps to only have the data in a decrypted format for as short as possible. Data posted to our Webhook is immediately encrypted and then consumed by our payment processing architecture. We decrypt locally and once validated, this data is encrypted again locally with a separate key. Currently, we salt and hash the payment contact address but will be moving to a zero knowledge gateway where we decouple the email address from the database altogether.

Does this mean we can recover all raw information?

Like much of our data, a large amount of it is off database and archived. We will add reporting to help analyse potential issues as genuine use cases arise. Our software permits decrypting of data.

How long would it take to implement your solution for our business?

This would typically take 2-4 weeks for a client per payment provider.

What may make the implementing the billing solution take longer to implement by Info Rhino Limited?

• If you want API handling implemented
• If your payment provider is a new payment provider
• If you require us to build functionality into your website to handle chargebacks
• Testing and bullet proofing
• Arranging hosting and setting up end points

Written with StackEdit.