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 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.

in Engineering

Moving fast at GoCardless: why we invest in our workflow and processes

At GoCardless, how we work is the secret sauce that allows us to deliver excellent customer experiences, from how we run customer support to how our design and marketing teams collaborate.

In this post, I’ll talk about how we changed the way we work over the last 9 months to build truly global software and introduce a localisation process which allows us to move quickly and deliver real value for customers.

The GoCardless Dashboard in French

We wanted to provide a great experience for our users, whatever language they speak — but it was imperative to do so in a way that didn’t slow us down as we continue to build out our product. When we get processes like this wrong, we not only make our team’s work harder than it needs to be, but we place a drag on what we care about most: delivering value for our users.

There’s a whole other post I could write about the intricacies of that process and how we’ve invested in sourcing skilled translators and ensuring we have perfect translations with quality assurance (QA) processes - but in this post, we’ll focus on the developer workflow.

Continue reading...

Want to work with us?
We're hiring
in Engineering

When good controllers go bad: getting started with Coach

Just over two years ago, Lawrence wrote about Coach, our open-source Ruby library which makes it easier to build robust, maintainable and well-tested APIs by replacing Rails controllers built with ActionController with chains of "middleware".

Since then, we’ve continued using Coach and we’ve no doubt that it has allowed us to move fast, write code that stands the test of time and maintain developer happiness.

In this post, we'll build a simple API using ActionController, discover the pain points, and then see how Coach can help.

Continue reading...

We're hiring developers
See job listing
in Engineering

Our 2017 internal hackathon: what we built

GoCardless Internal Hackathon 2017

On Friday 25th July, we held 2017’s annual GoCardless internal hackathon.

In a hackathon, a small team comes together for a short period of intense work to solve a problem, complete a challenge or build something new.

We brought together everyone from across our cross-functional Product Development team, including everyone from product managers to designers to systems reliability engineers (SREs).

This carries on a proud GoCardless tradition, starting with the pool ball tracker we blogged about in 2012 and have continued since - one of our interns last year, Henri, highlighted 2016’s hackathon as one of the highlights of his internship.

We think our internal hackathons are super valuable because they give us a chance to try out new ideas, learn new skills and technologies and work with people we wouldn’t usually get to work with.

In this post, we’ll look at three of the projects that came out of the day:

Trying out new ideas: the churn calculator

Churn calculator

Juliet, one of our Product Managers, worked with Ben and Joe from the Design team to build a churn calculator.

At GoCardless, we know that one of our greatest selling points is our fantastically low failure rate for payments. Where credit and debit card payments experience failure rates of 10-30% a month due to expired or cancelled cards, bank accounts don’t expire!

The team wanted find a way to help users understand the tangible difference cutting churn can make to their bottom line, so they put together a brand new churn calculator.

On the calculator, a potential user of GoCardless can input their total numbers of customers, the average value of each payment they collect and the number of payments they expect to collect per month for customer.

They’ll get back a beautiful graphical view, showing how much they can expect to lose to failed payments over the next 12 months for cards, standard Direct Debit and GoCardless.

Having experimented and built something awesome in less than a day, the team will move forward with their project, aiming to get it released onto our website soon.

Juliet said "It was amazing to have the chance to experiment and build something completely new in less than a day. We can't wait to move forward with what we've started and bring it to the GoCardless website soon".

Learning new skills: visualising GoCardless’s payment volumes

João, one of our interns worked with Pete, one of our Technical Leads, to resurrect a classic GoCardless hackathon project from a bygone era: the 'make it rain' dashboard. This tool shows each payment being collected through our infrastructure over the course of a day as a coin falling from the sky, each one labelled with its payment amount.

They kicked off the project with another key goal: to work on something fun and learn something new.

They wrote the backend in Go, which neither of them had used before, to handle real-time data on payments as they were processed. They then refactored the old frontend code of 2015 to make the most of new JavaScript features introduced in ES6.

