How to integrate with the GoCardless API

What is the GoCardless API?

The GoCardless API is a way for developers to interact via software with GoCardless, allowing you to integrate us into your website, mobile app or desktop software. This means you can build your own customised integration to automate payment collection and reconciliation.

What do you need to do to integrate with the GoCardless API?

Integrating with the GoCardless API is incredibly simple and can be done in minutes with the following simple steps and our easy to use API libraries.

1. Sign up for a sandbox account if you haven’t already - it’ll only take a minute to create your account. If you already have a sandbox account, just log in to your dashboard.

Continue reading...

Get started with our API
Visit the developer site

GoCardless goes down under - collect payments in Australia

We’re really excited to announce that you can now collect payments from Australia with GoCardless. The launch means our customers can now take payments from 24 countries and it brings us one step closer to delivering a global bank to bank payments network.

We have heard from many of you that Australia is an important existing or new market for your business, so we’re really looking forward to supporting you and your customers.

We think Direct Debit is the perfect solution for collecting payments, and it seems that customers in Australia agree; almost 36% of non-cash transactions were made through Direct Debit* in 2017, with trends indicating that this number will grow in 2018.

Continue reading...

Start collecting Australian Direct Debit through your account
Add BECS
in Business

Elevate your member experience to win in a fast-changing fitness industry

The UK’s largest health and fitness trade show, Elevate, returned to the Excel Arena last week and GoCardless was there to take part in the action.

We were joined by hundreds of fitness businesses, from gyms and equipment suppliers to software platforms, including our fantastic partners ClubRight, Glofox, Virtuagym, OpenPlay, Sport Solutions and more.

Business leaders took to the stage in Elevate’s first conference, to share their thoughts on emerging trends and the future of fitness. Throughout the two-day event, one thing became clear: the fitness sector is changing and those who focus on member experience will emerge as the winners.

In an industry that is shunning long-term contracts in favour of more flexible membership options, fitness business operators must provide a better member experience to attract members and keep them for longer.

That means top facilities and passionate employees committed to helping members see results. But increasingly, it also means keeping up with fitness trends, integrating technology into your offer and providing simple, hassle-free payments. We’re excited by this as we think our Direct Debit solution can help gyms of all sizes to do just this!

With this in mind, here are our 3 key takeaways from Elevate 2018.

Continue reading...

Get the most out of your Direct Debit provider
View the guide

Our role as a data controller and what it means for you

In February we wrote about our commitment to the upcoming General Data Protection Regulation (GDPR).

Under GDPR, businesses must operate as either a data processor or a data controller. In this blog, we explain GoCardless’ status as a data controller - and what that means for our customers.

As part of our preparation for GDPR, we have looked carefully at how we process data relating to customers who pay companies through GoCardless (‘end customers’).

From that analysis and taking into account UK and EU-wide regulator guidance, industry practice and legal advice, we've determined that we act as a data controller in respect of end customers (like many others in the payments space, including Square, PayPal and Visa members).

Ultimately, being a data controller means we have an even greater responsibility to protect your customers’ data - and we are directly liable to data protection authorities in relation to all obligations under the GDPR.

Data controller vs data processor

Under GDPR, businesses must comply as either data processor or data controller, in relation to specific data.

  • Data processors process personal data on behalf of the controller, but they don’t decide the purpose (the ‘why’) or the means (the ‘how’).

  • Data controllers determine the purpose of the processing and the means to achieve that purpose. Essentially they decide why and how the processing should take place.

Continue reading...

GoCardless and GDPR
View our customer FAQs
in Business

Goodbye, card surcharges. Hello, Direct Debit. Why the travel industry must offer alternatives to card payments

At the start of the year, millions of Britons escaped the grip of winter by flying to warmer climes. At the same time, a different kind of chill was descending on the holiday industry.

New pan-European legislation came into force at the start of the year banning surcharges on credit and debit cards, a move that hit many businesses’ profits hard. But holiday firms, with their big-ticket products and already slender margins, were affected more than most.

Plastic is still the most popular way to cover vacation costs for many people. Consumers spent £19.3 billion on credit cards with travel agents between January and October last year, according to the latest data from UK Finance.

It’s obvious why customers like cards – they’re accepted everywhere, easy to use and provide extra protection if things go wrong. The travel industry liked card payments until January, too – prior to the ban, travel firms typically charged customers who paid by credit card 2 per cent, roughly what they themselves were being charged by the banks to process those payments.

It may not sound like much, but cutting that 2 per cent surcharge equates to an equivalent loss of £385 million to the UK travel industry over that January to October period.

Continue reading...

Direct Debit - a beginner's a guide
View the guide
in Engineering

Service outage on 6 April 2018: post-mortem results

On Friday 6th April at 16:04 BST, we experienced a service outage. For a period of 27 minutes, the GoCardless API and Dashboard were unavailable, and users were unable to set up a Direct Debit via our payment pages or connect their account to a partner integration through our OAuth flow.

