PayPal? No way!

Minifree used to accept payments via PayPal, but since 7 December 2015, Minifree no longer accepts payments via PayPal. PayPal is evil.

Minifree accepts payments via wire transfer (SEPA, SWIFT, BACS – direct bank to bank transfer), and has done so for some time now. This payment method has proven to be rather popular with our customers already; it is now the only option on the Minifree website.

We are philosophically opposed to PayPal and all credit/debit card payment processors, whenever an alternative is viable. Just to be clear, we are hurting our profits by refusing to use them. That’s how serious we are. We also pay for most of our stock (to our suppliers) via wire transfer. Very few of Minifree’s purchases are done using a debit/credit card, often none. We pay our hosting provider via wire transfer.

What’s wrong with PayPal?

Here are just some of the things that PayPal does to projects/companies that use it:

  • Blocks payments, for no reason (PayPal did this to Minifree all the time. Customers often made several attempts before payments went through – we know this, we have the logs of failed order attempts, and memory of many telephone/email conversations with customers who had troubles ordering)
  • Freezes accounts (PayPal did this to Minifree, twice), regardless of whether all or most of your money is currently in the account.
  • Charges ridiculously high percentage fees to sellers, especially for income from foreign countries, despite the fact that PayPal provides poor quality service and is actually quite uncompetitive in general with other payment processors. (most credit/debit card processors are cheaper than PayPal, and don’t have nearly the same problems).
  • In addition to the high percentage value fees, PayPal’s foreign currency exchange rates are generally very low, so they rip you off twice. That, combined with blocking some payments, means that PayPal costs your business thousands per month or more, potentially.
  • PayPal is particularly hostile towards Free Software projects and companies related to Free Software development. (Minifree fits this bill, and the director of Minifree is also the lead developer of Libreboot, the free BIOS replacement that Minifree installs onto the computers that it sells)

Really? Just look at this well-known project and what they had to say:

There are thousands of stories online. These are just a few examples pulled from a very large proverbial hat.

Initially, Minifree had decided to use PayPal because, as is often believed by small start ups, it seemed like an easy option to us, and it looked decent enough since so many other sites use it, even the big ones. It even offered an option for non-paypal-users to pay with a credit/debit card without creating a PayPal account. So we thought, it was acceptable. We were wrong.

Minifree apologises on behalf of all of its customers who felt compelled to use PayPal when ordering from Minifree (or Gluglug, Minifree’s previous incarnation) in the past, even if they hated PayPal. PayPal should never be used.

Why are wire transfers better?

A wire transfer is when you (payee) give your bank account number (IBAN, SWIFT, etc) to the payer. They then give this information to their bank, and tell their bank to transfer the money to your bank account. This has been the standard way of sending money to foreign countries for decades.

Wire transfers usually have zero fees for the merchant, and usually low or zero fees for the purchaser (in the UK and other EU countries, it usually costs nothing to initiate a wire transfer). Not only that, but you’re not even taking any private financial details from the customer; this is far more secure by design, and it means that you don’t have to comply with PCI DSS standards, since you’re not taking card payments. Your bank also does not receive any private financial details about your customers.

There’s also another advantage: your website no longer needs to process payments. You simply give them your bank account number (IBAN, SWIFT, bank address, etc) and they can start the transfer at their bank without needing to use a computer; this means that there is no risk of proprietary JavaScript being needed at all. These days, most banks also provide their customers with a method to initiate wire transfers online, so it is virtually the same convenience-wise as debit/credit cards, while being much more secure.

It’s much more federated, since your customers will all have different bank accounts with different banks (in different countries); you’re removing an intermediary from the equation entirely. The way to accept wire transfers these days are also pretty much standardised in most of the world.

In practise, wire transfers are probably less susceptible to fraud (fraudulent buyers), because getting a bank account is much harder than getting a credit card in most countries, and often involves showing up to a meeting with your bank manager (your face will be on their cameras).

