Login | Register

Gocardless online payment system

Gocardless
https://gocardless.com/

Updated on January 22, 2013
Views: 20423 | Clicks: 149


Website Screenshot



General Information

 

 

 

GoCardless is a next generation payments company. We make it incredibly cheap and easy for anyone to take payments online using the Direct Debit infrastructure.

Based in London, we are a rapidly-growing, highly technical team. Combining years of financial services experience with a customer-driven approach we are transforming online payments.

GoCardless is the easiest way to accept Direct Debit payments online.

We handle the whole process, saving you time and allowing you to focus on what matters most: your business.

 

 


Currencies

GBP

Countries of use

UK

Users

private and business

Fees

TRANSACTION FEE 1% up to £2

SET UP FEE £0

MONTHLY FEES £0

HIDDEN FEES £0

 

The minimum amount is £1 and each transaction is capped at £5000. There are no limits on how many transactions you make.

Funds you have collected are paid directly into your UK bank account

All payments are paid out after 7 working days

Integration approaches

PayLinks, API, Partner Application

Information for developers

GoCardless was written by developers, for developers. Our REST API is powerful but simple, and with our 
client libraries and tutorials you can accept your first payments in minutes.

Docs may be found here

https://gocardless.com/docs

Recent news

Posted on August 14, 2019
What does Strong Customer Authentication (SCA) mean for your business?

What is SCA regulation?

For the most up-to-date analysis and guide to SCA, view The complete guide to SCA for businesses

On 14 September 2019, Strong Customer Authentication (SCA), a new regulation for authenticating online payments, will be rolled out across Europe, as part of the Second Payment Services Directive (PDS2).

(Note: On 13 August 2019 the Financial Conduct Authority (FCA) confirmed that enforcement of SCA in the UK will include a phased 18-month implementation, starting on 14 September 2019 and ending March 2021.)

One of the key aims of SCA is to reduce the incidence of payer fraud and increase security, by introducing two-factor authentication on electronic payments.

Learn more about how SCA works.

What kind of transactions are affected by SCA?

SCA comes into force on 14 September 2019, and will affect any applicable transaction for businesses whose payment service provider is located within the European Economic Area (EEA) and whose customer's bank or card provider is also located within the EEA. If only one of those parties is located within the EEA, the requirement is for them to still use 'best efforts' to apply SCA.

