Tag Archives: ecommerce

Verifone seems to be having issues processing UK payments

An ‘unfinished’ transaction is when an order ‘has incomplete/delayed/invalid payment details’. For example a payment not completed after being flagged (correctly or incorrectly) as fradulent will be marked ‘unfinished’. Recently I have been getting a lot more ‘unfinished’ transactions than usual through my main payment processor, Verifone[1]. This seemed to be particularly for people ordering from the UK.

I dug down into my table planning software sales data using my own data munging software. Here is what I found looking through data since 2017:

(April results are for half the month. There were fewer transaction during 2020 and 2021 as not much table planning was happening during the pandemic!)

The brown bars show the ‘unfinished’ transaction rate for all countries. The blue bars show the ‘unfinished’ transaction rate for the UK. So my suspicions were correct – there has been a huge jump in ‘unfinished’ UK transactions. In March and April the number of unfinished transaction is about 10x what I would expect historically.

Some of these lost sales I am able to recover by emailing them and sending a Stripe payment link. But it isn’t ideal, as it is a hassle for me, and the customer and Stripe doesn’t handle the tax. But many of these sales are just lost for good.

I emailed some of the prospective customers with unfinished transactions. Here are a couple of responses I got:

“Hi my bank tell me that you are not set up with the new security banking system. That is why my payment is not going through.”

“I was told to ring my bank to ask why the payment was denied. I spent ages waiting for [my bank] to answer the phone and had to answer goodness knows how many security questions before they were able to tell me that the payment company had not updated their software to be on Visa’s list of acceptable people to pay. Something to do with preventing fraud.”

What is going on Verifone? Why has my ‘unfinished’ rate for UK customers sky rocketed? Is it going to be fixed soon? This is costing me time and money. Quite a lot of money. Is anyone else seeing the same thing?

I emailed Verifone on the 11th of March to ask what is going on. I am still awaiting a substantive reponse from Verifone, over a month later. It isn’t the first time I’ve had to send several follow-up emails and wait weeks for a response. Verifone support response times are glacial. Unfortunately great little payment processing companies frequently get bought and become not-so great large payment processing companies. Back when they were Avangate, you would often get a reponse on the same day. I miss those days.

** Update 10-Jun-2022 **

Things got even worse in May, with some 30% of UK customer transactions failings. I kept on at Verifone and I finally got an email on 23-May-2022:

“Thank you for the patience you have shown us during the investigation. Our development team has resolved the described issue and released the fix into the production environment. We have tested it and confirm that the fix is working as intended.”

The rejection rate then went very quickly back to normal. When I asked what the problem had been I was told:

“There was a setup issue with the GBP payment terminal. Our engineers identified and fixed it.”

So I am glad it is fixed. But it took from 11-Mar, when I first reported it, to 23-May, when it was reported fixed. It cost me a lot of time and and money. It must have cost Verifone a *lot* more, Possibly millions in commission for an operation of their scale. You would think they would have spotted and fixed something like this very quickly. But apparently not.

[1] I was originally with Avangate, who merged with 2Checkout and then were bought by Verifone.

VAT basics for software vendors

The dreaded VAT. Ugh. Value Added Tax (VAT) is the European equivalent of sales tax and it is a Royal Pain In The Arse. However, if you are running a business that makes sales in Europe you need to understand VAT. In particular it has important implications for your choice of payment processor, even if you are based outside the EU or below VAT registration thresholds. I have put together a few pointers here in the hope that it will help someone grappling with the complexities of VAT. But please note:

  • I am not an accountant. If you need proper advice, talk to a proper accountant.
  • The VAT rules are complex and may be interpreted differently by different people.
  • The rules may be different in different countries.
  • The rules change over time.

