How to accept crypto payments securely 08 Dec 2022

Welcome to our article on handling payments and improving website security

If you wish to find out more about our platforms, high technology, and products that we are working on at the moment - including the fantastic platform crypto statto, drop us a line here at www.inforhino.co.uk/contact

We specialise in .net/dotnet development, business intelligence with multiple database platforms, OLAP technologies, and we build significant solutions for our own commercial initiatives.

We are more than happy to reduce costs by partnering with clients interested in what we discuss here.

Authentication and registering

The process of signing in and registering

I won't list all the tables but just a key overview of how it works.

Registration

• User registers by adding one or more email addresses
• User receives the emails.
• Once all email confirmations are verified, they are a member.

Signing in

• User adds their one or more email addresses to the signin page.
• User receives the emails.
• Once all email confirmations are verified, they are signed in.

Signing out

User simply clicks sign out. Once completed, relevant tidy ups happen.

Forgotten details

The user is provided with the option of entering an email address. If that email address matches, they will get sent an email of all the addresses that account is registered under.

Understanding why the security process has been designed as it has

• No storing of passwords inside the database
• No physical identifiers inside the database all encrypted or hashed
• Multi factor authentication. Users can add multiple e-mail addresses and their boy have e-mail accounts on different devices acting as a multi factor authentication mechanism. you could have an e-mail address on a mobile that was Google and your PC that was Hotmail for example.

It is worth highlighting that we could include other types of protocols such as SMS passwords block chain login et cetera This is why this has been built as it has been.

The significance of this process from the perspective of the website

The website never really needs to know about the user aside for matching a member to an e-mail address .we therefore don't try to capture personal identifying information. The user session and cookie are therefore anonymous and we simply match the member ID to the database equivalent to find their e-mail address when appropriate.

Extra thoughts on security and questions

• We need to make sure that the member ID is not stored or made available numerically anywhere on the website it is believed that we use one of the authentication or validated signing tokens. So we need to confirm that.
• We need to ensure that anybody who could gain unwanted access to the physical website server folders cannot use information in various configuration to decrypt all of the user information.
• We are considering having a separate repository that contains information which is pushed only for a user this would allow transactional information to not be available to the website.
• We're currently thinking in terms of users that pay for access to online services paying in terms of a term such as X days X hours that type of thing. It is likely this will be a separate library or even web service.

Protecting user data - thinking about Data Protection and GDPR

Rather than thinking about gdpr in terms of its focus on data controllers, data subjects, data processors, we prefer to think of it in terms of - how do we limit the ability of hackers and third parties to get to underlying data? One way to do this is to separate information into several different locations. So we can store information against a key in one database that may have sensitive information in there. In a separate database we can store the personally identifiable information - still encrypted. In the third system we can store the transactional information. This would be a good and relatively well protected system. It is important that we don't have all data access security information in one single application. where possible information should be stored in a need to know basis and processed behind the scenes and only provide back confirmation and basic details on what has been undertaken.

To recap;

1. One repository that contains Content management related information.
2. one repository that contains user related transactional information.
3. one repository that contains enough of the personal identifiable information but in an encrypted fashion.

Further considerations for security

The personal information should only be accessible via a gateway/API and should only return IDs. The application and database for the security information should be separate.

Two-factor and multi-factor authentication

We are now presented with a very important security benefit. a typical dictionary attack involves bombarding a server or API with any e-mail address and lots of passwords most websites have policies to not allow this to happen. interestingly if you had two or more e-mail addresses and one of these e-mail addresses was a very obscure 1 the chances of providing two or more e-mail addresses that matched an already registered user seems to be nigh on impossible. now imagine that we had say a private key from a blockchain which wasn't even known to the user or 8 mobile phone number this becomes even more secure. Taking this further what's to stop us allowing an independent website where these users sign up with this multi factor identifiers and they can then tap into this service in a similar fashion to oauth.

The current state of our web data platform with the step to protecting users information

Currently is agnostic to business domain information. We can plug in JavaScript and HTML content this can go to separate services we do currently stored encrypted user security tokens within our database we are looking to move this off database to a separate server as our platform grows.

Payment handling how we think we will get users to pay for our services in a secure way that protects our own business longevity

Our upcoming cryptocurrency platform is going to be phenomenal. Info Rhino's web data platform will provide access to reports and information for users wanting to understand more about the market. Our goal is to provide access to cryptocurrency market data and insights. We are currently in the process of architecting and developing a process for users to pay for access to reports and other services such as upcoming API in a manner that is not only secure but that doesn't run the risk of penalties from payment providers.

Without giving away too much of the detail as this is not relevant to the discussion at this moment in time, but also that we have not fully conceptualised how this will work. For this reason, this is not much more than a sounding board.

Payment Handling for online sales - thoughts and options

Payment Providers

Those outside of the cryptocurrency space are faced with two main mechanisms for receiving online payments.

1. A merchant account via their business banking.
2. A payment provider that that's a great way to a bank.

