Coding to handle VAT, and how to do inclusive pricing.

December 22, 2014 at 8:29 PMPhonicUK

If you're an EU business and you want to sell direct to consumers, you're now required to be able to account for VAT, even if you're below the VAT registration threshold that you'd normally fall under.

Those who are selling exclusively through online marketplaces like the Google Play Store, or the Apple App Store probably don't have to worry about this, as they handle calculating VAT for you as well as collecting and paying it. So you don't really need to do anything.

If you're selling to users directly however, and you have your own billing and/or invoicing system that you've built in house (or have modified a 3rd party one), then this page is probably what you want to read.

I'll be going over how to perform VAT calculations in both directions, that is how to add VAT on to an existing price, or calculate the original price if VAT is taken off.

Just for reference, all code samples will be in C# (or pseudocode) - but should be pretty damn similar in Java. Also in code the VAT percentages will always be in decimal format. (20% becomes 0.20M). The decimal data type must also be used, as its the only one with enough precision for performing financial calculations. (NodeJS users take note, this will bite you in the ass real fast!)

First off, before you can do anything - you need to know the VAT rates for the respective European countries, which can be found at (PDF Warning!) - This changes periodically so you need to keep an eye on it.

For the C# programmers, here's that information as something easier to digest:

        private Dictionary<string, decimal> VATRates = new Dictionary<string, decimal>(){
            {"BE", 0.21M},
            {"BG", 0.20M},
            {"CZ", 0.21M},
            {"DK", 0.25M},
            {"DE", 0.19M},
            {"EE", 0.20M},
            {"EL", 0.23M},
            {"ES", 0.21M},
            {"FR", 0.20M},
            {"HR", 0.25M},
            {"IE", 0.23M},
            {"IT", 0.22M},
            {"CY", 0.19M},
            {"LV", 0.21M},
            {"LT", 0.21M},
            {"LU", 0.15M},
            {"HU", 0.27M},
            {"MT", 0.18M},
            {"NL", 0.21M},
            {"AT", 0.20M},
            {"PL", 0.23M},
            {"PT", 0.23M},
            {"RO", 0.24M},
            {"SI", 0.22M},
            {"SK", 0.20M},
            {"FI", 0.24M},
            {"SE", 0.25M},
            {"UK", 0.20M},

Now if you're just sorting out VAT for the first time, you have two options:

  • Make the consumer pay the VAT by increasing the price by the VAT amount.
  • Decrease the 'actual' price so that after adding VAT, it's the original price consumers were paying.
If you're just making the consumer pay the VAT, then the total price is easy to work out:
    TotalAmount = AmountWithoutVAT x (1 + VATRate)
So if the amount of an item without VAT is £10, and your VAT rate is 20%:
    TotalAmount = £10 x (1 + 0.20) = £12
If you've got a total inclusive of VAT, and need to work out what the price was exclusive of VAT, then its backwards:
    AmountWithoutVAT = TotalAmount / (1 + VATRate)
So if we've got a total price with VAT of £12, and a VAT rate of 20%:
    AmountWithoutVAT = £12 / (1 + 0.20) = £10
This incidentally, is the same way you do VAT inclusive pricing regardless of the VAT rate. You use the total you'd like the customer to pay as the TotalAmount, and the VATRate for that users particular country to get the price you actually 'charge' them for the product or service.
I'll write a separate blog post about generating proper VAT invoices in an automated session at another time. I can tell you however that you don't need to go and buy an expensive PDF authoring library if you want to generate nice PDF invoices for customers to print. Instead you can write yourself a HTML template that you populate, and then use 'wkhtmltopdf' (which uses the webkit engine under the hood) to produce nice PDFs. More on this later, but that's something to play with.

Posted in: C# Development


How did we get here?

June 16, 2014 at 6:17 PMPhonicUK


How we got here

When it first started looking like server administrators were no longer going to be able to charge players for in-game items or bonuses, the first question that was often was being asked was “How am I going to support my server that costs $xxx/month to run?”

Initially my reaction was fairly unsympathetic - that if you couldn’t afford to run your server without donations/selling items, you couldn’t afford to run the server at all – and that while this revenue was nice, it shouldn’t be something the server relies upon to survive and that those that did depend on it were simply too big to operate and should downsize.

But then I started thinking about what caused this situation in the first place. Why do we have such huge servers and networks capable of sustaining hundreds of simultaneous users all at the same time?

At first it seems very counterproductive. You may be able to fit 200 players on a server, but should you? Adding more players to a server is going to cause diminishing returns. A 200 player server isn’t going to be significantly more fun than a 100 player server, and that’s not going to be much more fun than a 50 player server – simply because there is a limit on how many people you can interact with at the same time. Granted a 20 player server is almost certainly more fun than a 10 player server, but there is definitely a point at which adding more players stops adding any value.

Almost every game I play that has dedicated servers, I find myself a regular on maybe 3 or 4 different servers since a lot of games max out at between 16-32 players, if one server is full you simply join another.

‘Why doesn’t this apply to Minecraft?’ I thought to myself. But there’s a huge difference between Minecraft any many other games. One Team Fortress 2 server is much like any other. The map rotation might be slightly different and there may be some extras, but there isn’t a right lot tying you to any given server (other than its community) – you can just as easily drop yourself into another server and enjoy yourself just as much.

The difference lies in the creative and deeply personal nature of Minecraft. A given server has your stuff there. The things you’ve made, the caves you’ve explored, and the home you built for yourself and your friends by investing time and effort. And that’s before getting to meta-games within Minecraft where players complete quests and acquire resources.

This ties players to a given server much more strongly than almost any other game. There is something to be lost by going to a different server.

What this causes is a pressure on server administrators to allow more players at the same time, because players become frustrated if a smaller server is full all the time thus denying them their existing work and wasting their invested time and effort.

This is the point that I think has been overlooked. The demands of the player base (due to the nature of the game) are in conflict with the realities of running a server. So the only solution was to fund server growth.

Moving Forward

When dealing with a younger audience, micro transactions are a very attractive way of raising funds from both the customer and the vendor’s perspective. For the customer, it means something very quick with instant gratification, and no long term commitment. For the vendor, it means they can get revenue from a very large number of users, some of whom may be simply passing through never to visit again – keeping the payments very small for instant rewards allows this to happen.

What server owners have been told however is that they can only charge for either cosmetic items that don’t affect gameplay or for access to the server.

The unfortunate impact of this is that excludes any kind of ‘casual’ revenue generation as both of these require building a relationship with a particular server.

At a glance this seems ideal, due to the issue I mentioned earlier of the way that player’s attachment to their ‘property’ on any given server. And I’d largely agree that this is the way to go.

My concern is that players won’t contribute financially to servers that require payment in order to play so long as there are other servers available that don’t. Those servers will be smaller on average, but the question that this will answer is how much financial value do players place in their creations? Will they pay in order to stay where they are, or will they abandon their efforts and move elsewhere?

Closing Thoughts

Ultimately, I do think the solution is for there to be a larger number of smaller servers and that the days of 100+ player servers are very much numbered.

The technical problem that needs to be solved is how to keep players in contact with their in game properties.

One solution I think could work well is effectively a rolling whitelist with a queue. A server where anyone can join the queue to be on its whitelist, and players lose their whitelist slot if they don’t play on the server for more than a given amount of time (say 14 days) – this allows people to stay attached to their content without costing the server from inactive players being on the whitelist and denying new revenue opportunities from new users.

Ultimately though the community is going to have to re-think how servers are being paid for, how big they are, and what kind of communities they’re going to build. The two polar opposites are small servers with a very tight, very regular community of users – and very large servers with a casual user base that drop in and out with great frequency.

In this new environment, the latter is almost certainly unsustainable. But what remains to be seen is how far along that spectrum you can go and still have a viable server.

Posted in:


McMyAdmin licence migration plan.

March 10, 2014 at 3:44 PMPhonicUK

After many months, the new CubeCoders software licencing system is built and running. The new system offers a number of benefits:

  • No more dependencies on email addresses for the licence. You'll be able to switch email address much more easily in the future.
  • The server ID no longer needs to be requeried each time McMyAdmin starts up.
  • Proper invoicing facilities, with nice printable PDF invoices for your records.
  • Better key tracking and management. You'll be able to see how many remaining usages you have on each licence you own.
  • Greater licencing flexibility. It means we'll be able to have a wider variety of licence types to suit different users better.
The next stage is getting everything moved over to using it. With nearly 200K users, this is a difficult task.
So the migration is going to be done in stages, the current plan looks like this:
1) Dual Licencing
The first step is to release a version of McMyAdmin capable of handling both the new licences and the old ones, and that can continue operating just using a 'legacy' licence. During this step the old style licences will continue to be issued.
2) New purchases moved to new system.
Next is to have all new issued licences switch to being issued by the new system. This will be done a couple of weeks after the dual-licencing release to allow for the gap between downloading McMyAdmin and purchasing a licence. Old style licences will continue to be valid.
3) Automated migration of legacy licences to 'modern' licences.
After that the legacy licences will be automatically converted to the new style. This will trigger emails being sent out to everyone affected over a period of time with the new details in. McMyAdmin instances with valid licences will automatically collect their 'new' licence from the licence server without requiring any user interaction. During this stage the legacy licences will still be valid in the event that McMyAdmin cannot contact the licence servers due to the increased load.
4) Termination of legacy licences.
Once all licences have been moved over to the new system, another version of McMyAdmin will be released without the legacy licence system and will only run or activate with a 'modern' licence.
5) Mandatory update to 'modern' licence version.
About six weeks after the modern-licence only version of McMyAdmin is released, a mandatory update notice will be sent out to older versions. In addition, the legacy licence server will report a licence failure to all remaining legacy instances.
Other notes:
  • Anyone who has a free or complimentary licence will need to contact CubeCoders to request a new licence to be generated. These licences will not migrate automatically.
  • Enterprise hosts will be required to fill in a short form to migrate their licence. This is only done once for the whole licence (not per-instance) to collect information such as business type and VAT registration numbers (if applicable)
  • Linux users may have to install a new binary to update when the time comes, but all settings will remain.