Only VAT registered businesses have to charge VAT. You have to register for VAT once your sales reach a certain threshold. At the time of writing,  UK-based businesses have to register for VAT if their EU sales exceed £77k in a 12 month period (technically it is UK sales, but the ‘place of supply’ for EU consumers is classified as the country of the seller). You can also choose to register for VAT before you reach the threshold. But it usually isn’t worth it, unless perhaps you think having a VAT number is essential for your credibility. Personally I waited until I couldn’t avoid it any longer.

Even if your business is not based in the EU, the EU still expect you to pay VAT on any sales inside the EU once you reach a threshold. This is controversial and it isn’t clear to me exactly what the EU can do to enforce this if you are based outside the EU. Talk to your accountant.

The VAT rate varies between countries. At the time of writing it is 20% in the UK and 19% in the Netherlands. It also varies over time, it used to be 17.5% in the UK.

The UK also has a simplified flat rate VAT scheme with a lower VAT rate. But you can’t claim back VAT on purchases. Worse still, it appears that you will effectively be paying VAT on sales outside the EU. So that doesn’t seem at all attractive.

The VAT rules are complex and depend on:

  • where you are based
  • where your customer is based
  • whether your customer is a business or a consumer
  • whether you are selling goods or services

Technically you do not have to charge VAT to an EU business, even if they aren’t registered for VAT. Apparently they are then responsible for “self-charging” the VAT. However the burden of proof is on you to show that the customer is a business. So most vendors require a VAT number as proof of business status.

There also seem to be disagreements over whether software is goods or services. What if you ship a CD?

Here is a simplified summary in pseudo-code of whether a seller needs to charge VAT on software as I understand it:

paysVAT()
{
    if ( seller registered for VAT)
        if ( customer in EU )
            if ( customer is a business )
                if ( customer in same country as you )
                    return TRUE;
                else
                    return FALSE;
            else
                return TRUE;
        else
            return FALSE;
    else
        return FALSE;
}

Except that people in Norway and Switzerland (which aren’t in the EU) pay VAT in some circumstances. Don’t ask me why. Also you don’t pay VAT on some items, e.g. postage. And outside the scope of VAT (O), not rated for VAT (N) and zero rated for VAT (Z) are all different VAT codes meaning no VAT is payable. As I said, it’s complicated. Not complicated and interesting like quantum mechanics or the love lives of celebrities. Just complicated.

The only upside of being registered for VAT is that you can claim back the VAT you pay on any purchases you have made (make sure you get a VAT receipt). Or, if you are buying from another EU country, you can tell them your VAT ID and they shouldn’t charge VAT (see above). So any equipment you buy in the EU is now 20% cheaper. This is small recompense for the giving 20% of your sales in the EU to the VAT man. Try not to think about that. Instead give yourself a pat on the back for having reached the VAT threshold. A lot of businesses never do.

Note that when you register for VAT you may be able to claim back the VAT of products purchased before you registered. When I registered I could claim back VAT paid on goods purchased within the last 3 years and services purchases within the last 6 months. So keep your VAT receipts.

Congratulations on making it this far. Here is the important bit. How you process payments has important implications for VAT. When someone pays you via a payment processor, such as PayPal, legally they are buying from you and the payment processor is just handling the payment on your behalf (like a bank cashing a cheque). So you are responsible for collecting what VAT is due and paying it to the appropriate government. This can be a major headache if you are selling hundreds or thousands of licences per month.

When you use a reseller, such as Avangate or Fastspring, legally you are selling your licence to the reseller and the reseller is then reselling it to the customer. The reseller is then responsible for deciding what VAT is due, collecting the VAT and doing the paperwork. They then pay you net of the VAT and their commission. Leaving you to sort out the VAT for their one payment to you per month.

Using a reseller is a big win if you are registered for VAT. I am registered for VAT and use Avangate as my payment processor. They do the heavy lifting in terms of calculating, collecting and paying the VAT on my sales. But if you aren’t registered for VAT be wary of using a VAT registered reseller – approximately 20% of your sales will be disappearing in VAT (which the VAT registered reseller has to charge) which you could be keeping if the customer bought from you direct. So if you aren’t registered for VAT, a reseller such as Avangate or Fastspring may not be the best solution for you. Check out e-junkie.

