Thursday, 17 March 2016

What do you need to know about taking online payments?

Well, the last few weeks have been an eye opener for me as I have been trying to work out what is most cost effective way to take credit card payments online. I learnt a lot. The short answer is that I will use Stripe but some explanation is needed.

I searched for Credit Card Payments on Google and found a number of companies. One of them, Charity Clear, seemed reasonably priced and they donate their profit to charity which is fantastic. I would be a fool not to use them for my charity website. I was almost about to sign up and then something in the documentation hit me:

"You require a Merchant ID in order to use this system, which can be obtained from a Merchant bank account" - or words to that effect.

Hmm. We have a business bank account so let's contact the bank. Nope. Business Bank Account is NOT equal to Merchant Bank Account. Merchant Bank Accounts cost money, not just to open but you pay a transaction charge on them too. Eventually, when I priced this into the equation, the cost was really quite high compared to someone like Stripe so I wondered why we needed the Merchant account and how Stripe (and Paypal although slightly less so) could charge less money for their services.

Clearly, money transfers entail risk and require trust. A credit card company is not going to give you money just because you give them a bank account number. A merchant account is basically a bank account with some additional checks that occur and which prove to the credit card companies that they can trust you are a real business entity and not just a hacker. Of course, they do nothing of the sort since credit card fraud occurs all the time but that is the justification and why they charge you money. The payments gateway is simply the mechanism that captures credit card information, does some checks and then requests the Merchant account to actually transfer the money from the credit card company to the destination bank account (although delayed - of course!).

The reality is that in the modern age of micro-payments and small business, Merchant accounts are really just another way to earn the banks money but because you don't have a choice except to have one, you can't really do anything about it. Or can you? This is where the aggregated Merchant account comes in with companies like Stripe and Paypal.

The logic of the aggregated Merchant account is simple. Instead of creating one account per company, which is time consuming and expensive, why not create one massive one and anyone who uses Stripe or Paypal has the funds transferred into the big pot and then transferred out later. A bit later than a normal account (usually 7 days) but the larger pot enables Stripe to manage the risk of charge-backs and other fraud and gives them slightly longer to withhold funds if a problem occurs. Because there is only one account, the cost of managing it is much smaller and that cost is owned directly by the payment gateway. They can therefore charge you one fee (usually a small amount + a percentage), which in our case was around 50% of the cost of a dedicated Merchant account.

So are dedicated accounts useless? Well, they do allow you to get your money sooner and if you are a large customer, you could negotiate your rates to be lower. You might also write your own payment gateway and not have to pay for that so there are potential savings - although for us small people, a dedicated service like Stripe or Paypal is often cheaper and more convenient.

There is one last thing to consider and that is PCI. Any site that handles payment card data MUST conform to PCI standards. They are not law but they are a requirement for Visa, Mastercard, Amex etc. PCI is about security and has things like firewall requirements, coding requirements, encryption requirements etc. In most cases, it is not a place you want to go to unless you specifically deal with financial software and have the expertise. The audits and compliance can be very expensive and this is another area where a good payment gateway (including Stripe and Paypal) can help you out.

The easiest way to be compliant is not to touch the data. Some gateways allow you to simply redirect to their site to take payment and you never see the card details. This is OK but doesn't give you any customisation options. Some will allow you to host your own payment page but then you require PCI checks because you theoretically have access to the card data.

Stripe give you two options and they get the benefits of both extremes - Stripe-hosted but still customisable! The easiest but least customisable is called Checkout. It is simply a button that is drawn by a script you load from Stripe. You can customise some basic stuff like the title and logo image but otherwise it generates you a pre-designed card entry form, hosted by Stripe and where the data is sent directly to their servers. You are given a token and it is that token that you then use to take payments or setup a recurring charge or whatever. The second is called Stripe.js and uses a similar trick to allow you to create and style your own form but in a certain way which allows Stripe to pick out the values, sends it directly to them and gives you back the same token. The only requirement is that your site uses https, which is a small price to pay for this functionality.

So if you are a small merchant, I would recommend a complete payment solution like Stripe or Paypal (there are others too) and make sure that when you look into what is available, you work out whether they are integrated or whether you would also need a Merchant account. Check out the pricing too and try and estimate some income so that you can work out whether a higher transaction and lower percentage is more cost effective than a lower transaction and higher percentage charge.