Posted in: McMyAdmin


WinRT standard text styles previews.

August 19, 2013 at 11:22 PMPhonicUK

Perhaps the biggest irritation of developing for RT (or doing anything with XAML in general) is dealing with styles. There's no way to see a list of all the default ones, or the ones you've made yourself that are available in the current scope. You have to remember them, resulting in lots of tedious back and forth.

Here's the standard RT ones just dumped. They all have a margin of 8 added to space them out.

Posted in:


Email issues and missing keys.

May 28, 2013 at 2:56 PMPhonicUK

We've been having an issue with our mail server, and some licence keys have been lost as a result.

If you've recently purchased McMyAdmin, and do not receive your key by 12:00 GMT 29/05/2013 (Wednesday) - please do the following:

- Visit

- Enter your paypal email address and select "Find Licence"

If after doing that you *still* don't have your licence within an hour of doing that, use the contact form at with a subject of "NOKEY" and we'll send it to you by hand.

Note that the key recovery page linked above isn't usable until the day after your purchase (the transactions are processed in the early morning)

Apologies for any inconvenienced caused. We hope to have the issues resolved before the close of play today.

Posted in: McMyAdmin


McMyAdmin Personal restrictions to be relaxed.

May 21, 2013 at 12:25 PMPhonicUK

Starting in June, I'm planning on relaxing some of the restrictions on the Personal edition of McMyAdmin.