VAT admin is fairly straightforward. To keep the VAT man happy I have to file:

  • an EC sales list every month
  • a VAT return every quarter

My Quickbooks accounting package generates the numbers for these. It only takes a few minutes to file reports online once all the transactions and VAT codes are entered correctly into QuickBooks. The VAT man then debits (or credits) the appropriate amount from my business account each quarter. It is not too bad, as long as I don’t think about the wheelbarrow loads of cash Avangate keeps to pay the VAT man. Maybe they roll around naked in it on the last day of every quarter. I probably would.

When I first registered for VAT I tried adding the VAT onto my existing prices. But I found that sales dropped more than 20%. So I ended up keeping the gross price (including VAT) the same, whether the customer pays VAT or not (Avangate gives you this option). Whatever you do, make sure it is clear whether any prices you quote include VAT. EU consumer expect to be quoted prices inclusive of VAT and won’t appreciate it if you try to sneak on an extra 20% at the end of the purchase process. You may be legally required to quote the price including VAT in some countries.

A final note of warning. The VAT man has a lot of powers. I understand the UK VAT man can kick your door in and seize your equipment without needing even a warrant. He might not be impressed to find out that the computer you reclaimed the VAT for is an XBox. Do not mess with the VAT man.

If I have made any mistakes, missed anything out or if the rules are substantially different in your country, please add a comment.

** Please note that this article was written in 2012. It doesn’t cover changes since then, notably ‘VAT MOSS’. **

Thanks to Marcus Tettmar of Macro Scheduler automation software for checking this through and advising me on some of the finer points.

A survey of ecommerce providers for software vendors

Overview

The choice of ecommerce provider is probably one of the more important ones you make as a software vendor. It isn’t too hard to compare providers by feature set or price. But what about other vital attributes, such as support, reliability, ease of set-up and how they treat your customers? It isn’t realistic to try every provider, so this major decision is often made on the basis of haphazard anecdotal evidence from forums. I created a survey in an attempt to gather some systematic data on the ecommerce providers most commonly used by small software vendors. I present the results below without fear or favour. Skip ahead to ‘Overall ranking’ if you are in a hurry.

Methodology

I posted a request for survey responses on this blog and on a few forums frequented by microISVs and small software companies. Any vendor of software (desktop or web based) not directly affiliated with an ecommerce provider was eligible to take part. Software vendors were invited to fill out a survey form on wufoo.com for each ecommerce provider they had used in the last 2 years. They had to supply their product URL and an email address from the same domain so that I could verify their identity. They also had to check a box proclaiming:

I am a software vendor and I have used this Ecommerce provider in the last 2 years. I have no commercial interest beyond being a customer. (If you have affiliate links to the Ecommerce provider, that isn’t a problem.)

They then had to reply to an automated email from wufoo to the email supplied confirming it was them that had completed the form. If they didn’t reply to the automated email I followed up with a few more emails. Although tedious for me, I felt this was an important safeguard to avoid any possibility of fraudulent entries. I also checked for duplicate entries, duplicate IP addresses and other suspicious patterns. The survey was open from the 5th to the 8th October. Any responses not validated by 10th October were removed from the data.

The data

202 survey responses were received from 166 different software vendors. 9 responses were rejected as I could not verify their identity (they didn’t respond to several emails). 1 response was rejected due to a possible conflict of interest raised by the software vendor (they had done paid work for one of the providers). This left 192 valid responses. I saw no evidence of any attempt to rig the results.

You can download the raw data. It has been stripped of any personal identifying information. Feel free to do your own analysis or check my results.

Providers

The survey listed 14 of the major ecommerce providers, plus an ‘other’ box for providers not listed. Valid responses were received for 25 different ecommerce providers, as shown below:

responses