In some cases, a wire transfer can also be initiated somewhat anonymously. If you’re in the UK, you can walk into a branch, without a bank account, and pay cash at the counter, giving them Minifree’s sort code and account number, which they will then use to deposit that amount into Minifree’s account. You only need to specify the correct payment reference (usually the invoice number), and then the payment would be received and identified correctly.

What about credit/debit cards?

This presents similar issues to PayPal. For low value sales, credit/debit cards certainly do make sense, but Minifree mainly focusses on higher-value (laptops, desktops, servers) and is not interested in anything else.

For processing card payments, the merchant has to be PCI DSS compliant; basically, they must comply with several security practises. Most merchants outsource to third party card processing facilities (which won’t be mentioned here), typically redirecting to a page on that providers website, for accepting payments. The problem with this is that they often serve proprietary JavaScript. However, the beauty here is that you’re not storing card details yourself, which means that your PCI compliance is quite easy and straightforward.

If you want to be absolutely sure that no proprietary JavaScript is used, then you must process (and store) card details yourself. You would still still typically use a third party (outsourcing company) for actually taking the payments, but you would be able to provide your own interface on your own website for taking details. This means that you yourself can control what JavaScript code is supplied to the user. There are several problems here:

  • You have to maintain the code, and make sure that everything works. You have to talk to the payment processor during checkout, for tokenization, validating cards and so on. They can change their API any time, without warning – this either means that you have to spend a lot of time maintaining the software on your website, or you have to pay a lot for them to do it (probably giving them access to your site, which introduces security issues).
  • The PCI DSS compliance becomes much more expensive and time consuming. Several checks have to be made every year, and there are many long questionaires to fill out.
    This means that you have less time to focus on what actually matters; providing products and services to your customers.
  • You more or less have to self-host everything, and cannot outsource your hosting, because you have to make sure that everything is stored securely (how can you trust your webhosting provider to keep you secure? You have no way to verify their practises, and they won’t necessarily inform you of a breach or even be aware of one, and not only that, large hosting companies are large targets for intrusions for this exact reason)

Credit/debit card payment processors also typically take a very large portion of your income per sale; typically anywhere between 2-4 percent, usually on the higher end of this scale. It may seem small, but this percentage applies regardless of how much you charge for your products. For high value sales, this can become very expensive.

Even if you do meet PCI standards (which you have to) when taking card payments, think about it: you are being trusted to store peoples payment details in your company. Why should you need to do that? Is this not inherently insecure? What if a breach occurs?

Bitcoin? Other cryptocurrency?

Cryptocurrencies are generally difficult to deal with, accounting-wise (Minifree is a UK company, and it pays tax to HMRC, the UK’s tax revenue service).

In UK tax returns, you also need to convert everything to GBP for HMRC purposes. This means using a bitcoin exchange, and most of them are shady and untrustworthy (probably no better than PayPal, since they’re not banks so they have less governmental regulations protecting your finances). We do not feel comfortable using bitcoin, even if fiat currency (GBP, EUR, USD, DKK, NOK, RUB, etc) has it’s own share of problems.

Our suppliers also don’t use BTC either, so this means we’d be forced to use a BTC exchange if we accepted BTC as payment method.

Practically speaking, BTC is a no-no for Minifree at present. However, philosophically speaking, we support it 100% (but we can’t use it, yet).

Western Union?

This requires the director of Minifree to show her ID to a cash pickup point, which she doesn’t want to do.


Minifree does not accept in-person visits, and sending cash through the mail is not secure. We do not accept cash. If you’re in another country, sending cash also means getting currency converted (for cash, we would only accept GBP), and your bank would charge a lot for the currency conversion; roughly the same amount as they would for a wire transfer.


Minifree does not accept this method of payment, due to several practical issues that exist with it. For instance, there are long delays processing international cheques at the bank, and that’s notwithstanding the possibility of a bounced cheque.