How to Build: Non-custodial Cryptocurrency Payment Processor

What do we want?

A custodial cryptocurrency payment processor is one where an entity’s users pay the payment processor, and then the payment processor (hopefully) pays the entity. A non custodial cryptocurrency payment processor is one in which the money goes directly from the user to you, with no middleman in-between.

Why do we need it?

There are many reasons one might not want to use a custodial cryptocurrency payment processor.

1. They all charge fees and those fees are pretty steep.
2. They may choose to blacklist your users because the payment processor is operating in a jurisdiction that requires them to do so, or because they are just having a bad day.
3. They may not have as good of operational security as you, and at the least their security practices are entirely opaque to you. A sufficiently bad compromise could cause them to go underwater and be unable to pay you.
4. Many of them require your users sign-up with them separately.
5. Users usually are redirected away from your website to make payment, rather than being able to make payment inline on your site.
6. The payment processor has full insight into the accounts that are paying them, but this may be opaque to you so you get access to less data.

For these reasons and potentially more, it would be valuable if a business could operate their own payment processing and host it on-site rather than off-site through a service provider. Unfortunately, integrating with blockchains is a somewhat complex task and requires specialized knowledge/understanding, and simple errors can lead to catastrophic loss of funds. Doing it all right is expensive, and everything should be heavily audited which a small firm cannot afford.

How do we get it?

Hungry young developers wanting to make a name for themselves within the cryptocurrency and open source communities.

At the end of this article I have left an outline of the basic components of this system. Consider the idea public domain and anyone who wants to can implement this without even giving me credit, I just want to see this exist in the world. Any hungry young developer or team could run off and implement these components and it wouldn’t even be all that much work. I think for a senior set of engineers it is maybe a 1–2 years project from start to production including audits and the like. You could get a prototype out on test networks probably in a few months.

How do we make money?

Since this is a non-custodial service, it means anyone can run the software. Since it *should* be open source (important for auditing and credibility within the ecosystem), you can’t reasonably make money by selling the software itself. So how does one turn this great idea into a get rich quickish scheme?

Option 1: White glove service and support. You can publish this software open source, and then sell 24/7 support and integration services to enterprise customers who will pay big bucks to have a professional available to be on call when the have problems and to help them get the software integrated into their existing systems. While for may aspiring developers it seems strange that this could possibly be a good way to make money, but take it from an industry veteran that there is *huge* amounts of money down this path. Just having an engineer on retainer (available to be called on for help/support 24/7) alone can easily be 7 figures… for a single client.

Option 2: Managed hosting. Some of the system requires operating backend servers including cryptocurrency nodes. While all of the source code and documentation will be public, you should never be surprised at the volume of people who don’t want do the work themselves. You can offer to run all of the software for them in exchange for a flat monthly fee. As an example, Discourse (the forum software) has this model and they are doing just fine financially. Despite the fact that anyone can run their own discourse servers, most people don’t want to!

Boring Architecture Details

This section is for someone interested in actually building this thing. Feel free to stop reading here if you don’t actually care.

Server Component

The server component runs in the client’s data center and is what connects to the supported cryptocurrency nodes (Bitcoin, Ethereum, ZCash, Doge, etc.). When a user wants to make a purchase, they would first request an invoice from the server which would give them a price quote (based on third party price data feeds) and save that invoice in a local database. The user would then pay the invoice, including the invoice ID in the “memo” of the transaction (specifics here differ by blockchain, in Ethereum for example this would be a contract call with invoice details). The server would constantly be scanning for payments and when one was found it would call a callback to the client’s delivery infrastructure indicating the payment was completed successfully.

The server would also supply an endpoint for querying the status of certain invoices (in case the client wants to poll instead, and for troubleshooting purposes).

Finally, the server would provide a mechanism for querying for invoices that were paid to late so users could be refunded (a manual or separate process, since you don’t want this server holding private keys).

Most of the work for the server component is likely in the integration with various blockchains. You want to maximize your reach so you want to support as many blockchains as possible, but each one requires at least a little bit of customization. At the very least, you probably want support for Bitcoin, Ethereum, and a privacy coin (my personal favorite is ZCash). Once you have those, integrating others should be much easier as *many* blockchains are more or less clones of Bitcoin or Ethereum.

JavaScript SDK

Along with the server component, you will want a JavaScript SDK that your clients can drop into their website. This should have a handful of different renderings and be easy for the client to theme to match their site. Functionally, its primary purpose is a “buy now” button that when clicked will request an invoice (quote) from the server with the user’s currency of choice and then connect the user up to their wallet for final payment.

For something like Ethereum, this would integrate with the various types of wallets out there including browser plugin, mobile, QR code, etc. and for Bitcoin and similar it may be a bitcoin:// scheme handler, a QR code, or a Bitcoin payment URL.

The JS SDK would also make it easy for the UI to gain access to current exchange rates so prices can be presented to the user in their preferred currency, and there is probably a widget for choosing the currency of choice.

The Rest

Of course you’ll need a database integrated here as well, and maybe some adapters so you can integrate with the client’s database of choice easily including SaaS DBs like from AWS/Azure/GCE. You also likely want to build another server component for refunds, but since this would require key management it should be isolated from the rest and as tiny/simple as possible.

For v2 you could extend the offering by providing tooling for automatically converting the received cryptocurrency into one the user doesn’t mind holding (perhaps a stable coin). You could take it a step further and integrate with various exchange APIs for automatically converting to and withdrawing fiat.