TLDR;

I wanted to understand crypto payments, and created an online game and separate merchant service (taking care of user accounts / registration / logins / funding / withdrawals) which is the back end powering the experimental slot game at https://www.coinmachin.es/ . Feel free to give it a spin and tell me what you think.

I'll share my experiences diving into the issues with becoming an online BCH merchant, including some highlevel background and then diving gradually into more technical challenges.

Here's a screenshot of the running game. At the end of this article you can find screenshots of the account management pages, both front end (customer facing) and back end (merchant administration tool).

Why?

I've spent my whole life writing software for various industries. Two and a half decades ago I founded one of the early online payment companies in Norway. At that time, the challenge was convincing the local banks and their local VISA and MasterCard affiliates that not everybody that wanted to do business online and get paid was not thieves and swindlers. Infrastructure was sorely lacking. The first payment gateway I wrote basically collected the transaction details from the merchant and then popped a payment window on top of the merchant's website. The collected cardnumber and details would never actually go to the merchant. Infrastructure was also sorely lacking. There was almost zero infrastructure from the banks and card companies, so in the first version of the service I actually had to push transactions using phonelines, dialing into banking infrastructure that thought they were talking to their own terminals. Business was good, until VISA and MasterCard in the US decided that outside of the US, they would not allow "PIN less" transactions. They also invented some other tech where customers would be required to "drop by" their bank at the time of online purchases, effectively making recurring payments and one-click shopping impossible. I decided to get out of that business.

But anyway, despite the challenges at the time, online payment are simple in principle. You need an amount and details about who should receive the payment (the merchant) and from whom (the customer). Over the last few years I've been following crypto currencies a bit passively, before I decided to go a bit deeper and see what it might take to become an online BCH merchant. I wanted to understand the finer details about how everything works. Some people believe payments are the killer app for crypto currencies, others believe the killer app might be something else, even something we haven't invented yet. My personal take is that regardless of that, unless crypto currencies are usable for payments, it will not be successful long term.

What kind of merchant?

My first entry into payment services a few decades ago wasn't a coincidence. I had been working with a computer games company where we were writing online games that we needed to get paid for. Massive multiplayer games essentially, which meant monthly subscription fees. So we needed to collect and store payment details (or something representing those) that we could push to card companies/banks every month until customers stopped subscribing.

So how would this work with crypto? Today you can not do that with crypto. Yes, I've read papers about protocols and contracts that may support subscriptions or one click purchases. But as far as I know, these are proposals and mostly experimental at this point in time. In crypto, you need to actively contribute to every payment using your wallet at the time of purchase. "Not your keys, not your coins", assuming you haven't given away your keys, you are the only one who can access your funds.

So I wanted to investigate how one could set up a merchant system that supports subscription services, pre-payments or similar, where it would be possible to charge customers without actually requiring them to whip out their crypto wallet on every transaction. So these could be services with lots of micro payments, which is typically considered "spam" by most blockchains, and which for many blockchains are considered to expensive to be practical.

Surely there are many services like this already?

Maybe. I haven't found any. Most crypto payment services I've seen so far support the simple shopping cart / checkout pattern. I'm not saying those are useless. But I wanted to understand more of the finer details, and also how more complex payment patterns like I described would work. If you DO know of crypto payment merchant solutions that DO support subscription payments and/or account based pre-payments or similar, feel free to enlighten me (and anybody else reading this article).

I'll make a slot machine and a merchant service supporting it

Being a software developer and entrepreneur (and former game developer and merchant solution developer), I needed a good test case. A slot game should be a simple game, and hitting the blockchain for each spin would probably piss off a lot of blockchain users. It would probably also make each spin prohibitly expensive (minimum amount would be high). What I need is a system that supports "player accounts" and the ability to "fund" and "defund/withdraw" from those accounts. Then the slot machine service could charge "spin transactions" off blockchain by simple accounting (each time you spin, an "I owe you" goes from you to the house, and the other way around each time you win).