"By the end of the hackathon, we were pretty happy with the result and what we learnt in such a short period of time. It was a really fun day!" said João.

Working with different people: bringing the noughties MSN Messenger experience to Slack

Chris, one of our System Reliability Engineers, worked with Marco, one of our interns, to build a new tool called Slackify, aiming to bring one of the best features of MSN Messenger from the 2000s to Slack: showing what music you’re listening to in your status.

Experimenting with the Elixir programming language, they got to work together for the first time, and finished the day with a working prototype (albeit having spent much of the day fighting with Spotify and Slack’s OAuth APIs!).

Marco said "The hackathon was a blast! It gave me the opportunity to work with Chris, who I don't usually work with, and to get to know him better -- and also to learn Elixir!".

Interested in joining GoCardless?
We're hiring
in Engineering

Building our new developer experience: Part 1

Our API is at the heart of everything we do. Not only does it allow developers to build powerful Direct Debit solutions, but it also powers the GoCardless Dashboard along with our integrations with partners like Xero, Teamup and Zuora.

As engineers, we know firsthand the importance of having great resources at your disposal when you’re getting started with an API. So back in September we kicked off a major project to revamp our developer onboarding experience. We wanted to build something we could be really proud of and which would also delight our customers.

In this blog post, the first of a series of two, we’ll take you through the journey of building our new developer site from idea to delivery.

Continue reading...

Interested in joining GoCardless?
We're hiring
in Announcements

Introducing our new developer site

The brand new

The API is at the centre of everything we do at GoCardless - thousands of our customers use it to integrate Direct Debit into their applications and business processes, and it powers our Dashboard.

We’ve long had a great API reference, but we wanted to create a real home for developers with a wider range of content about our API.

To that end, we’ve launched our brand new developer site, with revamped reference documentation and a brand new getting started guide, helping you get up and running with the GoCardless API.

The guide takes you through, step-by-step:

  • Using our API libraries in PHP, Ruby, Java and Python
  • Creating your first customers
  • Taking your first payment
  • Staying up to date with webhooks

Throughout the guide, we’ve included copy-and-paste code samples in PHP, Ruby, Java and Python to make things as simple as possible.

We’ve also launched a new guide to building a partner integration, and helpful content which explains our developer tools.

We’d love to hear your feedback and answer any questions you have about our API - just get in touch at

Interested in taking payments with GoCardless?
Sign up here!
in Announcements

Improvements to our CSV exports

At GoCardless we make recurring payments invisible for tens of thousands of organisations. We know that small details can make all the difference and we’re committed to continuously improving our service. We’re also very aware that although the changes we make improve our service for countless customers, some users need time to adapt to them.

This is particularly true of the exports available from our dashboard. These help make it easy for GoCardless customers to reconcile their accounts and keep track of how much they have collected. Many of our merchants use exports regularly and build processes around them, so we often receive feedback on how to make them more valuable.

We’ve reviewed this feedback and we’re making a few tweaks. These are designed to:

  • Add extra information to make exports more useful for common tasks
  • Make sure the format for exports is as stable as possible
  • Add the ability to improve exports while minimising customer impact

Continue reading...

Interested in taking payments with GoCardless?
Sign up here!
in Engineering, People

A day in the life of a GoCardless software engineer

I’m Tim, and I’m a software engineer at GoCardless. I’ve been here for about four and a half years. I work on our UX team, building customer-facing bits of GoCardless, such as our dashboard and developer API. My team focuses on making them as powerful and easy to use as possible.

The early days

I first joined the team back in 2012, just a few months after GoCardless had launched into beta. I was attracted by the boldness of what the company was trying to do: making life better for small businesses and disrupting banks’ traditional monopoly. Since then I’ve worked in a variety of roles across the company, from setting up and running our customer support operation to running our partnerships team, to where I am now.

Continue reading...

Interested in joining the GoCardless team?
We're hiring
in Engineering, Support

Getting started with the GoCardless PHP library

This post relates to the Legacy GoCardless API. If you're starting a new integration, you'll need to use the new GoCardless API - for help getting started, check out our guide.