Note that ‘e-junkie+PayPal/GoogleCheckout/2Checkout’ has been shortened to ‘e-junkie’ for brevity.

Questions

Below I show the average (mean) score per ecommerce provider by survey question. The providers are sorted by score. Providers with less than 3 responses weren’t considered statistically valid and are not shown here (see the raw data for all responses).

Features

“How do you rate the range of features offered, e.g. coupons, support for multiple currencies, CD shipping, affiliate tracking, handling of tax etc.”

5=”Excellent”, 4=”Good”, 3=”Satisfactory”, 2= “Unsatisfactory”, 1=”Dismal”

features

Ease of use

“How easy is their system to set-up, manage and modify?”

5=”Excellent”, 4=”Good”, 3=”Satisfactory”, 2= “Unsatisfactory”, 1=”Dismal”

ease_of_use

Reliability

“How reliable is their service? Does their server ever go down?”

5=”Excellent”, 4=”Good”, 3=”Satisfactory”, 2= “Unsatisfactory”, 1=”Dismal”

reliability

Support

“How good is their support? Do they respond in a timely manner? Are their staff helpful and knowledgeable?”

5=”Excellent”, 4=”Good”, 3=”Satisfactory”, 2= “Unsatisfactory”, 1=”Dismal”

support

Fraud protection

“How well do they protect you from chargebacks and false positives (i.e. valid cards declined)?”

5=”Excellent”, 4=”Good”, 3=”Satisfactory”, 2= “Unsatisfactory”, 1=”Dismal”

fraud_protection

Ethics

“Does this service disrespect you (e.g. by paying you late) or your customer (e.g. by spamming them, adding unwanted items into their cart or making hidden charges)?”

5=”Excellent”, 4=”Good”, 3=”Satisfactory”, 2= “Unsatisfactory”, 1=”Dismal”

ethics

Value for money

“How do you rate their service compared to the cost?”

5=”Excellent”, 4=”Good”, 3=”Satisfactory”, 2= “Unsatisfactory”, 1=”Dismal”

value_for_money

Future

“What is the probability you will still be using this service in 12 months time?”

5= “>95%”, 4= “>75%”, 3= “>50%”, 2= “>25%”, 1= “<25%”

futureThe average score and standard deviation for each question across all providers is shown below:

question_analysis

From the averages software vendors are most happy with reliability and least happy with ease of use. From the standard deviation the least variation is in fraud protection and the greatest variation is in support.

The correlation (R squared) between the likelihood of staying with a provider and the answers to the other 6 questions is shown below:

correlation

Perhaps providers should be concentrating more on ease of use and support to differentiate themselves from the competition.

Providers

Below I show the average (mean) score per question by ecommerce provider. The providers are shown in alphabetical order. The standard deviation is also shown to give an idea of how consistent the responses were (the larger the standard deviation the more variation there was in responses). Providers with less than 3 responses weren’t considered statistically valid and are not shown here (see the raw data for all responses).

avangate

bmt_micro

e-junkie

esellerate

fastspring

kagi

paypal

plimus

regnow

shareit

swreg

Overall ranking

The average (mean) score and overall ranking for providers with at least 3 responses is shown below.

overall

The chart below shows the score broken down by question (click to enlarge):

overall_detailed

The chart below compares the 4 top performers by question:

top_performers

Avangate, Fastspring, BMT Micro and e-junkie all did well. The difference between the Avangate and Fastspring score (approx 0.3%) is probably too small to be statistically significant, but the survey shows significant differences between the best and worst providers. SWREG trails in last place by quite a margin, managing to place last or second to last in an impressive 7 out of 8 questions. It is also noticeable that the providers owned by industry heavyweight Digital River fill 4 out of the bottom 5 places in the ranking. This rather begs the question of how they got to be the industry heavyweight in the first place.