A slot machine is easy? Yeah, in theory. For a game developer with some attention to detail, probably not. Let's just say it took some time (all this is a side project btw, I have a real job). So first I had to learn how modern slot machines work. Then there's the math and probability theory. We also need some nice graphics. And physics of course, they need to spin! And sound effects. As I said, it took some time.

So what about payments?

While making the slot machine game, I also worked on the payments side. How hard could it be? I've looked mostly at Bitcoin, so for this project, Bitcoin Cash/BCH was a good fit. So how does a payment actually work with BCH?

Payments between two parties are simple. Both have a wallet. Wallets generally have the ability to issue a payment address, which can be shared with anybody who want to send you funds. For manual payments between two parties or simple "cash register" style apps, there are lots of nice free stuff out there already. Roger Ver and his company at https://www.bitcoin.com have done tons of work making this simple and easy. Check it out if you have not already.

But selling physical items to be paid at the cash register doesn't equal an online merchant.

Online Merchants

One of the challenges online merchants need to tackle are user accounts and figuring which payments represents which customer. If I buy something at a physical store that accept BCH for payment, this isn't a big problem. The store has a wallet that receives the funds for all customers, and generally the need to match individual payments to individual purchases is either not that important, or it can easily be deduced by when a transaction was keyed into the cash register and a payment of the same amount shortly after. I might be simplifying this a bit, it's not the primary use case I'm looking into anyway.

The use case I am looking into is the ability for an online merchant to accept funding and withdrawal requests to/from "customer accounts" at the online merchant. This would support things like subscriptions services, pre-payments and micro transactions (considered too small for blockchains)

Based on my experience so far, this is quite a bit more complex than just accepting payments from one wallet to another. So how could this be solved?

One wallet per customer?

I believe a naive approach to solve the one merchant many accounts problem would be to have one wallet per customer. When a customer puts money into his account at a merchant, money is transferred from his wallet to his wallet hosted my the merchant (which the merchant typically controls 100%). This will probably work fine, but it also means keeping track of a lot of wallets for the merchant. It typically also means all transactions moving money around inside the merchant would be blockchain transactions. They don't have to, but things would probably get very complex very soon if we have to reconcile payments from external wallets to internal wallets, and then internal off chain transactions as well.

There are some other things to consider as well. Without going into too much details, modern crypto wallets are basically software handling crypto keys (which are used for generating payment addresses and access to coins/funds). These wallets have some ways of handling key generation that developers of merchant solutions need to understand. Every time you want to receive some funds into a wallet, you typically generate a receiving address. For privacy reasons, it's considered bad practice to re-use receiving addresses, as it makes it a lot easier for others to track you and the merchant's spending habits. After you have generated a receiving address, your wallet will typically "listen" for payments to that address. So it will "scan" the blockchain for funds being sent to that address, and alert you when it finds funds. But what will you do if no funds can be found? Will you keep "scanning" that address forever? Will you stop "scanning" that address as soon as you receive funds on it? What if the user sends more funds into the same adress later (which is perfectly "legal")?

You need to understand how this works at a detailed level if you want to develop such merchant solutions. There are even more challenges. If you use some random server side wallet that somebody else wrote for handling wallets for your customer accounts, do you understand how address generation for that wallet actually works? Are you are of the typically 20 address gap limit will affect your service?

Anyway, I don't believe one wallet per customer is a practical solution for such merhcant solutions, and that there are better ways. The reason I'm babbling about this is that while most developers of merchant solutions probably understand how they typically work (take an invoice id, amount and payment details and send it to Stripe), you need to understand a lot more if you are planning on writing merchant solutions for crypto merchants. I believe it's actually a bit counter intuitive. Crypto is supposed to be so easy, right? Well, the base case (payment, one to one) is very easy. But the rest is not. But the good thing is the only thing holding you back is your technical skills and studying ability. At the very least you do not need to kiss card companies and banks' asses any more.

A better approach

I'll share more details about what I consider a much better approach than the one I described in the previous chapter in a followup article..

Screenshots from the game account management page (front-end), and the same from the back end.