(Note: The FCA released a statement on 28 June 2019 recognising concerns around the industry's preparedness and ability to comply with the requirements for SCA by 14 September 2019.)

SCA does not apply to GoCardless’ Direct Debit payments service. GoCardless is fully PSD2 compliant, and SCA does not apply to payments made through GoCardless as it uses 'paperless' Direct Debit mandates, which are out of scope of SCA.

So, what transactions are affected by SCA?

The main type of transactions that will be impacted are card payments made over the internet. As of next year, all single electronic payment transactions will need to be authenticated by at least two of the three following methods:

  • Knowledge: something only the user knows, such as a password.
  • Possession: something only the user possesses, such as a token or mobile phone.
  • Inherence: something the user is, such as a biometric element (e.g. fingerprint recognition).

According to Mastercard research, just 1-2% of UK online transactions require cardholder authentication to ensure completion (most likely using a password), but this is set to rise to up to 25% from this autumn.

SCA will also apply to some contactless transactions, as a periodic check to ensure the card is being used by its rightful owner. In-store chip and PIN transactions are already compliant.

Exemptions to SCA

Several exemptions and out of scope transactions exist under SCA. These have the potential to benefit businesses with recurring revenue. Notable exemptions or out of scope transactions include:

  • Merchant-initiated transactions
  • Fixed recurring transactions and subscriptions
  • Transactions below €30
  • Trusted beneficiaries (whitelisting)
  • Corporate payments
  • Low risk transactions

For more information, see our detailed list of all key SCA exemptions.

Where do subscription businesses stand?

For subscription businesses taking recurring payments by card, SCA will apply at least to the initial setup of the Continuous Payment Authority for the recurring card transaction. For recurring payments of the same amount, SCA will not need to be applied again. If this amount changes, SCA will typically need to be applied again, unless the payment is initiated by the merchant and the amount being charged is within reasonable expectations of the customer.

In most cases it will be the payer’s bank that facilitates the authentication, with the payer’s payment service provider facilitating the additional steps in the payment journey. Though where this is not the case, payment service providers affected by the regulation (e.g. card providers) will be expected to provide the authentication mechanisms themselves.

The impact on business

Any initiative to tackle the serious problem of fraud should be welcomed, especially since the e-commerce revolution shows no signs of slowing down.

Almost five million people in the UK had money stolen from their bank or credit card account last year, according to Compare the Market. Around £2 billion was taken from about one in ten people in the UK, with online payments being the weakest link – over a quarter of frauds took place online last year.

But the impact of SCA is likely to be felt more widely than in fraud incidence numbers. It could also impact costs and conversion for businesses, says Duncan Barrigan, GoCardless’ VP, Product.

“We’re yet to see the full impact of SCA, but the implications are potentially significant. Businesses are likely to see fewer customer chargebacks, and therefore potentially a reduction in operating costs.”

“Though they could see cost increases elsewhere,” he adds. “For example, if we see a liability shift, where the payer’s service provider is liable for fraud and chargeback costs, we could feasibly see increased fees as a result.”

Balancing risk and conversion

While the implications on operating costs are not yet clear, many businesses are concerned that SCA could be a conversion killer.

Additional payment authentication can introduce friction to customers’ online journeys by requiring additional steps in the payment process.

“For businesses taking payments online, there is a continual balancing act between risk and conversion,” says Duncan. “At the extremes, you could have the most friction-free offering out there; this would be completely open but also vulnerable to fraudsters. Or you could create the most secure service in the world. Ultimately, however, the barrier to entry would be so high that no one would want to use it. It’s important to find the right balance for each business.”

Learn more about how your customers will react to additional security measures.

What SCA means for GoCardless

As we mention above, SCA doesn’t apply to GoCardless’ Direct Debit payments service, and GoCardless is fully PSD2 compliant. We continue to take security and fraud prevention seriously, and GoCardless’ Risk and Product teams are committed to getting the balance between conversion and security right for our customers.

“We believe that technology and data can make it possible to improve the trade-offs merchants face between risk and conversion,” says Duncan. “At GoCardless, we’re working on a payment experience that will enable our customers to benefit from these advances whilst being able to adjust their risk appetite, to suit their business needs.

“Finding a way to reduce risk intelligently with the smallest possible negative impact on conversion rates is the best pay off for everyone involved.”

Fore more information on SCA, see our FAQs.

Read more on Gocardless
Posted on July 29, 2019
RGDP, le bilan un an après : 5 choses que nous avons apprises sur la mise en place d'un programme de confidentialité

Vous vous souvenez quand le RGPD est entré en vigueur l'année dernière et que toutes les entreprises avec lesquelles vous aviez un jour été en contact ont décidé de vous envoyer un e-mail ?

Certaines ont demandé votre consentement, d'autres se sont contentées de vous envoyer un simple message. Le mieux informées, ou celles qui avaient bien pris en compte tous les conseils donnés, n'ont rien envoyé du tout, convaincues que leurs solides pratiques en matière de respect de la vie privée appliquées dans la période précédant le RGPD justifiaient ce non-envoi.

À l'époque, nous avions partagé les détails de notre programme de confidentialité. Un an plus tard, nous avons pu le mettre à l'épreuve. Nous avons découvert ce qui fonctionne et ce qui ne fonctionne pas. Les directives réglementaires, les événements ainsi que la mise en application nous ont permis de mieux comprendre ce qui est efficace pour le RGPD.

Pourtant, depuis l'an dernier, tous les événelents et tables rondes auxquels j'ai participé tournent inévitablement autour d'un seul et même sujet...

Comment gérer la confidentialité à grande échelle ?

Comment se conformer à chacun des éléments prescriptifs du RGPD tout en respectant les principes de la réglementation, et ce, sans rajouter de distractions inutiles à votre activité principale ?

En résumé : comment s'assurer de prendre en compte la vie privée dès la conception (« privacy by design ») ? Les experts en confidentialité ne sont pas des plus nombreux et peu d'entreprises peuvent se permettre d'en embaucher assez pour répondre à toutes les exigences du RGPD. De plus, si les programmes de confidentialité sont conçus séparément des processus opérationnels normaux, il est impossible de le faire évoluer avec l'entreprise.

Dans cet esprit, voici cinq choses que nous avons apprises au cours de l'année passée concernant l'intégration de la confidentialité en entreprise.

1. Parlez la langue de votre entreprise

Tout le contraire de ce que nous avons fait à l'arrivée du RGPD. Pour nous assurer que notre registre des traitements était conforme au RGPD, nous avons préparé et envoyé des questionnaires d'un outil prêt à l'emploi avec toutes les questions auxquelles nous avions pensé à toutes nos équipes de traitement de données. Toutes sauf les bonnes.

« Pouvez-vous identifier une base légale de traitement pour cette activité ? », « Comment respectez-vous le principe de limitation du but pour cette activité ? »

C'est en nous penchant sur notre registre de conformité au RGPD que nous nous sommes rendu compte que nous avions tout faux. « Je ne suis pas sûr » était la réponse la plus fréquente à la plupart des questions !

Pour la version 2.0, nous avons adopté une approche différente et avons décidé de poser uniquement des questions auxquelles nous savions que nos équipes pouvaient répondre, telles que : À quelle fin utilisez-vous ces données ? De quelles données avez-vous besoin pour le faire ? Quels systèmes vous aident à réaliser cette tâche ? Grâce à ça, nous avons établi un registre clair, exploitable et facile à maintenir à jour.

2. Soyez là où les choses se passent

Convoquer un expert en confidentialité à chaque réunion est impossible. Nous ne sommes pas assez nombreux et même si nous pouvions être partout tout le temps, cela ralentirait toute la procédure.

Par conséquent, quasiment tous nos employés devront, à un moment donné, prendre des décisions en rapport avec la confidentialité... comme évaluer un nouveau produit, choisir un nouveau fournisseur ou expérimenter un nouveau modèle de données.

J'ai vu des programmes de confidentialité très bie, conçus échouer simplement parce qu'ils n'ont pas été adoptés par les entreprises.

Lorsqu'on demande aux gens de faire quelque chose en dehor de leurs tâches quotidiennes, ils ont tendance à prendre la « voie de la moindre résistance ». Cela ne veut pas dire qu'ils ne veulent pas faire les choses bien. Cela signifie que même s'ils comprennent ce que nous leur demandons de faire (cf. le point 1), la procédure peut être plus complexe qu'il n'y paraît pour eux.

C'est pourquoi pour pouvoir fonctionner, nous devons nous assurer que les procédures de confidentialité sont solidaires de nos activités habituelles. Comme l'explique notre responsable des données : nous devons faire en sorte que les gens puissent faire ce qu'on leur demande aisément et nous assurer que ce sera très dur pour eux de mal faire. Ce qui nous amène à notre troisième point...

3. Automatisez autant que possible

Cette évolution du domaine de la confidentialité a vu l'émergence d'outil prêt à l'emploi permettant d'automatiser la conformité.

Cependant, beaucoup de ces outils fonctionnent de façon indépendante. Par exemple : un outil de gestion des contrats de traitement de données qui ne peut pas être rattaché à nos fonctions de passation des contrats fournisseurs ; un outil de suivi des requêtes d'accès inutilisable par nos services d'Assistance ou encore un outil d'analyse d'impact sur la protection des données en dehors du cycle de vie du développement du produit.

Problème : lorsque ce type d'outils ne s'intègre pas dans vos activités, vos employés sont forcés de travailler à l'aveugle, ce qui signifie parfois faire mal les choses.

Pour bien faire, nous pensons qu'il faut commencer par vous pencher sur votre entreprise et ses besoins : À quoi ressemble votre quotidien ? Quels documents créez-vous, quels outils utilisez-vous, quelles sont vos étapes de prise de décision ?

Avec ces informations, vous pourrez vous poser les bonnes questions au bon moment et serez en mesure de faire remonter vos questions et besoins à l'équipe de protection de la vie privée si nécessaire.

Par exemple, lorsque nos équipes de données créent une nouvelle fonctionnalité, notre procédure leure demande automatiquement d'identifier un objectif commercial, il est impossible de lancer la création de cette fonctionnalité. Si l'objectif n'est pas répertorié dans le registre, cela signifie qu'il faut réexaminer la confidentialité afin d'intégrer ce nouveau type d'objectif.

Cette procédure nous fournit également une piste d'audit que nous pouvons tester pour nous assurer que les bonnes décisions sont prises.

4. Méfiez-vous des remèdes miracle

L'automatisation des procédures de confidentialité peut finir par vous nuire. Certaines entreprises utilisent des listes de contrôle pour garantir l'évolutivité de leurs programmes de confidentialité. Mais cette approche peut se retourner contre vous.

Mal appliquées, les couches de bureaucratie privent les employés de leur pouvoir, les empêchent d'être responsables de leur impact sur la vie privée et génèrent des risques inattendus (« cela ne figurait pas sur la liste de contrôle donc ça ne peut pas être un problème »).

Nous avons veillé à ce que nos procédures soient simples et avons mis l’accent sur la formation et l’orientation de nos équipes.

Par exemple, nous avons créé une formation pour nos responsables Produit et Fonction. Cette formation leur fournit les ressources nécessaires pour travailler à l’intégration de la confidentialité dans nos produits de bout en bout.

Parmi toutes ces ressources, l’une d’entre elles a été particulièrement utile dans la définition de produits et l’évaluation de l’impact sur la confidentialité : une taxonomie sur-mesure des risques de confidentialité qui permet d’orienter les discussions sur la réduction des conséquences non intentionnelles ou illégales de l’utilisation de données à caractère personnel.

5. Écoutez ce que vos programmes vous disent

Le RGPD permet aux personnes concernées d'exercer leurs droits auprès du contrôleur des données. Les requêtes d'accès et de suppression sont les deux requêtes que nous recevons le plus souvent.

Afin de ne pas surcharger notre équipe de confidentialité, nous avons décidé qu’elles seraient d’abord traitées par nos agents du service clientèle dans leurs propres outils (macros Zendesk et Centre d’assistance) avant d’être envoyées dans notre logiciel de demande de droits pour en assurer le suivi.

Nous sommes fiers de dire que cela a très bien fonctionné. Premièrement, nous ne traitons pas ces demandes de façon isolée. Envoyer d’abord ces requêtes à l’Assistance permet leur traitement par les personnes les mieux formées pour identifier et résoudre les problèmes sous-jacents (grâce aux formations et ressources fournies par l'équipe de protection de la vie privée).

Deuxièmement, notre équipe d’Assistance possède une grande expérience des métriques et des indicateurs de performance clés. L'utilisation de leurs outils nous permet de suivre de près les requêtes d’accès, ainsi que d'autres plaintes, questions et incidents.

La rapidité et l’efficacité avec lesquelles nous pouvons traiter une requête d’accès ou de suppression nous en dit long sur la santé de notre programme de confidentialité. D’ailleurs, le suivi de ces métriques est l’un de nos principaux indicateurs de risque.

Nous suivons également les taux de désabonnement marketing, les analyses de risque des fournisseurs ainsi que le temps nécessaire pour répondre aux demandes juridiques liées aux données.

Ainsi, nous comblons nos lacunes, nous améliorons progressivement notre programme et nous nous conformons au principe de responsabilité, le concept phare du RGPD.

Et vous, quels conseils avez-vous pour mettre en place un programme de confidentialité ? Rejoignez-moi sur LinkedIn pour continuer cette conversation.

Read more on Gocardless
Posted on July 17, 2019
What does SCA mean for recurring payments?

If you’re a merchant based in the European Economic Area (EEA), you might already be aware of Strong Customer Authentication (SCA). If you’re not, we’ve written a brief overview of what the new European PSD2 law means for subscription businesses. In a nutshell:

  • SCA is part of European PSD2 regulations, which aim to increase the security of electronic payments and account management, as well as reduce payment fraud
  • SCA comes into effect on 14 September 2019
  • If your business uses a European payment provider to serve customers within the EEA, SCA requires additional proof of identity from your customers when they make certain types of payments

Many businesses are concerned that the extra security measures posed by SCA will increase friction at checkout, leading to a drop-off in conversion. For businesses that take recurring payments, there are broadly three major factors that determine how SCA will affect you. And there are a number of exemptions and out of scope transactions that could help minimise impact on conversion rates.

Ahmed Badr, General Counsel at GoCardless, explores these areas in the videos below, as well as recommending the next steps businesses should take.

How does geography factor into SCA?

While your business and your payment service provider must allow for SCA to be applied, it is your customer’s bank (or card issuer) that will apply the authentication. Looking specifically at payments, and not other areas that SCA is required such as when accessing a payment account, the legislation is not limited in its geographical reach.

In recent guidance, the body responsible for SCA specifications has confirmed that SCA is only strictly required when both a merchant’s payment provider and customer’s bank (or card issuer) are located within the EEA. When only one of those parties is located within the EEA, it must use “best efforts” to apply SCA for payments that require it.

In practice, this means is that if a merchant located outside the EEA is using an EEA-based acquirer, that merchant can still expect the acquirer to support SCA for transactions that take place with EEA-based issuers.

How does payment method factor into SCA?

How you choose to accept payment from your customers impacts how SCA will affect you. SCA primarily targets electronic payments that are initiated by your customer, and that are processed instantly. This means many credit card and debit card payments, as well as bank transfers, will be subject to SCA.

Direct Debits or bank debits, on the other hand, are out of scope of SCA. This includes payments set up and made through GoCardless. The key difference with these payments is that the customer’s payment details are collected without the involvement of the customer’s bank, and this is being done at a different point in time to the payment being processed.

These payments also typically have much lower rates of fraud than card payments or bank transfers.

How does the type of billing factor into SCA?

Broadly speaking, recurring purchases can be billed in one of three ways:

  1. Invoicing - Your customer pays you variable amounts, at regular or variable intervals, with no fixed end date. (E.g. Professional services.)
  2. Subscriptions - Your customer pays you fixed amounts, at fixed intervals, with no fixed end date. (E.g. Gym membership.)
  3. Instalments - Your total product or service cost is broken down into fixed amounts, for your customer to pay at fixed intervals, with a fixed end date. (E.g. Loan repayments.)

Generally speaking, SCA applies to recurring purchases when either the amount or frequency of payments is changing. With invoicing, the amount varies, and thus every payment a customer initiates is subject to SCA. With subscription and instalment payments, only the first payment will be subject to SCA, as the subsequent payments are fixed amounts at a fixed frequency.

Which payments are out of scope of, or exempt from, SCA?

For businesses taking recurring payments, there are a few key exemptions and out of scope areas to be aware of.

Merchant-initiated transactions (MITs)

These are payments from your customer where you as the business initiate the transaction. In these cases, your customer must have given you advance authority to take recurring payments from them for a specified product or service.

Both card payments and Bank Debits like Direct Debit can be MITs. For card payments, SCA will typically also need to be applied when your customer provides you their payment details. However, all following transactions will be out of scope of SCA.

For electronic ‘paperless’ Direct Debits, such as those handled by GoCardless, SCA is not required even during mandate setup - due to the fact that the customer’s bank is not involved at the point of mandate setup. These types of payment also typically present a lower risk of payment fraud.

Learn more about merchant-initiated transactions.

Trusted beneficiaries (“whitelisting”)

As part of SCA, banks and card issuers will allow their customers to create a whitelist of businesses they trust, and for whom they are happy not have SCA applied. If your customer decides to add your business to their list of trusted beneficiaries, SCA will only need to be applied once - at the point of adding you to the whitelist. All of their future payments to you can then be processed without SCA.

Low value transactions

When your customer makes a payment to you that is under €30 (or its equivalent), it may be exempt from SCA.

There are two notable caveats to this. First, every sixth low value transaction your customer makes, SCA will need to be applied. This isn’t just every sixth payment they make to you, it covers all payments they make anywhere.

The second caveat is that if a cumulative payment total of €100 (or its equivalent) is reached before that sixth payment, SCA will need to be applied at that point.

Low risk transactions

If your payment service provider’s overall fraud rates are below certain thresholds, your customer’s bank can choose to not apply SCA under certain transaction values. For values above €500, however, this exemption does not apply.

Take note...

It’s worth noting that while banks are allowed to support exemptions under SCA, they aren’t obliged to. And even if a customer’s bank does support exemptions and a purchase meets the requirements of an exemption, they are still able to apply SCA if they wish. As such, you cannot rely on exemptions to opt out of preparing your payment flows for SCA ahead of September.

Learn more in our detailed list of all key SCA exemptions.

What next?

Take some time to map out your payment flows. Make sure you’re aware of every use case in your business and understand how SCA will apply to each of them.

While it is ultimately your customers’ bank or card issuer that will control SCA, the checkout flow on your website will need to capture the additional proof of identity from your customers. And, your payment service provider will need to be able to facilitate the secure transfer of this data to your customer’s bank or card issuer.

When you’ve mapped out all of your payment flows and understood the use cases where SCA applies, note any necessary changes you’ll need to make ahead of September to be compliant with the regulation. Also make sure you double check with your payment service provider to ensure they will be facilitating your compliance.

Over the coming months, we’ll be publishing more updates about SCA for businesses taking recurring payments. To ensure you don’t miss out, follow us on LinkedIn, Facebook, or Twitter, and keep an eye on our blog, guides, and support centre.

For now, make sure you read our comprehensive guide to Strong Customer Authentication.

(Note: On 13 August 2019 the Financial Conduct Authority (FCA) confirmed that enforcement of SCA in the UK will include a phased 18-month implementation, starting on 14 September 2019 and ending March 2021.)

Read more on Gocardless
Posted on July 15, 2019
Qu'est ce que l'Authentification forte du client ? (2 minutes)

Qu'est-ce que l'Authentification forte du client (ou SCA, pour Strong Customer Authentification) et quelles sont ses conséquences pour les commerçants au Royaume-Uni et en Europe ?

Si vous n'en avez pas encore entendu parler, vous êtes loin d'être seul. Selon l'étude de Mastercard réalisée sur des commerçants européens à la fin de l'année 2018, 75 % d'entre eux ne savent pas ce qu'est la SCA et ce qu'elle implique pour eux. Pourtant, la SCA devrait entrer en viguer en septembre 2019 et amener des modifications importantes dans les conditions de sécurité des achats en ligne.

Dans la vidéo ci-dessous, le Responsable marketing produits de GoCardless, Timmy Neilsen, vous donne un aperçu de deux minutes de la SCA et ses conséquences pour les commerçants en Europe et au Royaume-Uni.

À retenir

Qu'est-ce que l'Authentification forte du client exactement ?

En résumé, la SCA fait partie d'une législation à l'échelle européenne : la directive DSP2.

En pratique, il s'agit d'une double authentification qui sera désormais demandée pour tout achat en ligne. Lorsque votre client achètera un produit de votre entreprise sur Internet, il devra fournir deux types de données d'identification supplémentaires, en plus de ses données de paiement. Ces données requises pourront prendrela forme suivante :

  • Un élément que votre client connaît, comme un mot de passe
  • Un élément que votre client possède, comme un numéro de portable (qui pourra recevoir un code à usage unique)
  • Un élément propre à votre client, comme une empreinte digitale

Dans quels cas l'Authentification forte du client s'appliquera-t-elle ?

La SCA concernera toute transaction impliquant des parties situées toutes deux dans l'Espace économique européen (EEE), aussi bien le fournisseur de services de paiement l'entreprise que la banque du client final.

Si l'une de ces parties est située en dehors de l'Europe, la règle exige du fournisseur de services de paiement basé en Europe qu'il déploie « tous les efforts possibles » pour appliquer la SCA.

En quoi l'Authentification forte du client m'affecte-t-elle ?

La SCA sera appliquée par la banque du client, mais il est probable qu'elle soit gérée par un lecteur da carte. Cependant, en tant que commerçant, vous devez disposer d'un processus de paiement adapté.

Votre fournisseur de services de paiement sera certainement préparé, mais il serait judicieux de lire toute publication qu'il a pu produire sur ce sujet afin de comprendre son approche et ce que cela implique pour vous.

L'Authentification forte du client va-t-elle baisser mon taux de conversion ?

Ce paramètre inquiète de nombreuses entreprises. En effet, il se peut que la SCA complique l'expérience de paiement aux yeux de votre client, entraînant une chute du taux de conversion.

Cependant, la SCA ne s'applique pas à de nombreux cas, où la double authentification peut ne pas être requise, par exemple :

  • Les paiements considérés comme étant à faible risque, selon un ensemble de critères définis
  • Les paiements inférieurs à 30 €
  • Les abonnements d'un montant fixe

Read more on Gocardless
Posted on July 10, 2019
Track flaky specs automatically using this simple tweak in RSpec builds

GoCardless’ Product Development team recently had a summer Hackathon – during which, we developed a simple tweak for our RSpec builds to track flaky specs (or, intermittently failing tests).

The problem

There’s a lot said about flaky specs because they often lead to wasted time and effort. At one point or another, we have probably all been about to merge or deploy changes and a required build check stops us – only because a flaky spec acted-up!

When this happens, there’s no option but to retrigger the build to see it go green to unblock the change. We try and remind ourselves to write up a ticket and come back to this flaky spec but this isn’t always possible when you have a number of other things you are working on.

So, we needed an automated way to keep track of flaky specs so that they are visible and we are reminded about fixing them.

The solution

We depend on RSpec’s --only-failures option which reruns only failures from the last run. This option requires an RSpec configuration to persist spec execution results to a file:

RSpec.configure do |config|
  config.example_status_persistence_file_path = "/tmp/ci/example_status.txt"
end

Here’s what our build script looks like:

build_exit_status=0

execute_rspec {
  bundle exec rspec
  build_exit_status=$?
  mv /tmp/ci/example_status.txt /tmp/ci/example_status.txt.run1
}

execute_rspec_failures_only {
  bundle exec rspec --only-failures
  mv /tmp/ci/example_status.txt /tmp/ci/example_status.txt.run2
}

track_flaky_specs {
  // find failing specs from example_status.txt.run1
  // check if they passed in example_status.txt.run2
  // if it passed on second run, create a ticket to fix this flaky spec
  // if it failed, the build fails because this is more likely to be a valid breakage
  grep "| failed" /tmp/ci/example_status.txt.run1 | cut -d" " -f1 \
    | xargs -I{} grep -F {} example_status.txt.run2 | grep "| passed" | cut -d"[" -f1 | uniq \
    | xargs -I{} bundle exec rake create_ticket\["Flaky spec: {}","Build: $BUILD_URL"\]
}

execute_rspec || (execute_rspec_failures_only && track_flaky_specs)

exit $build_exit_status

The create_ticket rake task creates a ticket to remind us to fix this flaky spec. If there’s an existing ticket with that title, it just drops a comment on it about a recurrence. This tells us how often a flaky spec affects developers.

GoCardless teams have a rotating First Responder role. A First Responder responds to tickets in the general Ticket Inbox coming from our deployed applications or teams outside of Product Development.

The flaky spec ticket is created in the Ticket Inbox. From here, the First Responder can assign it to the team that is best-placed to fix it.

The results

While we haven’t been running this on CI for long, we are already seeing the benefits.

The automatically created tickets have given us more visibility over flaky specs that would have otherwise gone unnoticed. Developers have actively fixed flaky specs they inadvertently introduced knowing they’re regularly affecting fellow developers.

Now that we have a list of flaky specs, it gives us a chance to identify patterns behind misbehaving specs.

One such pattern we identified was related to our feature flagging library. It had been configured incorrectly to use in-memory storage. This resulted in feature flags being True in specs not expecting them to be enabled at all.

If you happen to try this out in your builds, we’d love to hear how that went @GoCardlessEng.

Read more on Gocardless

See all news of Gocardless

Gocardless Comments:

Add your comment
Pages: 1 2 3 4 5 6 7 8 9 10 from 10