Changes include:

  • Increasing the player limit from 8 to 10.
  • Increasing the panel user limit from 1 to 3.
  • Removing the limit on the number of worlds for multiworld configurations.
  • Only showing the "This server is running McMyAdmin Personal Edition" notice upon user login instead of every 30 minutes.
The following new restrictions will apply:
  • The Remote Assistance feature will be restricted to McMyAdmin Pro and Enterprise.
McMyAdmin is going to start shifting in the direction of including additional value-added features to Pro users such as integration with 3rd party services, and encouraging a higher level of uptake of Personal edition.
Please note that the exact changes are still subject to change without notice.

Posted in:


McMyAdmin to undergo external penetration testing.

May 17, 2013 at 10:38 AMPhonicUK

At some point during this month, McMyAdmin is going to be subjected to external penetration testing by a specialist security firm here in the UK.

It will be tested for issues including potential authentication bypasses, XSS attacks, session spoofing/hijacking and other issues that could compromise security for hosts or end users.

Once complete, McMyAdmin will be the only Minecraft control panel to have undergone professional security testing for the benefit of its users.

While there are currently no known vulnerabilities in McMyAdmin, the purpose of this exercise it to make absolutely sure. Security is no accident.

Posted in: McMyAdmin | Security

Tags: , ,

Proposed McMyAdmin Extension development guidelines.