Tuesday, 15 March 2016

Do airlines not understand their customers?

Some companies seem to survive only because they provide an essential service or because out of a small number of alternatives, they can do it more cheaply but many do not seem to consider how a customer will arrive at their site and what they will do next.

Hotels are one of these (with, I think, very similar problems) but I will pick on airlines.

The general view of an airline site is clutter and noise. There are too many options and I'm pretty sure that 99% of the time, I am going to their site either to enquire about a possible flight or to make some kind of update/check-in to an already booked flight.

I went to a particular airline site (which I won't mention - but most are the same) and the first thing I notice is 6 top-level menu items including - confusingly - 3 that are similar: book; vacations; travel info but then down the side there are tabs: book a flight; book a vacation; rent a car; book a hotel; As well as some others.

Already I am confused but let's stick with it. I know they are low cost and I will fight past the confusion to try and find a flight from London to Halifax. This is where airlines really lose the plot and where it is obvious that they design a site based around their systems rather than around the customer.

One of the problems for people like me is that there are about 50 airports around London, all called London Something and not all sites allow you to select "London (All)". Heathrow is much easier for me to get to than somewhere like Stanstead or Luton to the point I would even pay more to go from Heathrow. In this case, they only fly from Gatwick so I don't even have that problem here.

What I want to ask is very simple: What kind of price are flights from London to Halifax in, say, June time. I can't ask this question, in fact, it takes a while to even work out where this airline flies from and to. If you go to Air Canada's site, you can download 1000 page route timetable just to work out when they fly from where to where.

Anyway, I guess I can just choose two random dates in June and pick London and Halifax and see what I get, that should be close enough to get an idea right? I put in the "from" and "to" and then some dates in June (Sunday to Saturday) and then click search. Now, what would be nice here? What would be nice would be the grid that some sites have which shows you prices either side but nope. This site shows you the classic "there are no flights on these dates".

What now? What would be very useful is some more information. Perhaps, "flights between London and Halifax only run during July and August", perhaps, "There are no flights for these days (because we don't fly on Sunday) so how about these alternative days?" How about, "These are some example other fares of other flights near these dates so you can choose the cheapest"? Nope. Nothing, just the error. Why? Because they have geared the site around a web service that takes specific dates and returns results or nothing if there are no results. Their web site should cater for that, but it doesn't.

OK, I still haven't left, I really want to know. Oh look, there is a random link I have just noticed elsewhere on the page which says, "cheap fare finder for flexible dates". It would have been nice to see that on the front page underneath the main booking area but let's go for it. "Please select origin" - hmmm, no option to choose London, it seems that this only applies (for some reason) to flights starting in Canada. No headline saying that though. Could I book a fake return and then a single to get a cheap return from the UK? Maybe but at this point, I have given up, I won't book this company even if they are half the price of a major carrier. Why? Simply because I couldn't do what I (and I suspect many others) want to do.

Yii2 code works locally, doesn't work in production

Another annoying experience, which fortunately didn't take forever to fix (although out of luck probably rather than skill).

There were in fact two problems: 1) Captcha didn't work and 2) An email utility class didn't work. They were different issues but both worked locally and not in production.

Firstly, the captcha didn't display and there was an internal server error. I didn't think to look in the application log, which might have shown something useful, but fortunately I found the same issue on the Yii forums and realised that the problem was uploading the font for captcha in Text mode rather than Binary. I think text mode changes line-endings automatically but if the file is binary, something that looks like a line ending will be changed and in this case, broke the font! Reuploaded in binary and it was fine.

The second problem was really confusing. The email utility class worked fine locally and I got the error 'Class 'common\utils\EmailUtils' not found' in SiteController. What? The class was definitely there, definitely uploaded in text mode and it worked locally! I check the bootstrap.php in common\config and that was present (that's how the frontend and backend can find the common classes).

Eventually, I twigged, the class is EmailUtils and so it would be expected to be found in EmailUtils.php rather than emailutils.php, which is what I had uploaded. Renamed it - worked! Why did it work locally? I develop on Windows and it doesn't care about the case of file names! I understand why case is the way it is in Linux - A is not the same as a - but I still prefer Windows way. Why would you want to allow File.php and file.php to exist in the same folder?

Now I'm getting a SQL error - but that is another story....