Scirra_Tom

Not an expert but I'd be surprised if one trade like that triggered anything, could easily be a hedge.

There's a couple of other points here as well:

- If you do enough volume, you're able to negotiate the fee with the payment processor, we've done this successfully. If you outsource, that negotiation is the third parties margin.

- I'm not sure if this is true for third parties, but if they wrap up all your payouts in your native currency (EG GBP£), you lose money on forex. We try our best to have all our EUR and USD sales land in their respective currency accounts, then convert them with low cost services such as transferwise which has saved us a lot of money in the long run.

Saving on your forex and having no third party processor fees, I think in some instances you could be saving in the region of £40,000 to £80,000 per £1mm of sales.

We also couldn't find a third party implementation that would allow us to bill for our product, varied by country, amount, currency AND billing frequency. This fine tuned control can have real benefit, for example we noticed in Ukraine we had high traffic but no sales - by introducing a low monthly UAH billing option we started to grow sales in this region.

Other third party implementations won't handle VAT properly or comprehensively which can create more of an accounting burden, or round VAT transactions unfavourably (size of that benefit is irrelevant to very small obviously depending on volume of transactions!) This gap is being slowly filled from what I've been seeing though.

Using a third party solution for SaaS will always have some level of disconnect, it just feels nicer for the customer when it's all integrated seamlessly. One example being you have full control over branding and distribution of invoices/receipts etc.

One example is that some currencies have 100 subunits (eg USD), some have 10 subunits (EG TWD/MOP) and some have no subunits (eg JPY). This is made slightly more difficult in that Stripe/Paypal will treat subunits differently, for example Paypal might treat JPY as having 100 subunits and Stripe will treat it with 0 subunits.

You want to be really careful here not to charge 10x/100x more/less to the end customer than you imagine.

Formatting currencies is also something you need to do carefully as dots and commas mean completely different things in various countries and can lead to unexpected charges for customers.

Don't get me started on VAT :P

All worth it in the end though, I enjoy writing this sort of thing and I do see long term benefit to our business that we do it all in-house.

I'd also recommend future proofing implementations to use longs instead of ints for storing money values. Back when Bitcoin was less valuable we allowed BTC as a currency where 1 subunit = 1 satoshi (100,000,000 satoshis in a bitcoin). It was possible to overflow an int this way.

You also can't really write payment systems with the speed you might write other code in your startup - errors and mistakes here could have real impact on peoples lives. For example, loops that create charges that don't end (possible with both Stripe AND Paypal). Loops can manifest themselves as lock collisions as well. Basically, be careful and if speed is important you probably want to outsource it at the expense of some control.

Looks like they had aspiration to IPO earlier in 2019, imagine this would now not be on the cards for a long time.

I wonder how much the ransom is for. It appears to be an enormously damaging attack - I wonder if paying it is the best option for their business at this stage, then follow the money.

As our engine Construct 3 is written in HTML5 itself, Javascript was the natural language choice to integrate with our block system.

All languages have their up and downsides but we love Javascript and think it's suitable because it's used in many industries (not just making games) and is likely to have a growing demand going forwards. I think this is a much easier sell to education than other tools such as Gamemaker who use their own propitiatory language.