April 30, 2013 at 11:51 AMPhonicUK

McMyAdmin is moving more towards the point that part of its strength will be in the extra features provided by 3rd party extensions provided by other users. This of course naturally points things in the direction of a 'extension marketplace' where people can distribute extensions.

Whether or not they could be charged for is an interesting question, since they are simply HTML and Javascript and thus very easy to reverse engineer. However MCMA is able to provide signing and verification to prevent people using extensions they aren't allowed to (to some degree) - however in the immediate term, its likely that the initial release of such a market would have all the extensions being free.

So that in mind, there would be some sense in having a set of guidelines for what Extensions should or should not do in order to provide a good user experience.

Below is a first draft of the restrictions. Comments are invited by users and developers.

Extensions must (mandatory)

  • work on Internet Explorer 9 (or newer), Google Chrome and Mozilla Firefox as a minimum with equal functionality on all 3 browsers (exceptions may be made for bleeding-edge technologies such as WebGL)
  • warn the user before deleting or modifying any user data (such as permissions)
  • store user configuration using the extension configuration APIs and not via any other means.
  • not modify the McMyAdmin control panel outside of their own designated tab.
  • not permanently store any sensitive data (such as usernames, passwords, ip addresses, etc)
  • not use javascript or HTML included from external sources (all used code and markup assets must ship with the extension itself)
  • not manipulate any of McMyAdmins existing functionality.
  • not use obfuscated source code. All extension source should be human readable.
  • not attempt to replace the version of jQuery loaded by McMyAdmin

Extensions should (strongly advised, but not entirely mandatory)

  • conform to McMyAdmins overall look and feel (using the same CSS classes) where possible.
  • avoid using 3rd party services outside of the developers control.
  • not modify McMyAdmins own settings without notifying the user that it is about to do so first.
If you have any comments about the existing proposed rules or would like to suggest some of your own, you may post them below.

Posted in: McMyAdmin

Tags: , ,

Everyone should be just a little bit ruder.

April 28, 2013 at 10:54 PMPhonicUK

I've always thought the world would be a better place if everyone was a bit ruder to each other.

Just to clarify on that, I don't mean discourteous or impolite - what I mean is not sugar coating criticism to avoid making the other person feel bad, and that people should not be afraid to tell someone when they've done something stupid or to make fun of an individual for being incredibly dense.

At the moment when someone has been stupid, it's hard to call them out for it without looking like an ass. When an answer to a question is just a quick search away, then it seems entirely reasonable that people should be chastised for not using the tools available to them. However if you point someone to a LMGTFY (Let Me Google That For You) link - the smugness that comes with it would largely prevent the recipient from being open to the (passive) criticism.

If it were the case that criticism of this kind were much more widespread, it seems plausible that people would stop taking it personally - and we could all go around telling everyone else that they are idiots.

Because we are all idiots, every single one of us on this Earth is an idiot one way or another at some point.

But I do worry that some people seem to drift through life unaware of this detail, and need reminding of it.

Posted in: Ramblings


McMyAdmin to be owned by CubeCoders Limited

February 26, 2013 at 11:59 AMPhonicUK

This is a move long overdue, but finally it's happening.

Last week I started the process of moving my business operations to run as a fully fledged limited company here in the UK.

The final switch over will happen on the 1st of April this year. Meaning that at that point, all McMyAdmin related licences and contracts will move to being with myself to being with CubeCoders Limited.

Among other changes that are going to go along with this, all existing McMyAdmin Pro and Enterprise licences are being reissued either on or shortly after April 1st.

This will also trigger a mandatory update in McMyAdmin to change to using the new licencing server. Those with existing entered keys should find that their licence key is automatically swapped over without any intervention on their part.

Part of the move to the new licencing system is to no longer tie licences to email addresses or Paypal accounts to make them more flexible.

All existing licence keys will remain usable for a number of months after the changeover to give people time to migrate - but there will be a point at which old licence keys cease to be usable. There will be measures in place to help people recover lost keys if they have not managed to migrate by that time and the automated systems are unable to assist.

All in all this should be a largely transparent and painless transition, with many long term improvements once everything is done and dusted.

Posted in: McMyAdmin