Note that the ranking does not show who the ‘best’ ecommerce provider is, for the following reasons:

  • ‘Best’ depends on your requirements. All the questions have been equally weighted here. If you decide (for example) that good support should be weighted higher than ease of use you might come up with a quite different ranking.
  • The assignment of numerical values to responses (e.g. Excellent=5, Good=4 etc) was done for easier analysis, but is entirely arbitrary. Different values might have resulted in a different ranking.
  • We aren’t comparing like with like. Software vendors using ‘lightweight’ e-commerce providers such as PayPal or e-junkie might have lower expectations than software vendors using ‘fully featured’ e-commerce providers .
  • e-junkie, SWREG, BMT Micro and RegNow had respectively only 8, 7, 5 and 3 responses. They are therefore vulnerable to statistical fluctuations.

That said, the ranking does correlate fairly well with the many comments I see about ecommerce providers on various forums. I don’t think I would want to use any of the providers in the bottom half of the ranking.

Conclusion

While one shouldn’t take the overall ranking too seriously, it is clear that there are major differences in the performance of ecommerce providers in important areas other than pricing and features. I hope these results will allow software vendors (myself included) to make a better informed choice of ecommerce provider. Hopefully this will, in turn, improve ecommerce services overall by rewarding the good companies at the expense of the poorer performers. It would be interesting to run this survey in another year or two and find out what has changed. Thank you to everyone that took part.

Disclosure: I use e-junkie+PayPal/GoogleCheckout/2Checkout as my payment provider for my Perfect Table Plan software. I have an affiliate link to them in another article on this blog which brings me a few dollars a month. I have no other commercial relationship with any of the other ecommerce providers.

BMT Micro
e-junkie
eSellerate
Fastspring
Kagi
PayPal
Plimus
RegNow
ShareIt
SWREG

How good is your Ecommerce provider?

ecommerce surveyIt is important to choose the right Ecommerce provider for your business. A bad choice can have a significant impact on your sales and switching provider can be a major headache. But which one is the right one? It is easy enough to find out about prices and features, but what about the all-important intangibles such as support, ease of set-up and reliability? I hear a lot of good and bad reports about various vendors. I thought it was time for something a bit more comprehensive and systematic – a survey. That’s where you come in.

I hope this survey will provide a useful resource to software vendors looking for an Ecommerce provider and also force the under-performers to raise their game. But I need your help. So please click the link below and tell me what you think about your Ecommerce provider. Please note:

  • You must be a software vendor (web or desktop) and I need your email address and product website to prove this. You will have to reply to an automatic email after the survey to verify your identity. Without this it would be easy to rig the results. Your address and domain will remain confidential and won’t be used for any other purposes.
  • If you have used more than one Ecommerce provider in the last 2 years you can fill out a separate survey response for each one.
  • As there are quite a lot of Ecommerce providers I think I will need at least 100 responses to get a good data set. 200 would be better. So tell a friend.

** the survey is now closed **

results here

A new front-end for e-junkie

e-junkieI am been very happy using e-junkie as my payment processor for the last 4 years. I pay them a few dollars per month as a flat-fee and they provide an interface to PayPal, GoogleCheckout and 2Checkout (and others) plus additional features such as sending licence keys and handling coupon codes. It isn’t a fully fledged a registration service like Avangate, FastSpring or Plimus, but it has been adequate for my needs, has responsive customer support and is very cheap. In theory I could have written a load of scripts to do what e-junkie does, but re-inventing that wheel would be a lousy use of my valuable time.

I had been using e-junkie ‘Buy now’ buttons, but things were starting to get complicated with the branching of my single PerfectTablePlan product into three products: PerfectTablePlan Home Edition, PerfectTablePlan Advanced Edition and PerfectTablePlan Professional Edition.  3 products, each with and without a CD and available in 3 currencies is 18 purchase options, not including the choice of PayPal, GoogleCheckout and 2Checkout as processor. I also had additional options for upgrading version (e.g. v3->v4) and upgrading edition (e.g. Home->Professional). Doing all this through ‘buy now’ buttons was clearly going to be a mess.

