
[[This is Chapter 21(a) from "beta" Volume VI of the upcoming book "Development&Deployment of Multiplayer Online Games", which is currently being beta-tested. Beta-testing is intended to improve the quality of the book, and provides free e-copy of the "release" book to those who help with improving; for further details see "Book Beta Testing". All the content published during Beta Testing, is subject to change before the book is published.
To navigate through the book, you may want to use Development&Deployment of MOG: Table of Contents.]]
As it was mentioned in Chapter I, more likely than not your game will need some kind of monetization. And when speaking about monetization – we need to discuss payment processing.
These days, most of the time, you won’t process credit cards directly (leave alone “processing it directly with a bank”). We’ll come to all those alternative methods a bit later; however, to understand the other ways of payment processing, we’ll still start our discussion with credit cards.
Credit Cards
Credit card processing is a subject which has a very scarce coverage (even less so in programming books); the whole thing is not exactly secret (it is not really possible to keep it secret when so many people know it) – but rather it is not publicized. Ok, here it goes – your crash course on “how credit card system works”. Disclaimer: these are just my personal observations – and while they certainly were valid in quite a few scenarios, rules and procedures can potentially differ from one country to another one, and even from one bank to another one – and change in time too, so make sure to take it with even-larger-than-usual pinch of salt.
Card Not Present, Subscriptions, No Micro-Transactions
First of all, let’s define what kind of CC processing we’ll be doing. 99% of time, when speaking about online games, we’ll be discussing over-the-Internet transactions; these are known as “Card not present” transactions – and these tend to carry significantly higher risks for the banks – which means LOTS of headaches and costs for you as a merchant too 🙁.1 Moreover, within “card not present” transactions, pretty often banks recognize a subset when it is only digital goods which get delivered – and these are often considered even worse (i.e. more risky) than Amazon-style or phone order “card not present” transactions 🙁.
if your neighbor has opened a merchant account for his restaurant in a jiff – it doesn’t mean that you’ll be able to do the same thing for your online game
It is certainly not fatal – and a lot of businesses are doing it too. What I mean is that if your neighbor has opened a merchant account for his restaurant in a jiff – it doesn’t mean that you’ll be able to do the same thing for your online game 🙁. In the same manner – if you see a site offering payment processing for low fees – make sure to double-check if these rates apply when working with card-not-present transactions with no physical goods delivered.
Optionally, you may also want (depending on your monetization strategy) one or more of the following things:
- If you want to use subscriptions – it needs to be communicated to your merchant bank (see below) in advance; keep in mind though that mentioning it may reduce chances for them to open your merchant account 🙁 .
- Micro-transactions. As a rule of thumb, banks do not recognize the term “Micro-transactions” – all the transactions are equal for them, and carry the same per-transaction costs. It makes micro-transactions (usually those below $0.5-$1 or so) economically unviable – and usually puts them beyond traditional card processing.
- if you cannot live without micro-transactions – you’ll probably need a special micro-payment provider ☹️. Still, make sure to read the rest of this section on CCs – it will introduce quite a few concepts which are applicable pretty much across the board.
Merchant Accounts: a Big Headache for over-the-Internet processing
In the old days of CC processing, everything was plain and simple. If you want to process credit cards – you need to find a bank (or a reasonable facsimile2) which is willing to open you a so-called “Merchant Account”.
In practice, opening a Merchant Account often happens to be a Really Big Headache for a startup business aiming to process over-the-Internet transactions, especially without physical goods delivered 🙁 – and apparently, even worse for games 🙁🙁
It means that
If you’re going to go this way – make sure to (a) start approaching banks as early as possible, and (b) have a “Plan B” in case they refuse.
Two further things to keep in mind:
Bank policies in this regard vary A LOT. It means that if approaching 10 banks – it can easily happen that you’re turned away (with “are you crazy?” or even “should we call the police right now?” looks on their faces) by 9 banks, and will be met with open arms by the 10th
if approaching 10 banks – it can easily happen that you’re turned away (with 'are you crazy?' or even 'should we call the police right now?' looks on their faces) by 9 banks, and will be met with open arms by the 10th - Quite often it is your over-the-Internet payment provider that can help you with opening such a merchant account (they just happen to know which banks are familiar with this kind of processing).
1 note that term "high risk" is normally reserved for really-high-risk stuff such as online porn, online pharmaceuticals, and gambling, so most of the time your merchant account won't get that dreaded "high risk" status; on the other hand - card-not-present over-the-Internet transactions are still considered higher risk than classical restaurant-style credit card transactions with a card slip being signed
2 in particular, in Europe CCs may be issued by other financial institutions, though for all the our purposes they're pretty much the same as banks
Merchant/Acquiring Bank and Issuing Bank
A tiny bit of further terminology. Whenever transaction happens – it happens between you and your paying customer. However, in addition to you (“Merchant”) and customer “Cardholder”) – there are also two banks involved. “Your” bank (the one which has opened your Merchant Account) is known as a “Merchant Bank” or “Acquiring Bank”; Cardholder’s bank (the one which has issued the credit card) – is known as an “Issuing Bank”.
Life Cycle of a Credit Card Transaction
Usual database transaction can be only in three states - "in progress", “committed” or “rolled back”; with CC transactions, things are much more complicated. In general, a typical CC transaction can go through the following stages:
- Pre-authorization. At this stage, money do NOT change hands (yet), it is just blocked/reserved for specific merchant on the credit card account (the one of the Cardholder, and sitting within the Issuing Bank)
- If you’re buying/selling something outright – pre-auth is usually combined with “settlement” (see below)
- If pre-auth is not followed by “settlement” within some pre-defined time (such as 30 days) – it is rolled back automatically.
- Originally, pre-auth was intended for hotels (so a hotel pre-authorizes some amount “just in case” if you’re taking something from mini-bar etc. etc.). However, pre-auth MIGHT be usable for other purposes too (YMMV, batteries not included, depends on your Merchant Bank).
- Settlement. This is the point when money DOES change hands (at least from legal standpoint).
- As noted above, settlement can be based on a previously issued pre-auth. In such cases – as a rule of thumb, amount of settlement cannot exceed the amount of pre-auth (but it MAY be smaller). Of course, to have a larger amount than original pre-auth, you can make a separate transaction – but then you’ll need a separate authorization from your customer.
Portion of the settlement funds being kept in Rolling Reserve. While, in a sense, the money from the settlement can be considered “yours”, you won’t get all the money from the settlement right away. It is a common (or maybe even “universal”) practice used by Merchant Banks, to keep a portion of your settlement money in “rolling reserve”. It means that some percentage (like 20%, though these numbers vary greatly) of your transactions settled in January will be very likely held by your Merchant Bank until July or so (YMMV, but 6-month rolling reserves are pretty common). The rest of the money (like 80%) is usually released to you right away at least in theory (in practice though, unfortunately "at the end of the month next after current one" is not that unusual 🙁).
While, in a sense, the money from the settlement can be considered “yours”, you won’t get all the money from the settlement right away. - The official reason for bank to have “Rolling Reserves” is to serve as their protection against “chargebacks” (more on them below). Unofficially though, there is a second reason – that banks are making money on these reserves. On the other hand, whatever the reason is – most of the time, the existence of Rolling Reserves in non-negotiable (though if you’re processing enough transactions – percentage and term can sometimes be negotiated).
- After the settlement, there are still two things which can happen to the transaction:
- Refund. This happens when you’re voluntarily refunding money for the transaction (with the difference from Chargebacks below being “voluntarily”).
- Most of the time, refunds CANNOT be larger than original settled transaction.
- On the other hand, they MIGHT be usable for other purposes3 than simple refunds.
- Chargeback is a very nasty thing; it happens whenever your customer files a complaint with their bank (Issuing bank for the transaction) that “such and such transaction was not authorized by me”. Chargebacks have LOTS of nasty implications – and is to be avoided at all costs. More on chargebacks in [[TODO]] section below.
- Release of Rolling Reserve. This is the point when you’re finally receiving the remainder of your settlement money. Usually (though not necessarily) it more or less coincides with the point in time when chargebacks from your customers become impossible.
3 such as paying some kind of winnings; note though that this is a very difficult legal problem, leading to a crazily complicated world of sweepstakes and lotteries. Make sure to get very solid legal advice long before doing anything like this.
Every Merchant’s Nightmare: Chargebacks
Chargeback monster will come from under the bed and will eat all your hard-earned money!
Ok, now we’re about to discuss the thing which is the most feared among merchants (especially online merchants); yes, I’m speaking about chargebacks. It is feared in merchant world that bad that the stories you’ll hear will sound like “Chargeback monster will come from under the bed and will eat all your hard-earned money”. Let’s take a closer look at this monster lurking in the shadowy corridors of CC processing.
Chargeback Mechanism
First, let’s discuss a typical mechanism of the chargeback:
- Cardholder receives her CC statement and sees a strange item on the list
- That’s why it is so important to have a name of your business – and not some intermediary or your-company-legal-name-nobody-really-knows-about - in your credit card transactions! Otherwise she might have simply misidentified your transaction, causing that dreaded chargeback.
- She calls her bank (Issuing Bank). The first thing they will normally tell her – is a question: “hey, did you call the merchant to try sorting it out?”
- That’s why it is so important to have your phone number in your credit card transactions – and have somebody answering this phone number too!
- However, if the Cardholder just says her bank “sure, I did call them 3 times already and nobody answered” – it is usually enough to let her go to the next step
- Issuing Bank accepts the complaint from the Cardholder (usually in writing)
- Issuing Bank sends the complaint to the Acquirer Bank
- Acquirer Bank comes to you (Merchant) and asks “hey, do you have any proof that this transaction did take place?”
- If you’re doing card-not-present transactions without physical goods delivered – at this point you’re in trouble.
- Usually, you MIGHT be able to contact your customer (hey, you have transaction ID, and should be able to find out their e-mail) – and try to remind him that it was indeed him doing the transaction. This MIGHT work (especially if you manage to help the Cardholder to recognize their transaction) – or it MIGHT not.
- If you (Merchant) don’t provide any proof – the chargeback is automatically decided in favour of the Cardholder (and you can be losing MUCH more than just a chargeback itself, see [[TODO]] section below).
- If you (Merchant) decide to go for chargeback dispute – then your proof of transaction usually goes back to your Acquiring Bank, then to Issuing Bank, and then to the Cardholder.
At this point, if you manage to satisfy Cardholder with your proof – things are ok; other than that (i.e. if Cardholder still insists that the transaction is fraudulent) – well, your chances become Really Slim :-( .
At this point, if Cardholder still insists that the transaction is fraudulent – well, your chances become Really Slim - Some time ago, going beyond this (i.e. disputing chargeback any further) was almost-perfectly hopeless for digital goods.
- Since the end of 2015, however, rules have changed a bit in favor of digital goods merchants. However, these changes don’t seem to apply to games :-( (at least those rules I’ve seen, YMMV greatly).
- Overall – you MAY try disputing, but TBH – don’t expect to get much out of further chargeback disputes for games.
Heavily Skewed in favour of Consumers. Honest Mistakes
[[TODO: discuss why it is a Right Thing for the whole payment ecosystem]]As a Big Fat Rule of Thumb,
the whole chargeback process is heavily skewed towards Consumers and against Merchants
A real-world example to illustrate it. Once upon a time, a friend of mine told me the following story:
- He received his CC statement – and found a strange charge coming from some not-really familiar restaurant
- He disputed the charge via his Issuing Bank – and got a proof from the restaurant, a scan of their payment slip with his signature (the proof went all the way described above – via both banks – but eventually landed with him)
- He didn’t recognize his signature, told his bank about it – and was promptly refunded.
That wasn’t the end of the story though. A bit later, he was walking along the street and DID recognize the restaurant. He was there – and did sign that payment slip too.
He was there – and did sign that payment slip too. - A contributing factor (and a pretty bad one at that) was that the restaurant settled its transaction like 3 months after the dinner had happened.
- why the friend of mine didn’t recognize his own signature – I have no idea; my wild guess is that he was overindulged which changed his writing enough to become barely recognizable 😉.
This whole story was an ultimate example of an Honest Mistake (sometimes also referred to as “Friendly Fraud”). And the key lessons we can learn from it would be: what can we (as Merchants) do to reduce chances for it happening? It is more or less along the lines mentioned above:
- Making all the charges right away (well, for online games it will be quite difficult to do it any other way)
- Making it VERY clear on the CC statement who we are. It MUST be the same name we’re using for doing business (and NOT some obscure name of the company which nobody has heard of, neither a name of intermediary).
- Providing a phone number on the CC statement.
- Include as much information as possible into our chargeback reply (in hope that it will reach our customer – and chances are really high that it will).
Penalties for Chargebacks. Reasons behind
You can get much farther with a kind word and a gun
than you can with a kind word alone.
— Al Capone —
Now we can answer the question of “why chargebacks are that bad for merchants?”. The problem with chargebacks is that
Not only you will pay money back, but also there are heavy penalties for chargebacks
Usually, with credit cards, if the number of your chargebacks starts to exceed some pre-defined percentage of your transactions (usually – 1.5% or so4) – you will be fined (heavily), or in more extreme cases, your account can be closed🙁 .5
To the best of my knowledge, the reason behind such harsh penalties for chargebacks goes back to 1970s. At that point in time, there were a few merchants using a fraudulent schema with charging everybody in existence for small amounts ($10-$20), just because they were able to do it technically. If the person complained – they refunded without question, if not – they pocketed the money.
This outright fraud was so easy to mount (and so difficult to prove in court) – that VISA has apparently decided to eradicate it completely by making it economically unviable.
This outright fraud was so easy to mount (and so difficult to prove in court) – that VISA has apparently decided to eradicate it completely by making it economically unviable. Heavy penalties for chargebacks achieve exactly this – they’re not supposed to affect honest merchants, but make the fraud itself non-profitable; this has been observed to be a much better disincentive than merely running after frauds and putting them into jail.
As a side note – this story provides a good lesson to be learned for game-related anti-fraud/anti-cheat teams: if you can remove (or at least greatly reduce) the incentive to cheat – it works really well to combat fraud/cheat/abuse.
4 usually, it won't apply until you have enough transactions to get any meaningful statistics, but make sure to check it - and the thresholds - with your bank. Also make sure to figure out when exactly the chargeback applies to your percentage - probably it will happen at the moment of receiving chargeback - and not at the moment of original transaction, so if your game is subject to seasonal variations, it can become a problem :-(
5 as we’ll see below, for other payment methods penalties can differ – but in any case the penalties are stiff.
Even if you’re perfectly honest – there WILL be chargebacks
BTW, the magical number of 1.5% I mentioned above, is not zero for a good reason. This is because
However honest you are and whatever steps you’re doing to prevent honest mistakes – you WILL have chargebacks, plain and simple.
Some people will still make honest mistakes, and some people will be frauds – there is no way around it.In addition to the story about an honest mistake above – here goes another one, from a surprisingly different field, but leading to about the same conclusion. This very blog has a mailing list (yes, that envelope on the left side). The mailing list is managed by mailchimp, is double-opt-in, we’re sending e-mails only once a month, and they’re as unpromotional as they go (usually it is just a digest of posts for the previous month). And still, among those 16 unsubscribes we’ve got over last year – there was one marked as SPAM, and one marked INAPPROPRIATE CONTENT (oh, really?). My only comment about it is that
..it happens
In exactly the same way, whatever you’re doing – you WILL have chargebacks. The difference is only in numbers of chargebacks you have. On the other hand, these numbers are Damn Important – at least for the reasons discussed above. It is difficult to discuss the exact numbers (they depend too much on specifics of your game) – but usually, you should at least try to aim at whatever_chargeback_percentage_which_starts_fines / 2.
[[TODO: 3D Secure, Verified by VISA, etc.]]
Refunds instead of Chargebacks
whenever you’re sure that chargeback is coming – try to issue refund instead.
Due to those stiff penalties for exceeding percentage of chargebacks – the following tactics often makes sense: whenever you’re sure that chargeback is coming – try to issue refund instead.
Unfortunately, it is quite difficult to predict chargebacks. However, there is one important case when such a prediction becomes kinda-possible. It happens when you have a bunch of transactions from the same credit card – and you get chargeback (indicating that it is a fraud) for the earlier transaction. In this case, most likely all the further transactions will be also charged back, so you have nothing to lose if you try to refund them before they reach chargeback status (so you have a chance to avoid those chargeback penalties). AFAIK, this is a relatively common practice in the industry; however, as any other practice - its efficiency depends on fine details, so be careful not to abuse it.
Fraud prevention: Chargebacks vs Collateral Damage
With all those negatives which come as a result of chargebacks, it is only obvious that 3rd-party vendors came up with lots of “fraud prevention” systems and software. Most (if not all) of these systems are working by pre-filtering transactions, and rejecting them outright without even going to the bank, if they feel that something fishy is going on. Sure, if there was indeed something fishy for pre-filtered transaction – you’re winning by pre-filtering it (by not allowing that transaction-which-would-be-a-chargeback to happen in the first place); on the other hand, if you’re turning away a perfectly legitimate customer – you’re losing her business.
For a long while (until about mid-2000s) such “fraud prevention” systems were competing using just one metrics – namely, reducing the percentage of chargebacks further and further. After going in this direction for a while, it has naturally come to the point where these systems were rejecting much more transactions than it was necessary. These perfectly legitimate transactions fell victims of “collateral damage” caused by developers-who-were- checking-for-whatever-they-were-able-to-think-as-suspicious – and filtering all such “suspicious” transactions out.
I remember these really gloomy days of credit card processing, when merely having a credit card from across the board (though just 10km away) was sufficient to get your transactions blocked.
I remember these really gloomy days of credit card processing, when merely having a credit card from across the board (though just 10km away) was sufficient to get your transactions blocked.6 OTOH, some of the more-smart-companies (with an Amazon being one of the most prominent examples) were very lenient about whatever-the-others-considered-too-risky – and won significant business because of it.
Fortunately, about 10 years ago a Really Big Revelation came to payment processing industry, and an understanding was achieved that
it is not only chargebacks which matter – but rather a balance between the chargebacks and the card decline rate.
Still, there are some companies out there (notably Apple) which feel that paying them is a privilege, and employing all the kinds of the “fraud checks” (including outright silly ones) to make the life of their customer more difficult. On the other end of this spectrum – there is Amazon, which is still among the most customer-friendly merchants out there (at least payment-wise 😉). In this battle for customers, I clearly bet on Amazon.
BTW, I certainly do NOT mean that all “fraud prevention” is pointless; to the contrary – you certainly DO need some. Moreover, we’ll even discuss some of DIY techniques for CC fraud prevention in Vol.3, tentatively Chapter [[TODO]] (and BTW you’re actually in better position to do it rather than any 3rd-party system too).
On the other hand – rejecting each and every transaction which matches some obscure rule which one-of-your-developers-thought-might-indicate-fraud – is a surefire way to lose transactions and customer loyalty too.
it is trivial to develop a system with guaranteed zero chargeback rate – to achieve this, it is sufficient to decline each and every transaction at pre-filter stage
As a result – if you see “fraud prevention” vendor which boasts about their minimal chargeback rates (without mentioning decline rates), it is usually better to look elsewhere. In fact, it is trivial to develop a system with guaranteed zero chargeback rate – to achieve this, it is sufficient to decline each and every transaction at pre-filter stage (without going to the bank). However, while such a “guaranteed zero chargeback rate” may sound really nice in ad materials, I have my doubts that this is what you really want as a merchant.
6 it happened at the point when "fraud prevention" guys have learned about BIN tables and Geo IPs, and didn't think of anything better than simply comparing BIN-based country to an IP-based one; we'll discuss more sensible ways of doing BIN- and GeoIP-based fraud prevention, in Vol.3 (TODO)
[[To Be Continued...
This concludes beta Chapter 21(a) from the upcoming book "Development and Deployment of Multiplayer Online Games (from social games to MMOFPS, with social games in between)". Stay tuned for beta Chapter 21(b), where we'll discuss technical issues regarding to payment processing.]]











Comments