The main challenge with payment providers is not only the hoops we need to jump through to be able to use them, but also chargebacks and customer queries.

Crypto currency payment handling

Conceptual overview

When a payment is made using a cryptocurrency the process is as follows;

1. The customer users the wallet to send money to a separate public address.
2. A while later if not fairly instantaneously, this money is received in the recipients wallet.

Cryptocurrency payment handling in slightly more detail

• The customer logs into the blockchain wallet using their seed phase
• The customer enters an amount, a reference, and the recipient's public key (wallet address)
• The customer makes the payment, The wallet signs that transaction with a private key.
• After n blockchain confirmations, the recipient's public key shows an amount credited to their account/address.
• After monitoring the blockchain the recipient discovers the payment and can then allocate access to the online services.

Which one will we use?

We may be forgiven for thinking that we should go with the merchant accounts or payment provider approach it sounds simpler. In principle though there are some definite benefits to using cryptocurrencies;

• We have no need to try and store the payment details of our customers. This is a win for security and PCI compliance.
• The user does not add any private details to their website. This is secure.
• We just focus on the reference attached to the payment, once received the user has access.

At this point you may be saying, "What is so exciting about that? I can set up a payment through my bank account to go to a third party." The key difference is it is far faster and has far less scrutiny by banks and other providers, this isn't to highlight that cryptocurrencies can be anonymous but more to focus on the fact that it is more hassle to set payments up through a bank account.

It seems to be a nobrainer to use cryptocurrencies instead of going via a bank account for online payment handling.

What are some obvious drawbacks to using cryptocurrencies for online payment handling?

• Monitoring blockchains to check for payments
• Customers accidentally overpaying. Imagine we were asking for a payment in Bitcoin that was 0.01 Bitcoin, and for some reason the user gave us one Bitcoin. They would want their money back.
• Customers underpaying when they thought they overpaid.
• Price volatility in light of potential refunds. This is a big problem isn't it? There could be price slippage in terms of fees and big movements in the value of the currency compared to Fiat.

How will we implement payment handling for crypto statto platform on top of our web data platform?

This is a high level overview of how we may look to implement payment handling using cryptocurrencies within a platform. We have two choices;

1. Use a crypto currency exchange in a similar fashion to a payment provider. We can have a callback/web hook. we still may need some monitoring.
2. Offer payments on a few blockchains and handle this ourselves.

The first sounds easier but we need to understand this in more depth. We will consider possible applications that may be needed.

Products, services, contract terms application

Our data mainly exists on disk and get pulled into the website. This data appears as tabular reports, maps, charts, dashboards, and articles. We configure folders at different levels to be mapped to products and services. We have created a mechanism to permit mapping of the disc reports to our package products and therefore pricing. We detailed payment terms. The objective is to ensure we can manage payments against like for access to their resource is on the website.

Website authentication and authorization - Website Security Application

Whilst our website currently has security built into it we would eventually have a gateway application that would handle this. The future solution would be a separate web service that accepted the relevant tokens and return a token key that can be mapped to a user. we may decide to manage the lifetime of this key and instance on the website security application.

Payment application

Initially this will be a separate library referenced by the website application. a future version would be an API application. this application would link to the products and services application, plus would reference valid users via a token. Feature of this service would be too monitor different blockchains for transactions mapping them to users to allow referencing applications understand if payments have been made. It would make sense to have a webhook also to allow any payment providers to make a callback.

Finishing up on security , authentication, authorization, payment handling, article on access to resource is that users have paid for

Mitigating risks

The number of risks to any application in terms of feeling secure and accurately handling payments is significant. Thanks, credit card issuers, online shopping stores, employ teams to help manage inconsistencies in payment handling and investigate fraud. no informal agencies are also on hand to try and understand where payments have been inappropriately applied.

Many risks, some possible ones;

• Unauthorised server access

• Keys, tokens, passwords on configuration folders may provide hackers enough information to read payment details , or worse still the accounts/wallets

• It is possible that intelligent hackers could replace libraries with their own versions, sending payments to a different route altogether. Against reboot we would need to keep a track independently of users accessing resources which are on a premium subscription, versus checking blockchains for payments - effectively a reconciliation.

• Corruption

• if databases can be got to then hackers could simply try to corrupt information stores making it hard to link information up. What would the benefit be in doing this? One benefit could be simply to just cause problems for a company. For this reason regular backups would be the right way to go. With my old say want to store keys completely independent of any applications where possible and to ensure that any links to private keys it help completely off any servers.

No single answer to solving these challenges

This article has only been a process in thinking through from a high level how they may want to handle payments through a website. What we need to balance as a software development company the needs both companies wanting to receive payments, and the security of their customers. The most important thing is to not over engineer this in the short term. The most important goals seems to be;

• Making decent attempts to not store user passwords and sensitive information on our website
• Not providing access to our private bank account/wallet address
• Performing a reconciliation on our services purchased versus our wallet quantities
• Not over-engineering the solution in the short term

Thanks for reading