I looked at the e-junkie shopping cart, but it had a number of shortcomings I couldn’t live with, most notably:

  • It always shows a coupon field. I don’t use coupons very often. A coupon field says to a customer without a coupon “Someone else getting this cheaper than you – sucker!”. There is a good chance that they will hit the back button and start searching for a coupon (I have done it myself). Maybe they will never come back. I only want the coupon field to appear if I give the user a particular URL, and I will only give that URL to customers who have coupon codes.
  • It always shows the ‘Buy with GoogleCheckout’ button – even if GoogleCheckout don’t do transactions in that currency. So a customer buying in US Dollars can click the ‘Buy with GoogleCheckout’ button, only to be told they can’t buy in dollars through GoogleCheckout. That is a very poor customer experience.

I investigated e-junkie ‘variants’, but these weren’t an adequate solution either. I was loathe to pay more for my payment processing. So I asked my good friend Paul Kossowski, an experienced Javascript programmer, to write me a payment form front-end to e-junkie. My basic requirements were:

  1. Handle multiple products, options and currencies.
  2. Show a running total depending on the product, number and options selected.
  3. Default to a sensible currency, based on the customer’s location from the free maxmind.com geolocation service.
  4. Mustn’t hang if the geolocation service is down.
  5. Make it easy to change prices and product descriptions.
  6. Make it easy to configure options, currencies etc (e.g. GoogleCheckout only allows me to charge in pounds sterling).
  7. Make it easy to change the ‘look and feel’ of the form.
  8. Only show a coupon field if passed an appropriate argument in the URL.
  9. Allow me access to the Javascript source so I can make it call the appropriate e-junkie URL, pass cookies and make other tweaks.

I am very pleased with the results. Here is a screenshot (click to enlarge):

payment form

click to enlarge

You can play with test versions that link through to PayPal, GoogleCheckout and 2Checkout via e-junkie by clicking on the links below (I prefer you didn’t play with my live payment pages, thanks):

Note that some links are broken on these test pages, but the link to the ecommerce providers are live. So don’t type in your credit card number, unless you are feeling generous.

The HTML on these pages includes some simple Javascript that sets up some arrays with the various products, prices, currencies etc. This then calls a separate (obfuscated) .js file which does the real work. An example of the set-up code is shown below:

form_javascript_example

click to enlarge

The look and feel of the form is controlled by a .css file. The resulting form looks fairly trivial on the page, but the .js file actually runs to several hundred lines of Javascript and took a few days for Paul to write and test, partly because of all the configuration options.

I think Paul’s form + e-junkie makes for a very professional looking and flexible payment solution at a very low cost. If you are interested in having Paul customize the Javascript for use on your site you can email him at: paul (at) dolphinfutures (dot) com . Expect to pay for a day or more of his time at UK rates, depending on your requirements.

TrialPay results

trialpayTrialPay is an interesting idea. In basic terms:

  • merchants (e.g. microISVs like me) want to sell products, such as software
  • customers want to get a product without paying for it
  • advertisers (such as Netflix and Gap) want to sell their goods

TrialPay brings the 3 together by letting the customer get the merchant’s product for ‘free’ by buying something from the advertiser. The advertiser then pays the merchant, with TrialPay taking a cut. The merchant gets paid, even though the customer might not have been prepared to pay the price of their product. The customer gets your product ‘free’ by buying something else, which they might have wanted anyway. The advertiser gets a new customer. TrialPay get some commission. Everyone is happy. I decided to give it a try and signed up in October last year.

get_it_free

I decided not to mention the TrialPay offer on my main payment page. I could visualise eager potential buyers of my table plan software, credit card in hand, being distracted by the TrialPay ‘Get it free’ logo. Off they would wander to the TrialPay pages and become so engrossed/confused/distracted by the offers there, they would forget all about my product. Sale lost. Instead I modified my Inno setup Windows installer to pop up the following dialog when someone uninstalls the free trial without ever adding a licence key:

