I recently did a very small integration with GoCardless: just a one-page registration form that then redirected out to them to capture direct debit details.
I was very pleasantly surprised that I, as an individual developer, was able to access all their documentation and sign up for a Sandbox API key very quickly and painlessly. I didn’t have to tie to the the real company account in any way (which I was still waiting on details for at the time).
It’s disappointing how rare it can be to not have to jump through any hoops.
Wow, that's awesome! I've found sometimes the "verification" process of getting access to dev-docs and API keys etc. a bit of a ball-ache in the past with some providers too.
What was the integration itself like in the end? Good docs/sensible API?
The one small part of it I worked with (registering users) was very easy. Documentation was clear with example code in a stack of popular backend languages.
Our backend is all PHP, so I just pulled in their Composer package. As I recall, all I had to do was pass it customer information and a redirect URL for where to send users after completion, and it handled the rest.
My experience differs from others here. I did an integration for a national charity.
A simple integration is straightforward; however if you want to test all permutations possible the support is lacking.
The different documentation (their "turoial" ones, the API docs, and their helpdesk documents) contradicted at times.
But the testing story was the worst part. In the end we took a "Run in production, save all GoCardless events, replay and test/correct the behaviour based on them". This was the only way we were able to get all expected properties in uncommon cases e.g. where a supporter used the Current Account Switching Service, so the DD was migrated to a new bank account.
An easier way to set up the scenarios, to mock all cases, and to re-run them would be appreciated. In their sandbox, you have to wait in realtime for the next DD collection to occur.
I find most payment processors not brilliant at supporting automated testing, but at least the number of card numbers etc that Stripe, Braintree et al have allow easy testing of any flows.
I know about the scenario simulation, and when I have corresponded with the support team it is where they have pointed me. This in spite of saying I have read it and explained why it isn't doing what we're after.
In its current form, it is not adequate. We have to manually set up the resource to run it on. Once run, there is no easy reset, to re-run it (if, for example, the response was handled incorrectly).
It can be argued that mocking all behaviours should be carried out our side and not involve the GoCardless sandbox. I am open to that, but note we have not seen any existing libraries handling this.
And the behaviour of other payment processors suggests this is not the most common approach to take.
Edit: As samples of all events/payloads are not present, we have to record production data first in order to get the data we can use in our mocking and testing.
Been using GoCardless for a couple years now they have been great.
The API is simple enough and does exactly what one would expect, Stripe used to be like this but right now is a complete clusterf"#%k, they have so many "products" that they've become the quintessential example of feature creep.
I have the idea that the US is the Mecca of credit cards, how widespread is the usage of Direct Debit in the US?
FWIW, I've been working with the Stripe API for the last 5 years, on an integration spanning 7 years of API changes, and I find it necessarily complex. I'm not sure it would be possible to reduce the complexity much without sacrificing quality.
I would disagree or maybe we have different ideas of what recurring payments are. Most businesses that use recurring payments require their customers to allow them to ACH debit their account.
Hi Pedro, Brad from GoCardless here. So glad to hear you're enjoying the product. The US (well, North America, really) definitely has a penchant for credit cards relative to the rest of the world, but Direct Debit is sizeable (and growing)!
Last year, the ACH network (the US's equivalent of Europe's SEPA network, or the UK's Bacs network) added more than a billion new transactions for the 4th year in a row. The system saw 23 billion transactions, of which 13.4 billion were debits.
The org that oversees ACH - Nacha - has indicated 80% of US businesses prefer to receive B2B payments via ACH debit, and 53% of consumers share this preference for recurring bills. (That said, there's still a lot of opportunity - a Goldman Sachs report found that 60% of B2B payments are still done by check.)
It’s pretty common. If you pay a lot of household bills—for electricity, water, insurance, rent, tuition, etc.—many of those will accept credit cards, but most will also allow ACH direct debit as a payment option and a few will only allow direct debit and check. Or sometimes there is a credit card option, but it is run by a third party and comes with a surcharge.
On the other hand, direct debit is often not an option at all for “online” subscriptions such as news sites or streaming services, or for newspaper or magazine subscriptions.
I was there recently and people seemed blown away at my instinct to pay by contactless card payment. At one or two shops, the staff member serving me commented on how rare it was to see a customer do that. ️
Isn’t ACH slow though? I have personally used ACH to transfer between personal bank accounts and it usually takes 2-3 days for each transaction to complete.
Also a 1% transaction fee for something that takes 2-3 days to process seems very high. Companies already have a business checking account, why can’t I use that account to process the ACH transactions?
If US banks got their head out of their ass they could leverage their existing ACH infrastructure and include it as a low cost way to process transactions (static fee of a few cents).
19 comments
[ 0.18 ms ] story [ 51.0 ms ] threadI was very pleasantly surprised that I, as an individual developer, was able to access all their documentation and sign up for a Sandbox API key very quickly and painlessly. I didn’t have to tie to the the real company account in any way (which I was still waiting on details for at the time).
It’s disappointing how rare it can be to not have to jump through any hoops.
What was the integration itself like in the end? Good docs/sensible API?
Our backend is all PHP, so I just pulled in their Composer package. As I recall, all I had to do was pass it customer information and a redirect URL for where to send users after completion, and it handled the rest.
A simple integration is straightforward; however if you want to test all permutations possible the support is lacking.
The different documentation (their "turoial" ones, the API docs, and their helpdesk documents) contradicted at times.
But the testing story was the worst part. In the end we took a "Run in production, save all GoCardless events, replay and test/correct the behaviour based on them". This was the only way we were able to get all expected properties in uncommon cases e.g. where a supporter used the Current Account Switching Service, so the DD was migrated to a new bank account.
An easier way to set up the scenarios, to mock all cases, and to re-run them would be appreciated. In their sandbox, you have to wait in realtime for the next DD collection to occur.
I find most payment processors not brilliant at supporting automated testing, but at least the number of card numbers etc that Stripe, Braintree et al have allow easy testing of any flows.
I'm an engineer at GC and regarding your comment on testing/mocking we do have a tool to help with that: https://developer.gocardless.com/getting-started/developer-t...
Maybe this is hidden/not clear in the documentation.
I'll pass this feedback to our API team.
In its current form, it is not adequate. We have to manually set up the resource to run it on. Once run, there is no easy reset, to re-run it (if, for example, the response was handled incorrectly).
It can be argued that mocking all behaviours should be carried out our side and not involve the GoCardless sandbox. I am open to that, but note we have not seen any existing libraries handling this.
And the behaviour of other payment processors suggests this is not the most common approach to take.
Edit: As samples of all events/payloads are not present, we have to record production data first in order to get the data we can use in our mocking and testing.
The API is simple enough and does exactly what one would expect, Stripe used to be like this but right now is a complete clusterf"#%k, they have so many "products" that they've become the quintessential example of feature creep.
I have the idea that the US is the Mecca of credit cards, how widespread is the usage of Direct Debit in the US?
Credit cards and paper checks. A very large portion of the recurring payments in the US are still based on paper checks.
Last year, the ACH network (the US's equivalent of Europe's SEPA network, or the UK's Bacs network) added more than a billion new transactions for the 4th year in a row. The system saw 23 billion transactions, of which 13.4 billion were debits.
The org that oversees ACH - Nacha - has indicated 80% of US businesses prefer to receive B2B payments via ACH debit, and 53% of consumers share this preference for recurring bills. (That said, there's still a lot of opportunity - a Goldman Sachs report found that 60% of B2B payments are still done by check.)
On the other hand, direct debit is often not an option at all for “online” subscriptions such as news sites or streaming services, or for newspaper or magazine subscriptions.
[1] https://en.wikipedia.org/wiki/Unified_Payments_Interface
Also a 1% transaction fee for something that takes 2-3 days to process seems very high. Companies already have a business checking account, why can’t I use that account to process the ACH transactions?
If US banks got their head out of their ass they could leverage their existing ACH infrastructure and include it as a low cost way to process transactions (static fee of a few cents).