I don't get why the US and UK rely so much on payment methods that rely on the secrecy of some unique codes, that you have to trust every payee to secure. Seems backwards to me.
Here in Portugal we have both direct debits and "service payments" (for one-off stuff), and in both cases the payee is the one telling the bank about the payment (usually on the bank's website or an ATM). There are codes involved (the merchant's), but since they can only be used to transfer money to them, they don't have to be secured.
What secret code are you referring to? To do a direct ACH transfer to someone, you need only an account #, and that's not a secret since it's on every check you give out.
Is this also true the other way around? Seems like security can be lax when depositing to an account but should be much more strict debiting from an account.
Since these charges can be reverted by the customer this system works by thoroughly vetting the debiting company and ensuring that it is able to repay the funds owed from these 'chargebacks'.
Yes, and no. Bank has APIs for including/opening popup with a very simple "focused on this transaction only" form for a quick payment sign from the user. So this is integrated into the seller site purchase flow.
I know for sure Montepio has them. Probably others too but that's the only one I use. I pay all my bus tickets with it directly from the bus company website.
Vasco, can you please point me to that website? I'm researching online payment solutions in Portugal and would love to see that implementation. Thanks.
In Poland probably everything. There's services that handle the integration, so you don't have to implement all of their APIs.
My banks service is called mTransfer, and the integration providers are e.g. Przelewy24 and platnosci.pl. Basically all the polish websites connect to one of those.
APIs are, as far as I know, not publicly available. Each bank has their own API—again as far as I am aware.
I have never seen any integration of this sort with a Swedish bank on an international site, but I don't know if that is because international vendors don't want to bother with integrating with a number of different bank APIs in X number of countries, or if you need to have a local (Swedish) account to be able to process payments this way.
The only place I can find that seems to integrate these is Inpay, who I had not heard of before http://www.inpay.com/ who seem to have pretty good coverage.
Is collective payment taken once a month or on a per transaction?
When using a credit card, having a keylogger trojan on my comp is a minor deal. if I'm entering my bank details, it becomes huge. Am I covered?
The UK is one of the financial scam hotspots of the world. CS told a family member it's why BB left the UK. This after the family member had an order for £5,000 worth of iMacs cancelled repeatedly for no apparent reason (even after confirming three times with the CC company that the card was okay to go ahead).
I hope you're ready. There is a huge demand for a solid payment solution though, so if you hit it right, you're on to an easy exit.
What shows on the bank statement?
- GoCardless shows up on the bank statement
Is collective payment taken once a month or on a per transaction?
- We take a payment for each transaction. This makes it clearer for payers and merchants get their money quicker.
I always love to see innovation in the payment space. In the grand scheme of things, there was very little innovation until PayPal arrived, but there has been very little innovation post-Paypal arrival as well (compared to improvements in other areas).
My biggest worry with something like this is that small companies in the financial space can be here one minute, and gone the next.
I wonder what these guys are doing to establish their credibility and safeguard their future prospects as well as for their customers.
This is fantastic. Payments are still so shit across the world. I have a lot of respect for startups that try and take on the task of changing them for the better.
I agree that the site doesn't look great, but their platform works pretty good (well, apart from the abysmal SOAP API) and they offer support for lots of different payment methods (including direct debit, in lots of countries). So I truly don't understand why everybody is suddenly getting so excited about direct debit payments?
When your customers money and your businesses reputation are at stake trust is a huge issue. The website doesn't look great and gives hardly any information on the services.
I'm sure if they smartened up their website and offered a REST API they'd be in a much better position for web based startups to consider them, otherwise I'm left searching for signs that its a professional and trustworthy company to try and balance my initial impression.
Don't get me wrong, I totally agree with you on the design part.
But what I'm trying to figure out is if design and a REST API are the only 2 things where GoCardless outexecutes competitors. Especially since direct debit clearly isn't something new and there are other players in the field that offer a much broader support for different kinds of payment methods.
Id guess so yes but also market reach. I have a UK business and currently our customers are manually transferring money to us every quarter because I couldn't find a simple, easy and cost effective way to retrieve payments.
I hadn't come across Adyen until you mentioned them here.
This is great news. Finally a UK-based payments solution. The difficulty/cost of getting a Merchant Account and taking payments is what has put me off beginning any of my weekend projects in earnest. Wishing you the best of luck with this.
That was good to see. For EU payments (no sign they are going global) this would make a great solution. Less use for me while still UK only, but I am sure there are lots of UK businesses that could start using it now.
Doesn't look like you can make payment requests via the API without sending the card owner to the gocardless site first.
Our need is to be able to take a customers card details, store it with a provider (and get an auth code) and then bill that card via an API. Hopefully they'll expand on their current offering soon, UK businesses really need more options in this market.
You're right, I've let that go straight over my head.
It's the same deal though at the end of the day, as a business I want to take payments from my customers without hassling them to make manual transfers.
So an id for cc details is the same as bank details from my end providing I can request payments for flexible amounts.
Service providers in the UK seem to be able to change the amount I pay on direct debit agreements without anything further from me, so I assume its all possible on the banking side.
Looking at the API, if you have the agreement set up you can make charges up to a maximum limit (that you can see) without further customer interaction. If you need to interact with the customer there are different API calls, eg to increase limit, get initial agreement.
So id have to get the customer to agree to authorise an amount larger than their current subscription fee so that it has scope to cover upgrades and extra services - something doesn't quite feel right there, maybe I'm approaching it completely wrong.
I can't see any guidelines about how you are recommended to approach these types of situation. In some ways pre-setting a max limit is nice for the customer if you warn them when they approach. I know people who have been billed huge amounts on AWS without really realizing. SO long as you hand hold the customer and your pricing model is simple to understand you should be able to make it work out I would think. For upgrades there is probably no reason not to get explicit agreement (presuming it is just a checkbox really, no need to give the acount details again after all), it is variable usage that is more complex I would think.
If we are able to provide some blurb on the form then it can probably be explained adequately to alleviate any of the customers concerns, on the other hand if they just see a form asking for authorisation to take an amount over their standard subscription it probably won't work.
I agree that subscriptions could change if they just have to tick a box and not provide all their details again, it's just that in our case we often provide a small variable number of one off add-on services to each customer over a month which we'd ideally not have to ask them to pay for seperately.
I've signed up for their beta though and sent them an email, hopeful that its workable. If they can do what we need id be a very happy man.
You can pass in information to display on the checkout pages. We can definitely help you with any kind of variable billing. You can come and chat with us at:
As Alex and Justin mentioned, users can pre-authorise a given amount, optionally over a time interval (e.g. up to £100 each month). The merchant can then bill the user within this limit directly via the API.
liability in the UK is different: credit card transactions are heavily protected (you're guaranteed to get your money back), whereas direct bank transfers are vastly less protected (with the exception of direct debits).
can you even have a one-off direct debit? I didn't think the system was really designed for that.
This is a common misconception about direct debits. Direct debits can be used to charge people varying amounts at varying frequencies (including one-offs).
Presumably you'll set the direct debit up on the GoCardless service, and then authorise each payment through them. So just like a third-party credit card processor, the merchant never sees your details, just that the payment has been authorised.
Just a personal incident. They took the cash out of a connected bank account following the classic "I didn't receive the delivery" scam dispute where I was the seller.
Buyer gets the delivery, then claims they didn't. It's then buyers word against sellers (this was before the new system of protection for sellers if they post to the Paypal registered address).
They then claim non-delivery. Next thing I know I'm out $300.
How do you know they got it? Did you send it in a way that they had to sign for it? If so, would not serve as proof of delivery to prevent the chargeback? And if not, how do you know that the customer is not telling the truth?
The delivery came with a signature. They claimed it was not theirs. They also had it delivered to what turned out to be a disused building, beside a car park, in a ghetto.
I wrote it off as a lesson and closed my Paypal account that day.
This is a great product for the UK. Sadly, unless they get acquired quickly, they'll get destroyed by fraud. The Direct Debit Guarantee means that as the account-holder, I can tell the bank to give me my money back immediately, with no reason. So a fraudster will make some charges, run away with the money and GoCardless will be left holding the full liability.
This is one of the reasons that it's so painful to be allowed to process Direct Debit transactions in the UK.
We've recently launched an Direct Debit facility and faced these exact problems. Luckily our DD provider works with some huge companies and so is already insured against any "indemnity claims". This insurance is reflected in our transaction fees though.
Besides the fact that a direct debit payment is reversible, isn't there also a timeout between the authorization and actual debit (in The Netherlands, I believe it's about 1-2 days)?
How do they handle chargebacks/failed payments and do they charge their merchants for failed payments/chargebacks?
I think direct debit could be huge on mobile, but given the fact that every direct debit payment can be cancelled within a month or so, how do you reduce your risks?
This looks like great news. Hirokitakeuchi could you describe what the payment flow would be like for me as a merchant if my customer has never encountered GoCardless before?
Until you gain some traction I'm wondering where perceptions of trust on the part of my customer might be affected by their interactions with GoCardless during a payment.
About £0.50 per payment, regardless of size. Certainly quite affordable, I chickened because the terms and conditions if you're handling payments for others was grey area at best, and it was hard to determine what regulations would apply for a cash-holding transaction-middleman.
They also only process direct debits monthly, and the payment needs to be advised weeks in advance, so the debtor can object. Fine for recurring memberships etc., not really suitable for one-off payments.
Finally, there's a deeply entrenched national debit-ish card, run by the same nominally private sector entity running direct debits. They essentially write their own rules for the entire sector in Denmark, and I wasn't really too keen on going up against them. So perfect match for the schlepp-essay :)
1. How quickly is the money in the merchant account after the payment is authorised by the consumer?
2. Is the Faster Payments system now the new standard? If so, what is the difference between this and electronic Direct Debit and will you be porting onto Faster Payments?
3. What is next for GoCardless, apart from user (business) acquisition?
1. We pay out on a 7 days after a transaction is initiated.
2. Faster payments is the new standard for payments initiated from within a bank account (e.g., via online banking). Direct Debit is still the standard for "pull" based payments.
3. Keep an eye out. We have some big announcements coming up.
Although I like the idea aslong as banks charge anything up to £40.00 for a failed direct debit I can't see it catching on. If there's not enough funds in Paypal it will just bounce the payment with no charge (providing you aren't funding your account with your bank account).
Given that DD is a very well established service with high takeup, there is evidence that the UK population is happy to use it. However, there may be an issue with the public not trusting unknown companies to take payment this way.
I thought it was some sort of new 'micropayment' service aswell from the HN title of "Direct Debit API for 1% max £2". Twas only after reading the website that I realised the max £2 is for their fee.
Here in Portugal we have both direct debits and "service payments" (for one-off stuff), and in both cases the payee is the one telling the bank about the payment (usually on the bank's website or an ATM). There are codes involved (the merchant's), but since they can only be used to transfer money to them, they don't have to be secured.