trialpay_uninstall

If they click ‘No’ the software uninstalls. If they click ‘Yes’ they are taken to the PerfectTablePlan TrialPay page. I hoped that this would entice some of those who had decided not to part with $29.95 to ‘buy’ PerfectTablePlan anyway through TrialPay.

TrialPay allows you to set the mimum payout to any level you like. You can also vary the payout by customer country (e.g. less for poorer countres). The lower the minimum payout you set, the more advertisers deals are available to customers (and presumably the higher the chance of a conversion).

The Minimum Acceptable Payout (or MAP) is the lowest amount you are willing to accept per transaction and determines which advertiser offers are available to your customers. The lower the minimum, the more offers that will appear for your product and the more likely a user is to find an offer that compels him to complete his transaction. While you may set a low MAP, your average payout will greatly exceed the minimums you set. (from the TrialPay website)

It quickly became apparent that very few advertisers offer deals that pay the $29.95 I charge for my product (possibly none, in some countries).

trialpay map

I set a minimum payout of $25 in rich countries and $20 in poorer ones. After a few weeks with no TrialPay conversion I reduced the mimum payout to $20 in rich countries and $15 in poorer ones. TrialPay suggested that a $2 minimum payout was optimal in Africa and Central America if I was accepting $20 in the USA. $2? I don’t think so. That doesn’t even cover the cost of answering a support email. Especially if they aren’t a native English speaker.

I also gave the TrialPay option a mention in my PerfectTablePlan newsletter. Most of the recipients already have licences, but I hoped that that they might forward it to friends and colleagues.

The results to date have not been encouraging. Lots of people have gone to the PerfectTablePlan TrialPay page (approximately 1 for every 10 downloads), but the conversion rate has been dismal. The total number of TrialPay sales since I signed up over 7 months ago is two, for a total of $43.60. That certainly isn’t worth the time it took me to sign up, modify the installer and test the ecommerce integration with e-junkie. I am not sure why the conversion rate was so poor:

  • The TrialPay landing page isn’t compelling enough?
  • The advertiser offers aren’t attractive enough?
  • The concept of TrialPay is too complicated?
  • People are suspicious of ‘free’?

TrialPay’s poster child LavaSoft claim an impressive  5,000 additional sales per month through TrialPay. At $26.95 per licence this is an additional $1.6 million per year. But the numbers look a bit less impressive on closer inspection. 5,000 additional sales/month from 10 million visitors/month is only an extra +0.05% conversion rate[1]. And TrialPay probably didn’t pay out the $26.95 per licence Lavasoft normally charge. It is also noticeable that TrialPay only seems to get a mention on the download page of their free product, not the products they charge for.

Obviously the only way to know for sure whether TrialPay will work for you, is to try it. Your results might be very different from mine. If you do still want to try TrialPay, you can find out some details of how to integrate it here [2].

[1]I am being a little unfair here, as the quoted 10 million visitors probably aren’t just for Lavasoft’s Ad-Aware product.

[2]Note there is a bug in some older versions of Inno setup which means you can’t continue with the uninstall if they click “No” when you display a dialog, as shown above. So, if you are using Inno setup (which I recommend highly), make sure you are using v5.2.3 or later.

GoogleCheckout price increase

googlecheckoutIt was always on the cards that Google was going to raise the prices of their payment processing service, GoogleCheckout. Up till now I had effectively used GoogleCheckout for free, as they offset their 1.5% + £0.15 processing fee against my Adwords spending. But they are dropping the Adwords offsetting and introducing a new tiered pricing structure.