PHP is the web's most popular coding language, used by nearly 40% of websites, so we've made it super simple to integrate with GoCardless using our open-source API library.

In 90% of cases, you'll be wanting to set up pre-authorizations. These are variable Direct Debits, letting you have your customer authorise once through our secure payment pages, after which you'll be able to charge them automatically whenever you need to with just two lines of code.

1. Add the PHP library to your project

First of all, you'll need to sign up for a GoCardless account and enable developer mode. Once you've done that, you'll get your authentication details which you'll be able to copy and paste into your code. This will take about 5 minutes - just follow our guide here.

Next, you'll need to grab the latest version of our library. There are two options for doing this:

  • Download the ZIP file here and add it to your project.
  • Add GoCardless to your composer.json file:
    "require": {
        "gocardless/gocardless": ">=0.4.2"

We'd recommend storing the extracted GoCardless.php file and the gocardless folder inside a lib/ directory. This makes it easy to organise your code's dependencies.

Next, create a central configuration file. Using this will make it easy to share all the GoCardless setup between different pages, meaning you only have to change your settings in one place. I'll call it


  // By default, your application will run in the sandbox - here,
  // you can test with no money changing hands. When you're
  // reading to go live, simply uncomment this line.
  // GoCardless::$environment = 'production';

  // Let's add your authentication details for the production and
  // sandbox. You can get them both from your Dashboard - copy them
  // in to replace the examples.
  if (GoCardless::$environment == 'production') {
    $account_details = array(
      'app_id'        => 'INSERT_LIVE_APP_ID',
      'app_secret'    => 'INSERT_LIVE_APP_SECRET',
      'merchant_id'   => 'INSERT_LIVE_MERCHANT_ID',
      'access_token'  => 'INSERT_LIVE_MERCHANT_ACCESS_TOKEN'
  } else {
    $account_details = array(
      'app_id'        => 'INSERT_SANDBOX_APP_ID',
      'app_secret'    => 'INSERT_SANDBOX_APP_SECRET',
      'merchant_id'   => 'INSERT_SANDBOX_MERCHANT_ID',


2. Send the customer to the GoCardless payment pages

Setting up a pre-authorization will allow you to get authorisation from your customer once, and then charge them whenever you need to in the future. To do that, you'll need to send the customer through our secure payment process.

Our API library makes this simple:

// Bring in the file we made earlier, which includes the GoCardless
// library and all of our configuration

// Provide the details to use to set up the Direct Debit. In
// particular, make sure you set the amount to be higher than
// you'll ever need to collect in a month.
$pre_authorization_details = array(
  "amount" => "10000",
  "interval_length" => 1,
  "interval_unit" => "month"

// The GoCardless library puts everything together and
// generates a personalised link to our secure payment pages
$pre_authorization_url = GoCardless::new_pre_authorization_url($pre_authorization_details);

// Now we could put that generated URL behind a link...
echo "<a href='" . $pre_authorization_url . "'>Set up a Direct Debit</a>";
// or we could redirect the user right away...
header("Location: " . $pre_authorization_url);

3. Confirm the setup of the Direct Debit

Once the customer has finished going through our payment flow, we'll send them back to your website, where you'll need to confirm the authorization via our API.

Let's create a file called callback.php. You'll need to set the URL of that as your "redirect URL" in your Dashboard's developer settings:

Setting your redirect URI

// Let's include our central configuration file again.

// Pull out the required data from the redirect
$confirm_params = array(
  'resource_id'    => $_GET['resource_id'],
  'resource_type'  => $_GET['resource_type'],
  'resource_uri'   => $_GET['resource_uri'],
  'signature'      => $_GET['signature']

// We'll add this - it'll come into effect if you implement
// a more advanced integration,
if (isset($_GET['state'])) {
  $confirm_params['state'] = $_GET['state'];


// If all has gone well, you'll now be able to charge this
// customer. To do this, you'll need to store their
// pre-authorization's ID somewhere - for instance on a
// user's database record.
$pre_authorization_id = $resource_id;

<p><b>Thank you!</b></p>

4. Charge your customer

When you're ready to charge your customer, it's just a few simple lines of code:


// You'll need to pull our the customer's pre-
// authorization ID which you saved somewhere in
// the previous step.
$pre_authorization_id = fetch_id_from_database();

$pre_auth = GoCardless_PreAuthorization::find($pre_authorization_id);

// Set the details for the payment to collect. We'll
// display the "name" in emails sent to the customer.
$bill_details = array(
  "name" => "Invoice for June 2014",
  "amount" => "25.00"

$bill = $pre_auth->create_bill($bill_details);

// It's likely that you'll want to store the bill's ID
// - this is useful for staying up to date on its status
// later.
$bill_id = $bill->id;

What next?

You've now seen how to set up the GoCardless PHP library, create your first Direct Debit and then take a payment. Here's a few things to check out as your next steps:

  • Web hooks allow you to be informed about the progress of a payment or any changes to your customers' Direct Debits - so for example, we'll let you know when money has been successfully collected.
  • Pre-populating information makes it simpler for your customers to pay and increases conversion.
  • Using the "state" parameter lets you pass data through the payment process, and collect it at the other end.

If you have any questions or we can help at all, just get in touch - email us.

Want to find out more or ask questions?
Book a chat with an expert
in Business, Engineering

Rolling your own cloud phone system

At GoCardless, we're committed to providing great support to all of our users. This means building great tools, both for our customers and for internal use.

We've previously looked at our Nodephone cloud phone system which uses Twilio's telephony APIs and hooks up our phone support with our user data, as well as various internal tools.

Quite a few people have asked us about open sourcing the application. We might well do this, but my experience shows that different users will have very different requirements, so it makes sense to roll your own. This is a guide that will help you do just that.

Choosing the framework: Ruby on Rails + Backbone

I've previously experimented with Node.js and its Express framework and Ruby on Rails for these kinds of applications. Rails is the stand-out choice for three reasons:

  • It's the framework of choice for GoCardless and most other startups too, meaning the expertise is most likely already there
  • Rails provides so much for free, so you spend less time reinventing the wheel and more time building functionality
  • Ruby has an incredibly rich ecosystem of gems, providing functionality from Twilio API access in twilio-ruby to tagging with just one line of code with acts-as-taggable-on

On the frontend, I opted for Backbone.js. Nodephone was my first time working with a JavaScript framework like this, but I'm absolutely converted. Its models and collections made data super easy to handle, and encapsulating presentation logic in bound views helped avoid inevitable callback hell.

Choosing the platform: Heroku

We're experienced at deploying and scaling Rails apps at GoCardless, but a service like this didn't justify giving our dev ops team another service to manage. Instead, we chose Heroku to give us:

  • super simple deployments
  • high availability so users can always reach us

Heroku offers a lot of addons as well, making it easy to add extras like log management, a Redis database or exception tracking in a couple of clicks with no billing complications.

Heroku can be a little expensive. If you're looking for a cheaper alternative and more flexible customisation, a great choice would be Amazon Web Services Elastic Beanstalk, especially with the benefits of the AWS free tier.

Working with external services

One of the great things about building a custom phone system is the freedom to integrate with other services you use.

Nodephone pulls in the profiles of callers from GoCardless itself based upon their phone numbers, as well as working with external apps like Salesforce.

When you're working with Twilio, response times of your app are critical to providing a decent experience for callers. Slow external services, and worse still, applications that inevitably go down, threaten that.

The ever-popular background job library Resqueprovides an ideal solution, allowing tasks depending on background services to be performed asynchronously.

When someone calls in, we look up their phone number in GoCardless to see if we know who they are. To do this, we enqueue a Resque job to perform the API request whilst displaying a progress indicator to the client:

Looking up...

Once the job has finished in the background (which usually takes seconds) the app provides a real-time update to clients using Pusher's web sockets:

response = Gocardless::Merchant.find(args["merchant_id"])
Pusher.trigger('calls', 'lookup', { id: args["call_sid"], merchant: response })

Looked up caller

If GoCardless is slow to respond or out of action, there will only be a slight degredation of service, rather than failed calls.

Avoiding missed calls

We've all called customer support lines, and one of the biggest frustrations is having to wait for ages to speak to someone who can help.

In order to manage bursts of incoming calls, we introduced a queuing system. Since our average call lasts less than 3 minutes, most callers can get through to someone within a few minutes. However, we also wanted to ensure we didn't miss calls from people getting frustrated by longer waits in the queue.

We achieved this with more Resque magic. Once a caller has chosen an option, they're placed in the queue and agents can pick it up by hitting the "Answer" button on their screen. When a call is answered, we mark it as such in our database.

When the call joins the queue, at the same time we schedule a job for 3 minutes time which will check if the call has been answered:

Resque.enqueue_in(3.minutes, ForwardUnansweredCall,

If, 3 minutes from now, it hasn't, it'll ring on all of the phones in the office immediately. This means that every single call is answered within 3 minutes during office hours - but usually much sooner!

Open for business

A particular challenge when building phone systems, as simple as it sounds, is managing opening hours, thanks to complications like time zones. Existing gems that I found like business_time were one step removed from what I needed.

It quickly became clear that I wanted something that didn't already exist, so I built it myself in no time at all. My in_business library lets you set your business hours on a daily basis, and provides simple open? and closed? methods to call in your code:

# Configure the gem with hours of your choice, on a day-by-day basis
InBusiness.hours = {
  monday: "09:00".."18:00",
  tuesday: "10:00".."19:00",
  # ...
  saturday: "09:00".."12:00"
} # => true [if now is within the set hours] DateTime.parse("9th September 2013 08:00") # => false

Taking inspiration from business_time, I added support for the holidays gem, making it possible to take into account public holidays with just two lines of code:

Holidays.between(Date.civil(2013, 1, 1), 5.years.from_now, :gb).
  map{ |holiday| InBusiness.holidays << holiday[:date] } DateTime.parse("25th September 2013 10:00") # => false

An important final addition was adding overrides for the set hours. From time to time, you inevitably want to open and close on an ad-hoc basis. For instance, you might decide to open on a bank holiday when you hadn't planned to.

Overriding business hours

The end result

Twilio, accompanied by popular tools and frameworks and some ingenious thinking makes it relatively simple to build powerful bespoke phone systems which run entirely in the cloud.

Do you love talking to customers and building great tools to track and improve the service you provide?
Join the GoCardless team.

Talking to our customers 2.0

Back in January, I wrote about our customer support phone system, Nodephone. Based on Twilio's telephony platform, it allowed us to collect valuable data about our phone calls with customers.

Since then, GoCardless has grown to become the UK's largest Direct Debit provider. On support, we now generate huge amounts of data every day. We've continued iterating our phone system to help us:

  • Prioritise development by generating user request data
  • Train our staff by recording calls
  • Distribute our product by linking up with Salesforce
  • Deliver great customer support by routing calls efficiently
  • Allow flexible working so support agents can work from across the UK

This post describes how the system works.

Prioritising development by collecting feedback

Around two months ago, we started using our new feature tracking tool to log our customers' thoughts and comments. Often, however, we found feedback from calls was lost, as the process for recording it was still too time-consuming.

With our new phone system, it is extremely simple to log a feature request whilst on a call.

The agent simply enters the information in a textbox on-screen either during the call or immediately after.

It is then submitted instantly to the tracker, complete with the caller's details, so we can keep them up to date on progress or get in touch if we want to delve deeper into their thoughts.

Training our staff with call recordings

Providing great quality support means providing great training for our support agents. Further, to keep close to our customers we insist that everyone in the company spends time on support. That means a lot of people who need training!

One powerful way we've found to help people improve is to play back calls and discuss them. Our new phone system makes that easy - thanks to Twilio, we're able to record every phone call, providing amazing resources for training and monitoring.

Linking up with Salesforce

Many of our potential customers first contact us via our support channels, so we want the handover to our sales team to be as smooth as possible.

Now, we record data about prospects into Nodephone, and this is passed through automatically to our Salesforce CRM using their API.

Recording a prospect

What's more, the process for our sales team of calling back leads is massively simplified with a smart integration between Nodephone and our internal Chrome extension.

Call from Salesforce

Click the "Call" button and your phone rings and connects you straight through. Make some notes or schedule a callback in the window that pops up, and all the data gets passed back through to Salesforce automatically, including the recording. Magic.

Salesforce tagging

This has increased the call volume our sales agents are able to make by about 20% - a real difference for our productivity.

Providing a great customer experience

We want to provide awesome support, and that doesn't include waiting ages for an answer and then being sent around the houses. Our new phone system makes call routing simple, and ensures no-one waits longer than 3 minutes to speak to us.

Now, when customers call, they begin at a quick 10-second menu where we work what they're calling about - whether they're paying someone, already collecting or looking to start taking payments with us.

Once they've chosen an option, they enter the queue and show up in our revamped agent interface.

Queued call

After 3 minutes, if no-one has answered, all calls are forwarded to every phone in the office, ensuring a speedy response.

Allowing flexible working

As GoCardless has grown, we've needed to expand our support team. As we've done so, we've become more and more interested in a distributed support model, where agents work part-time from wherever they are.

Historically, it's always been easy to answer emails from home but not so simple for phone calls. Our new phone system fixes that.

When configuring Nodephone, agents enter the phone number they'd like to use when answering calls. Then, when they hit the "Answer" button, the call is put through to that phone. Agents can choose any phone number or even take the call direct from their laptop using Twilio Client.

More accessible data

In the original Nodephone, we recorded plenty of data for long-term stats, but it wasn't easily accessible on a day-to-day basis. We've taken two steps to fix this.

Firstly, we have a full interface for looking back at previous calls, incorporating recordings, notes and other data.


Secondly, if a caller has called before, at the click of a button you can get an at a glance view of their previous interactions.

Previous calls modal

To sum up

Nodephone 2 is already bringing great benefits to our internal processes and our customers.

If you're more of a technical type, stay tuned - in a few weeks' time, we'll have an in-depth look at the technical implementation of this new app.

Are you excited by building great tools to solve real business problems? Join the GoCardless team.

What do you think?
Share on Twitter

New features in the GoCardless API

This post relates to the Legacy GoCardless API. If you're starting a new integration, you'll need to use the new GoCardless API - for help getting started, check out our guide.

Today we're extending our developer API to include three great new features: payouts, pagination & improved filtering.


You can now query payouts in our REST API, making it possible to build features like bank reconciliation into your integration.

For each payout we'll tell you the amount, the fees charged and the reference that will appear on your bank statement.


Using our new pagination features through the page and per_page parameters, you can cycle through your data in manageable chunks.

This is especially useful for merchants with a large number of customers or payments.


API requests can now be filtered by a wide range of attributes. Full details are available here.

Available now

These additions have already been included in our API libraries.

If you have any questions, don't hesitate to get in touch by emailing us at

in Customers, Motm

Merchant of the Month: Has Bean Coffee

Has Bean Coffee

One of the nicest things about having businesses as GoCardless customers is that we get to see the great use they make of the service. Our 'Merchant of the Month' programme recognises and thanks some of our favourite customers each month for being so awesome.

For December 2012, we've selected Has Bean Coffee, who sell coffee beans and coffee-making equipment online. They've been using GoCardless since November 2011 via KashFlow to collect payments from their wholesale customers conveniently and affordably.

We had been looking for years to find some way of taking Direct Debits. GoCardless have looked after us so much. I need systems that just work and this is what GoCardless gives us.

Stephen Leighton, Managing Director of Has Bean

They also offer coffee subscriptions, and are working on an integration with our API to allow them to take payments for these each month via Direct Debit for a fee of just 1%.

Interested in discovering all the great benefits of GoCardless for yourself? Simply sign up today in just 60 seconds!

in Business, Engineering

Data-driven support

Here at GoCardless, we try to make all our decisions in a data-driven way. Staying customer-centric whilst we do so means making sense of all the interactions we have with our customers.

On the Customer Support team, we spend more time than anyone else speaking to customers. We generate a lot of rich but unstructured data: our email, calls and other interactions. Recently, we’ve been working on new ways to analyse it to improve our support and drive product development.

How things were

When I joined GoCardless we were providing great support but our tracking was ad-hoc. We were manually recording some interactions, but the data was patchy and the process was time-consuming.

Worse still, our support data wasn’t linked with the rest of our data, meaning we weren’t using what we did record. It was buried.

Enter Nodephone

We decided to begin our overhaul of support-tracking with our phone channel, and I set about building a new, metrics-driven system.

We had a good foundation to build on - all external calls come in on a Twilio number and are forwarded to phones in our office. To get good quality tracking I built a system called “Nodephone” to sit in the middle. Built in Node.js with the Express framework and, it’s on the other end of Twilio, responding with TwiML, but it also communicates with GoCardless and a web interface.

Any incoming call is logged and looked up in our merchant records. We then display the call on a simple web interface, where the support agent can see the caller’s name and click straight through to their records. At the end of the call, they can add descriptive tags and notes.

Nodephone interface

Now when customers call we know who they are and can greet them personally! If we don’t recognise their number and we find out who they are on the call, we can save it from the web client for future calls.

All the data entered, alongside the duration of the call, is saved on the merchant’s account for future reference.

A logged call

Data, data, data

All that data we’re collecting has already proved incredibly useful since we can analyse it to find the trends. For example, we want to know between what hours we should provide support, so I graphed the number of calls in different hours of the day over a typical month:

Calls over hours of the day

Clearly the vast majority of people call between 9am and 6pm, so we decided to set our office hours for then. We also use this kind of data to inform recruitment for the customer support team.

We can also see why people are calling - that is, whether they’ve paid via GoCardless (customers), collected money (merchants) or are interested in taking GoCardless payments (prospects) from the tags:

A logged call

As a start-up that prides itself on reducing friction to signup we were amazed to see so many prospects trying to call us. What’s more, they were finding our number from parts of our site designed for our current users. From the data above, we decided to put our number front and centre on our merchant signup pages - check it out here.

The tags we logged on calls from merchants also showed that there was a lack of helpful information on the site to answer common questions, so we’re revamping our FAQs with a whole range of new content.

What’s next

We’ve built a powerful new automated metrics system for logging our phone calls.

Next we’re targeting our other support channels. We’ll be using’s API to analyse our email support, providing the ability to do all sorts of calculations which aren’t possible with the software’s own analytics.

We're also going to build an internal dashboard so anyone can see the headline stats for support in a couple of clicks.

Over time, we want to make all our internal analytics as powerful as we can. If you find problems like this interesting, we’re hiring and would love to hear from you.

in Customers

Spencer Hockey Club

Spencer Hockey Club are one of several sports clubs collecting their membership fees with GoCardless. With over 400 members they wanted a simple way to collect fees, and to keep track of who had paid. As a non-profit they didn't want to pay high fees.

The GoCardless API was the perfect solution. Integrated into the Spencer Hockey Club website, it makes paying and keeping track of whose paid incredibly simple. Mark McDermott, who wrote the integration, describes the benefits:

"We'd wanted a way for members to pay their fees online for a couple of years, but PayPal and the rest were just too expensive. With fees of only 1%, GoCardless changed that. It's made collecting membership fees much less time consuming, so our volunteers can focus on what they do best."

The GoCardless API is incredibly flexible, and with client libraries in PHPJavaPython,Ruby and .NET it's easy for any developer to use.