What happened

The outage was caused by a misconfiguration of our database, which stopped us making changes to the data we have stored.

For those of you wanting the technical details, the error was due to us reaching a limit on the ID given to each entry in our “update log”. Every time we make changes to certain tables in our database (i.e. create or update a row), we make a record of the changes to an “update log” to provide an audit trail. Each entry in the log has an automatically-generated sequential ID (1, 2, 3, and so on). Our database configuration meant that the maximum possible value for this ID was 2,147,483,648.

We hit this limit, so we were unable to write to the “update log”, which blocked writes to the database. For more details, see our previous blog post.

Our response

As a payments company, we know how critical our service is to our customers, and we take incidents like this extremely seriously.

As such, once we’ve responded to an incident and restored service for our users, we run “post-mortems” to make sure we understand:

  • exactly what went wrong
  • how we can reduce the chance of similar incidents occurring in future
  • how we can respond more effectively when things do go wrong

Following the post-mortem for this incident, we’ve already taken a number of steps to improve our systems and processes for the future:

  • We’ve improved the robustness of our automated alerting, guaranteeing that we’ll be informed within seconds if our service goes down
  • We’ve improved the reliability of our code for turning off the “update log”, allowing us to recover more quickly if we see a similar failure in the future
  • We’ve made our code more resilient, so “read-only” requests to the API will still work even if we’re unable to write to the database

We’d like to apologise again for any inconvenience caused to you and your customers. We will continue to invest in our technology and processes to ensure we guard against any similar incidents in the future.

in Business

What the gig economy means for the self-employed

The world of work is changing. An ever increasing number of people are becoming self employed and are responsible for generating their own work - and getting paid for it.

These changes have been facilitated by technology, with smart devices and ubiquitous wifi making it easy for individuals to transact in the digital economy.

On top of this, 'gig economy' platforms such as Deliveroo, Uber and AirBnB are providing freelancers with the opportunity to top up their income with short term contracts and one-off jobs.

Gig economy assignments and longer form freelancing opportunities have clear benefits such as flexible hours and the opportunity to strike a better work/life balance. But they also have their own set of unique challenges, including getting paid on time and the lack of workers rights.

In this blog, we take a look at some of these pros and cons in more detail.

Flexibility

Continue reading...

Guide to getting paid in time
View the guide
in Announcements

Our approach to testing

To ensure that we keep building the best payment solution for you & your customers, GoCardless will be testing ways to improve areas of our product. Sometimes when we run a test a small number of your customers may see a slightly different experience.

Why?

Payer experience is an extremely important part of both our business & yours. We want to help more and more of your customers to pay you through GoCardless.

We’re continually researching and developing ways to make our product better for you, such as looking at how we make it easier for your customers to use our payment pages, so more of them end up paying you using GoCardless. Part of this research process involves testing with real customers to help us make informed decisions using data.

Continue reading...

Contact us
in Engineering

Service outage on 6 April 2018: our response

On Friday 6 April at 16:04 BST, we experienced a service outage. For a period of 27 minutes, the GoCardless API and Dashboard were unavailable, and users were unable to set up a Direct Debit via our payment pages or connect their account to a partner integration through our OAuth flow.

Submissions to the banks to collect payments and pay out collected funds were unaffected.

We’d like to apologise for any inconvenience caused to you and your customers. As a payments company, we know how important reliability is to our customers, and we take incidents like this extremely seriously. We’re completing a detailed review of the incident and taking the required steps to improve our technology and processes to ensure this doesn’t happen again.

What happened?

All of our most critical data is stored in a PostgreSQL database. When we make changes to certain tables in that database (i.e. create or update a row), we use a trigger to keep a separate record of exactly what changed. We use this “update log” to enable data analysis tasks like fraud detection.

Each entry in the log has an automatically-generated sequential ID (1, 2, 3, and so on). This ID is stored using the serial type in the database, which means it can be a value between 1 and 2147483648.

At 16:04 on Friday 6 April, we hit this upper limit, meaning we could no longer write to the “update log” table. In PostgreSQL, when a trigger fails, the original database write that triggered it fails too. This caused requests to our application to fail, returning a 500 Internal Server Error.

This issue also affected API requests (including those from the Dashboard) which only appear to read data (e.g. listing your customers or fetching a specific payment), since authenticated requests update access tokens to record when you last accessed the API.

How we responded

Having identified the root cause of the problem, we disabled the trigger which sends writes to the “update log”, thereby restoring service.

We’ve resolved this problem for the future by storing the IDs for our “update log” using the bigserial type, which allows values up to 9223372036854775807. This is effectively unlimited, and can be expected to provide enough IDs to last millions of years.

Next steps

In the next few days, we’ll be running a full post-mortem to better understand:

  • how we can reduce the chance of similar errors occurring in future; and
  • how we can respond more effectively when things do go wrong

We’ll publish the results of this post-mortem in a follow-up post within the next 4 weeks.