As I put most of my payments through PayPal I will probably be on the highest price tier of 3.4% + £0.20 per transaction. This means that a £19.95 sale will cost me £0.88 (4.4%) through GoogleCheckout as opposed to the £0.68 (3.4%) I pay through PayPal. I wouldn’t mind the higher fees if I got a better service than PayPal. Unfortunately GoogleCheckout still has all the flaws I commented on back in April 2007, namely:

  • Google still don’t accept payments in more than one currency (e.g. as a UK resident I can only accept payments in £). Expecting anyone outside the UK to pay in £ is a very bad idea.
  • Delays between customer purchase and payment clearance result in angry and/or confused emails from customers wondering why their licence key hasn’t arrived. This has improved since the early days of GoogleCheckout, but it is still an issue.
  • Google’s option to anonymise the customer email address is a royal pain in the backside for the vendor.  It causes me of lots of wasted time and unecessary emails.
  • The customer *has* to sign up for a GoogleCheckout account (unlike PayPal).
  • There is a £7 chargeback fee (PayPal don’t charge a chargeback fee).
  • Customers prefer PayPal.

About the only advantage of GoogleCheckout is the GoogleCheckout badge that appears alongside your Google Adwords ad. In their email to me explaining the price rise Google claim:

Advertisers who use Checkout have the opportunity to display the Checkout badge on their ads, which has proven to  be an effective way to differentiate ads and attract user interest. Checkout users click on ads 10% more when the ad displays the Checkout badge and convert 40% more than shoppers who have not used Checkout in the past.

My own measurements showed a worthwhile effect from the GoogleCheckout badge, but I am not convinced it is worth the additional problems and expense of GoogleCheckout just to get the badge.

I already push PayPal more than GoogleCheckout (e.g. you have to click a link from my US dollar payment page to see a GoogleCheckout button). The price increases will probably result in GoogleCheckout being pushed further into the background for use just as an alternative for those that don’t like PayPal. I don’t know if Google will punish me by removing my Adwords badge.

Note, in order to continue to use GoogleCheckout from 5 May 2009 onwards, you must login to your account and accept the new Terms of Service between 18 March and 4 May.

Amazon payments

Amazon have launched their Amazon payments ecommerce service. From a quick browse it looks quite similar to PayPal and GoogleCheckout in scope and pricing. It doesn’t say in the FAQ which currencies and countries are supported, so it may only be US dollars/USA at present. I already offer payment by PayPal, GoogleCheckout, 2Checkout and cheque, so I don’t feel any need to be an early adopter of Amazon. I will be keeping an eye on it though and a bit of extra competition for PayPal and Google is welcome.

PayPal vs GoogleCheckout revisited

I wrote back into December 2007 that 70% of my customers prefer PayPal over GoogleCheckout, given the choice. I re-checked the figures today to see if GoogleCheckout was gaining traction with my customers. It isn’t.

% of UK customers[1] choosing PayPal vs GoogleCheckout by month

I’m glad. Despite PayPal’s recent flakiness (since improved) and higher transaction fees[2], I still prefer them as a payment processor due to Google’s confidential email option (which a pain in the butt for support), lack of multi-currency support, chargeback fees and slow processing of many orders. It is useful to have an alternative to PayPal though.

[1] GoogleCheckout only lets me accept payment in pounds sterling, so I only offer it to UK customers.

[2] For a £19.95 transaction PayPal charges me £0.68 and GoogleCheckout charges me £0.45. But Google currently refunds transaction fees for 10x my adwords spend, meaning I don’t pay any transaction fees at all to Google in a typical month.

First charge-back from GoogleCheckout

google_checkout2.gifI have just had my first charge-back through GoogleCheckout. I shouldn’t moan at one charge-back in 8 months use as my secondary payment processor – except:

  • the credit card address was in the UK, the IP address was in the Netherlands and the email address was .ru (Russian Federation)
  • the payment failed authorisation twice, before succeeding a third time

Despite the above, Google apparently just processed the payment automatically, without referring it for further checks. How many Google Phds does it take to write a scoring system that can figure out that this was a suspect transaction? To rub a bit more salt in the wound Google have debited a £7.00 charge-back fee on top of refunding the payment.

I guess Google must need the money.