Accepting credit cards online for recurring payments in Europe | Hacker News Reader

Accepting credit cards online for recurring payments in Europe

piesync.com

35 pointssimon0220 comments

I find it strange that everytime I read something about payments in Europe it's about credit cards. I don't know anybody here in Germany that uses credit cards as their main way for payment, most people I know don't even own a credit card. If you don't offer direct debit or wire transfer I won't buy anything from you.

If you want to sell internationally, credit cards are practically the only way possible. If you ask me, there is no standardized way to allow users to pay via wire transfer (internationally and instantly). Heck, even amazon.com does not support international wire transfer.

I think even consumers are getting used to the fact that ordering online internationally is done mostly via credit cards.

Another question is, how would you handle automatic recurring payments?

There is sepa for wire transfers and direct debit in most of Europe.

To let costumes pay via wire transfer just give them your IBAN and let them pay. Or you take their iban and set up direct debit.

How to handle recurring payments? Well let your costumes set up recurring wire transfers with their bank (usually done here for paying rent or pocket money) or you just do recurring direct debit (usually done here for magazine subscriptions or insurance)

Most people just won't order because they would need to get a credit card.

http://en.wikipedia.org/wiki/Single_Euro_Payments_Area

The standard way of handling recurring payments is to send recurring invoices and have users pay those. I don't see the issue.

(I agree with you that CC's are the only practical way nonetheless.)

Yes that's true, and many businesses work that way. It heavily depends on the use case.

That's why I carefully added "internationally and instantly" between brackets here.

We are a B2B company so we are not selling to consumers. If that is your primary market, I agree that you might lose a lot of sales with only offering credit cards (anyone has a reference for this?), but I also think paying with credit card is on the rise thanks to companies like Amazon.

To me (English), "credit card" and "debit card" are interchangeable. While, as a user of the cards, I know what the differences are, as a vendor, I don't really care. I don't think I've seen any online services that offer wire transfer.

Well my experience with braintree is that if your business model is innovative enough they won´t take the risk to process your payments (told personally by a braintree representative in a phone conversation, after a brief explanation of our business model). At least they are very kind, and they´ll tell you before hand, so you don´t have to waste time with all the legal paraphernalia. A pity because the API seems really fast to implement and well thought.

Respecting Paymill... well we are not going to put data on the hands of the Samwer brothers right away(just in case...).

edit: typo.

The API does work like a charm. If history can be a reference, Paymill is going to get bought by one of the big players who want a quick start in the European market (Stripe comes to mind). But I do get your reluctance.

What alternatives are you now considering?

By now we are working with Paypal to show the concept (Not an API you would recommend dough...). But we are planing to create a Ltd. in the states to work with Stripe. It will also make it easier to close a round with american VCs. We are based in Spain and the Spanish VCs are not what you could call that "venturous". They are more likely to invest in "me too" startups, or proven models.

Author here. Are there any other important payment solutions we should be looking out for (available in Europe, Belgium) that I forgot to mention in the blog?

As I just posted in the comments on your blog, Google Wallet is a serious consideration if your app is available in the Chrome Web Store (or on the Play Store). They charge relatively little and support European accounts and subscriptions.

There's also the Google Apps Marketplace to consider if your app targets the enterprise, which also hooks into the same payments APIs.

FastSpring is worth a look. My company (also European) has been using them successfully for subscription billing for over a year. I really like their system.

Klarna is a payment startup in Sweden focused on invoices and installments. Currently working in se,dk,no,fi,nl,de,at. Could be worth keeping an eye on.

Another interesting discussion on this topic: https://news.ycombinator.com/item?id=5091069 (not limited to recurring payments)

Is Braintree really holding the first $3000 in reserve until you stop using them? That sounds rather weird and unexpected.

It's neither weird nor unexpected. Reserve accounts are a decades-old tool of the credit card processing industry for approving new or unusual businesses.

The bank is taking a considerable risk: whatever the merchant's expected transaction volume is, the bank could be on the hook for up to 6 months worth if that business were to go bankrupt or otherwise disappear without fulfilling its obligations to customers. They would all charge back their payments, and with the merchant gone, the bank underwriting the merchant account is on the hook for all that money. If they start out at $10k a month in revenue, that's $60k in risk for the bank.

If a company has no track record, poor or no credit, or a business model that doesn't fit well into a known risk model, the bank can mitigate the risk that it'll lose money by establishing a reserve account. It might be a fixed reserve (i.e. $3000 for a new company with low expected initial volume), or a rolling reserve (i.e. holding back 15% of your gross sales up to some limit for an existing account that has seen a jump in its chargeback rate).

The alternative is to deny the application altogether. Now, a bit of speculation... Stripe, PayPal Pro and other 3rd-party processors that act like first-party processors are able to take more risks (like letting you start taking payments right away without a formal application and underwriting) because they've negotiated permission with their underwriting bank to process payments on behalf of their customers with only one or a few real merchant accounts. By pooling many customers on one account, and charging a premium on the fees, they can absorb more losses and even handle merchants with >1% chargeback rates without the underlying merchant account reaching those risk barriers, which is all Visa/MasterCard/Amex care about... as long as on average, their customers are running legitimate, healthy businesses.

It surprised us too. And it is actually the merchant account provider, Adyen in our case, who ask for this reserve. This money is used as a security in case we would charge eg. 100 customers, receive the money, spend it all on marketing and then notice our product is broken and we have to declare bankruptcy because we do not have any savings left. As I understand it, the amount can vary greatly depending on the amount of risk they see in your business plan.

$3000 is quite low in my experience (depends on your processing volume; I've seen high tens to mid hundreds of thousands of dollars) - although reserves typically aren't applied as 100% of your transactions until you meet them. Normally it's filled slowly over time, say 1-5% per transaction until the reserve is met.

Moreover, you generally won't get it back until several months after you stop processing, since that's when the real risk of chargebacks goes away. Depending on your contracts and agreements, the timeframe can change significantly, including having several smaller payouts.

That's a nice post, glad you have got the solution for recurring payments. In India we don't have that open yet.

Reply on news.ycombinator.com