235 systems total
Here you can find news gathered from systems presented in our directory
View all news of Gocardless
Posted on July 15, 2019
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.
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 :
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.
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.
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 :
View all news of Gocardless
Posted on July 10, 2019
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).
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.
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.
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.
View all news of Gocardless
Posted on July 9, 2019
We’re delighted to welcome DocuSign Inc as a new customer – and one of a growing number of SaaS businesses choosing GoCardless to power their global subscription payments.
DocuSign helps organisations connect and automate how they prepare, sign, act on, and manage agreements. Its customers will now be able to subscribe using GoCardless, as an alternative to credit/debit cards and PayPal.
“We want our global customers to have access to simple and easy payment methods when purchasing DocuSign,” said Robin Joy, SVP of Digital, Demand & Web Sales at DocuSign.
“We’re delighted to be working with GoCardless to offer Bank Debit as a payment option throughout the UK and Europe, to ensure customers are able to complete quick and easy transactions with DocuSign.”
Hiroki Takeuchi, CEO of GoCardless, commented: “GoCardless' global platform provides a new way for businesses to collect internationally – one which meets changing payer preferences and saves businesses time, hassle and money.
“Historical payment options designed for ecommerce are just not fit for purpose when it comes to collecting recurring revenue – and a binary choice between cards and PayPal can be a blocker on growth.
Businesses are realising that there is a better way to solve their recurring payment needs.”
In the first phase of the roll out, a significant portion of DocuSign’s new customers in Europe have chosen to pay by GoCardless when given the option.
This echoes findings from the 2019 Global Payment Preferences research report conducted by YouGov and GoCardless, which shows that at least one third of consumers are likely to choose Bank Debit/Direct Debit to pay for online subscriptions. The report surveyed more than 12,000 consumers across 10 global markets.
Further research by GoCardless and YouGov on business payer preferences across these same markets, shows that in the UK, 44% of businesses were likely to pay by Bank Debit/Direct Debit: more than corporate cards, bank transfer and digital wallets.
DocuSign is the latest in a number of global subscription businesses that have chosen GoCardless to provide direct debit payments, including TripAdvisor and SurveyMonkey.
DocuSign will access GoCardless through Zuora, fully-automating their billing, collections, quoting, revenue recognition, and subscription metrics.
View all news of Gocardless
Posted on July 5, 2019
On Thursday 27 June between 12:41 and 13:21 (BST), we experienced a 40 minute service outage.
Our 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. We know how important reliability is to you and we take incidents like this extremely seriously.
We’ll be completing a more detailed internal review of the incident in the coming weeks but we want to provide more details on exactly what happened and what we’re doing about it.
Our dashboard displays a merchant’s balance, letting them know how much money they’ve collected recently and how much they can expect in their next payout.
We compute these balances whenever a merchant logs into their dashboard and cache them. This means we temporarily store them so that if the user reloads the page, we can quickly show them the existing balance, without them having to wait.
We keep these cached balances in a data store called Redis.
On Thursday at 12:17, as part of an internal reporting exercise, we ran a one-off task to compute balances for all our merchants. As each balance was computed, it was also automatically cached, resulting in a significant increase in the number of cached balances stored in Redis, compared to what we’d usually expect to see.
By 12:40, the machine running Redis had almost used up all its available memory, which caused it to automatically restart.
We’ve previously put measures in place to ensure that our service can cope if Redis isn’t available. This should have meant that aside from a slight delay in updating balances, our service should have remained online.
Instead our API, dashboard and payment pages experienced downtime.
At 12:42, our monitoring flagged that our API was offline and by 12:43, our on-call engineers had received an alert and began investigating.
They quickly established that Redis was experiencing issues but it wasn’t immediately obvious what was causing them, or why it had taken the rest of our service offline with it.
After some further investigation, we established that Redis was attempting to bring itself online automatically but that it was taking a long time to do so. Our systems assumed this meant it wasn’t working properly and so it was rebooted, again, preventing Redis from loading successfully.
Observing this, our infrastructure engineers concentrated on trying to break the cycle by updating our monitoring to allow Redis enough time to come back online fully.
This was successful and at 13:24 Redis came back online. By 13:26, the rest of our service was restored.
However, once Redis came back online, it still contained previously cached balances; meaning we were still at risk of further downtime. The team monitored the situation closely and, set about exploring how best to clear the existing values from Redis to buy us back more capacity without causing any further downtime.
Unfortunately, whilst we were doing this, at 17:00, Redis once again exceeded its memory limit, resulting in a further 4 minutes of downtime. Shortly after, we cleared the unnecessary balances, putting Redis back into a stable state.
We’ve already learned a few valuable lessons from this experience.
Having identified why our service failed when Redis became unavailable, we've applied a fix that means we'll be unaffected if this was to happen in future, and have plans to continually verify this on an on-going basis.
In the next few days, we’ll also be running a more formal “post-mortem” internally, to examine both the incident and our response to it in further detail.
View all news of Gocardless
Posted on June 26, 2019
Today, we released research from a GoCardless survey into consumer attitudes around security and convenience when buying online.
The findings show that UK consumers are torn between valuing convenience and security when making purchases online – but they value “speed and ease of payment” more than their European counterparts.
The GoCardless study, 'Security vs convenience in the payment experience', asked 4000 consumers in the UK, France, Germany and Spain, about their attitudes and behaviours to online shopping, and found that:
The research is published ahead of the introduction of Strong Customer Authentication (SCA); a new, European-wide, two-stage verification process coming into force from September 2019 as part of PSD2.
(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.)
As a result, shoppers will have to provide two sets of security information – that could be a password or PIN, biometric information, or device information like a mobile number – to authenticate an online purchase.
Our survey suggests business will need to manage the changes to checkout flows carefully to avoid a drop off in conversion:
We also asked payers how they felt about giving away different types of security information, described by SCA. A significant number of UK payers were uncomfortable giving out personal data:
Interestingly, the need to give away complex security information makes as many people feel suspicious as safe (40%).
Protecting shoppers from fraud when they pay online is crucial, and new regulation which achieves this should be welcomed.
The flipside is that these measures, if implemented badly, could significantly disrupt consumers and lead to a significant conversion hit for businesses.
Businesses need to work with their payment providers to find the right balance between security and convenience at checkout.
SCA was primarily designed to increase the security of online payer-initiated transactions, and to reduce the problem of payer fraud. To understand the likely business impact of SCA, view the complete guide to Strong Customer Authentication (SCA).
View all news of Gocardless
Posted on June 18, 2019
Remember when GDPR was coming into effect last year, and every organisation we’d ever had contact with decided to send an email?
Some asked for our consent, some just checked in. More knowledgeable companies, or those who had taken good advice, didn’t email at all, trusting that solid privacy practices in the lead-up to GDPR made it unnecessary.
At the time, we shared details of our privacy programme; one year on, we’ve had a chance to experiment. We’ve learned some of what works, and what doesn’t. And regulatory guidance, events and enforcement have started to shed light on what good looks like for GDPR.
Yet the discussion at every privacy event I’ve attended in the last year, and every panel I’ve spoken on, inevitably turns to one topic...
How do you achieve privacy at scale?
How do you comply with every prescriptive element of GDPR, and meet the principles of the regulation, in a way that minimises unnecessary distraction from your core business? In short: how do you create ‘privacy by design’?
Few companies hire enough people with ‘privacy’ in their job titles to meet all the requirements of GDPR. It follows then that if privacy sits on top of normal business processes, it won’t scale.
With that in mind, here are five things we’ve learned over the last year about embedding privacy in the business.
We didn’t get this right the first time around. To build our GDPR-compliant register of processing activities, we used questionnaires sent out from an off-the-shelf tool.
We asked all our data processing teams a lot of questions – all the wrong ones, as it turns out. “Can you identify a lawful basis of processing for this activity?” “How are you meeting the principle of purpose limitation for this activity?”
We knew we had gotten it wrong when we looked at our GDPR-compliant register and saw dozens of different variations on the term “not sure”!
In v2.0, we took a different tack. We asked the business only the questions we knew they could answer, like – what are you trying to do with the data, what data do you need to do it, what systems help you accomplish it. As a result, our updated register is clear, actionable and easy to keep up-to-date.
We can’t have a privacy expert in every meeting – there aren’t enough of us, and even if we could be everywhere all the time, it would just slow things down.
But that means almost every GoCardless employee will at some point have to make decisions that have a privacy impact . . . like scoping a new product, choosing a new supplier, or training a new data model.
I have seen even very well-designed privacy programmes fail when they just aren’t adopted by the business.
When people are asked to step out of their day-to-day role, they’ll tend to take the path of least resistance. It’s not because they don’t want to do the right thing! But even if they understand what we need them to do (and see point 1), the process we’ve created might just make it hard for them to do it.
Privacy processes can’t stand alone, they need to be part of business as usual. Our head of data puts it nicely: we need to make it really easy for people to do the right thing and really hard for them to do the wrong thing. Which leads to...
As the privacy field matures, we’re starting to see tools offering out of the box automation and compliance.
The problem with many of these is that they offer a standalone experience: a tool for managing data processing agreements that doesn’t sit within a broader supplier contracting function; a tool for tracking data subject access requests that can’t be used by Support, a data protection impact assessment that isn’t part of the product development lifecycle.
Privacy processes that don’t fit within a broader business context will take people out of their day-to-day. Then, if they’re done at all, they aren’t done well.
We’ve found it more effective to start with the business – what does their day-to-day look like? What documents do they create, what tools do they use, what are their decision-making points?
Those are opportunities to ask the right questions at the right time, and to be able to escalate to the privacy team where necessary.
For example, when our data teams build a new feature, they’re prompted from within the process itself to identify a business purpose from our (now clean and up-to-date) GDPR register. If a business purpose isn’t present, the model can’t be built. And if there isn’t a suitable purpose listed in the register, then it’s an indication that something new is happening that needs privacy review.
The process also gives us an audit trail that we can test to make sure the right decisions are being made.
Automating privacy processes can end up working against you. Some companies make programmes scalable using checklists. But this approach can backfire.
Layers of bureaucracy badly applied disempower employees, keep them from being accountable for privacy impacts, and lead to unexpected risks (“this wasn’t on the checklist, so it must not be a problem”).
We’ve been careful to keep our processes simple, and focused heavily on training and guidance for our teams.
For example, we’ve launched training for our product managers and functional leads, giving them the resources to think about building privacy into our products from start to finish.
One resource has been a particularly useful part of our product scoping documents and privacy impact assessments: A tailored taxonomy of privacy risks that helps guide thoughtful conversations about minimising unintended or unlawful consequences from the use of personal data.
GDPR allows data subjects to exercise their rights with the data controller. The two rights requests we see most often are subject access requests and subject deletion requests.
Early on, we made a decision that subject rights requests don’t go straight to our privacy team. They are handled first by our customer support agents using their own tools (Zendesk macros and our Support Hub), before they go to our rights request software to track to completion.
This has been very successful for two reasons: First, these requests don’t happen in isolation. Sending the requests to Support first brings them to the people who are best trained to identify and resolve the underlying problem (supported of course by training and resources from the privacy team).
Second, our Support team has an enormous amount of experience with metrics and KPIs. Using their tools allows us to keep close track of SARs as well as other complaints, questions and incidents.
How quickly and efficiently we can handle an access or deletion request tells us a lot about the health of our privacy programme, and tracking these metrics is one of our key risk indicators.
We track other risk indicators too, like marketing unsubscribe rates, supplier risk ratings and time to respond to data-related legal tickets. These tell us a lot about where the gaps are and allow us to optimise.
That feedback allows us to make constant incremental improvements to the programme, and also helps us meet the principle of Accountability, the heart of GDPR.
What tips do you have for scaling a privacy programme? Join me on LinkedIn to continue the conversation.
View all news of Gocardless
Posted on June 13, 2019
What is Strong Customer Authentication (SCA) and what does it mean for merchants in the UK and Europe?
If you haven’t heard of it yet, you wouldn’t be in the minority - Mastercard’s survey of European merchants in late 2018 found that 75% were unaware of what SCA is and what it means for them. As it stands, however, SCA will be coming into effect in September 2019 and it poses significant changes to the security requirements of online purchases.
(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.)
In the below video, GoCardless’ Product Marketing Manager Timmy Neilsen provides a 2-minute overview of what SCA is and how it’s affecting merchants within the UK and Europe.
In short, SCA is part of a European-wide legislation, PSD2.
In practice, SCA means two-factor authentication will now be required for online purchases. That means when your customer purchases something from your business over the internet, they need to offer two further pieces of identifying information on top of their payment details. This info can take any of the following forms:
SCA will impact any applicable transaction where both the business’ payment service provider and the end-customer’s bank are located within the European Economic Area (EEA).
If one of these is outside Europe, the requirement is for the payment service provider in Europe to use ‘best efforts’ to apply SCA.
SCA will be applied by the customer’s bank but is likely to be facilitated by a card processor. However, it’s necessary that you as a merchant have a payment flow which allows for this.
Your payment service provider will likely be on top of this, but it’s worth reading any materials they’ve published on the topic to understand their approach and how it affects you.
This is a concern for many businesses. And it is certainly possible that SCA may complicate the checkout experience in your customers’ eyes, leading to a conversion drop-off.
However, SCA has a number of exemptions built-in where two-factor authentication may not be required, for example:
View all news of Gocardless
Posted on June 4, 2019
Comment les consommateurs veulent-ils payer leurs abonnements, leurs factures et leurs versements ? La réponse à cette question pourrait bien être la clé de l’optimisation du taux de conversion pour les entreprises. Connaître les méthodes de paiement avec lesquelles vos clients sont le plus à l’aise, et celles avec ils préfèrent payer, peut avoir un impact considérable sur la génération de recettes pour les entreprises encaissant des paiements récurrents.
Avec l'aide de YouGov, nous avons sondé 12 785 consommateurs sur 10 marchés (Royaume-Uni, France, Allemagne, Espagne, Danemark, Suède, États-Unis, Canada, Australie et Nouvelle-Zélande) pour découvrir leurs préférences de paiement en 2019. L’étude portait sur quatre types de paiements récurrents : abonnements traditionnels, abonnements en ligne, factures (charges) et versements. Nous avons sélectionné ces marchés car, à eux tous, ils représentent plus des deux tiers du volume de paiements récurrents dans le monde.
Le rapport indique clairement que tout dépend du pays des consommateurs. Par exemple, les paiements par chèques sont beaucoup plus importants en Amérique que dans le reste du monde. La Chine, quant à elle, privilégie fortement les paiements mobiles. Les paysages technologiques et culturels varient énormément d’un pays à l’autre et ils influencent beaucoup les préférences de paiement des consommateurs.
Voici un aperçu de ce que ce rapport nous a appris :
En moyenne, 40% sont « très peu susceptibles » d’utiliser des cartes de crédit et 29 % des cartes de débit.
Les Canadiens sont plus susceptibles d’effectuer leurs paiements récurrents par carte de crédit que n’importe quelle autre nationalité interrogée : 27 % sont « très susceptibles » de les utiliser pour des abonnements traditionnels (salle de sport par exemple) et 26 % pour leurs factures et abonnements en ligne. Les Américains sont presque aussi enthousiastes : la carte de crédit est leur méthode préférée pour les abonnements traditionnels et en ligne.
En dehors de l’Amérique du Nord, les consommateurs de tous les pays sondés ont déclaré qu’ils étaient « très susceptibles » de payer leurs factures de la manière traditionnelle : par prélèvement bancaire (aussi connu sous le nom de prélèvement automatique en Europe).
Sur 9 des 10 marchés sondés, environ un tiers des consommateurs ont déclaré qu’ils choisiraient probablement de payer leurs abonnements en ligne par prélèvement bancaire. Si l’on se penche sur les 44 des principaux sites web d'abonnement mondiaux, un seul propose le prélèvement bancaire en tant qu'option de paiement (et uniquement en Allemagne).
Au Danemark, 44 % des consommateurs ont répondu qu’il était « très peu probable » qu’ils utilisent cette méthode pour des achats récurrents. À l’opposé, 16 % des consommateurs espagnols ont déclaré être « très susceptibles » d’y avoir recours.
Comprendre les préférences d’achat des consommateurs est essentiel pour les entreprises B2C. Les consommateurs ont désormais un vaste choix de méthodes de paiement et ils sont disposés à l’utiliser ou aller ailleurs s’ils découvrent qu’ils ne peuvent pas payer comme ils le souhaitent.
Ce qu’il faut retenir de ce rapport, c’est qu’il n’existe pas de méthode globale « one size fits all » (ou approche unique) pour les paiements récurrents mais il n’y a pas non plus de solution unique qui conviendrait aux consommateurs de tous les pays, toutes les tranches de revenus ou tous les groupes d’âge. Avec les bonnes informations, vous pouvez mettre en place les meilleures solutions pour votre entreprise ainsi qu’optimiser votre taux de conversion.
View all news of Gocardless
Posted on June 4, 2019
How do consumers want to pay for subscriptions, memberships, bills and instalment plans? The answer to this question can hold the key to conversion rate optimisation for businesses. Knowing which payment methods your customers are comfortable with, and which they actively prefer to pay with, can have a significant impact on revenue generation for businesses taking recurring payments.
We partnered with YouGov to ask 12,785 consumers across the UK, France, Germany, Spain, Denmark, Sweden, USA, Canada, Australia, and New Zealand what their payment preferences are in 2019. The research covers four typical recurring purchase use cases: traditional subscriptions, online subscriptions, household bills, and instalments. Together, these markets represent more than two-thirds of the world’s recurring payment volume.
Want the full report? Download your FREE copy here. Or watch Duncan Barrigan, VP Product at GoCardless, deliver the foreword on video below.
As the data shows, the answer to this question depends on where your customers live. If you take a look at existing research, for example, you’ll see that cheques are more relevant in America relative to the rest of the world. While in China, mobile payment transactions are huge. Cultural and technological landscapes can differ drastically from country to country. And these can heavily influence consumers’ payment preferences.
Let’s take a look at some key insights from the data…
On average, 40% of Germans are ‘very unlikely’ to use credit cards (and 29% feel the same about debit cards).
Canadians are more likely to make recurring payments on credit cards than any other nationality surveyed. 27% are ‘very likely’ to use them for traditional subscriptions (such as gym memberships) and 26% are for household bills and online subscriptions.
Americans are almost as keen – credit cards are their preferred method for both traditional and online subscriptions.
Outside North America, consumers in every country surveyed said they were ‘very likely’ to pay their household bills the traditional way – by Bank Debit (or as Europeans tend to call it - Direct Debit).
In 9 out of 10 markets surveyed, around one-third of consumers said they were likely to choose Bank Debit to pay for online subscriptions. And yet, looking at the top 44 global subscription websites, only 1 offered Bank Debit as a payment option (and only in Germany).
In Denmark for example, an average of 44% of consumers were ‘very unlikely’ to use a digital wallet to make any kind of recurring purchase. Whereas in Spain, an average of 16% were ‘very likely’ to.
For B2C companies, understanding consumer purchasing preferences is critical. Having been given a wide choice of payment methods, consumers are minded to exercise it - and they may well go elsewhere if they can’t pay the way they want.
If there’s anything to take away from this research, it’s that there is no ‘one size fits all’ global offering for recurring payments. There is no single solution that will suit all your customers across every country, income bracket or age group. But armed with the right data, you can implement the best solutions for your business, and optimise your conversion.
View all news of Gocardless
Posted on May 31, 2019
Merchant Risk Council events are some of the best places to discuss the challenges and opportunities facing the payments sector, from open banking and borderless payments to blockchain and virtual marketplaces.
One topic that dominated this month's Merchant Risk Council London was Strong Customer Authentication (SCA), part of the PSD2 regulations. SCA is the new regulation for authenticating online payments, and will be rolled out across the European Economic Area (EEA) on the 14 September.
(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.)
SCA has been put in place to increase security for payers and reduce payer fraud as well.
SCA consists of a 2-factor authentication that will apply to all electronic (online) payments.
We talked about SCA with players from across the payments landscape, both at the event itself and at a roundtable dinner we hosted on the topic.
This article looks at three key topics that emerged from those discussions.
It’s hard to dispute the core aims of SCA - reducing fraud and making online payments more secure. Everyone we met was in favour of taking a principle-based approach to achieving these goals and was excited by the potential for innovation that this allows.
However, there was widespread frustration at the lack of consistency in the depth and granularity of the regulation, which some attributed to the pressure that regulators face from well-funded interest groups. In turn, this could lead to an inconsistency of implementation.
The 14 September deadline is fast approaching and few - if any - of the online businesses we spoke to felt ready for the change. While C-suite executives seem to have recognised the size of the potential impact that SCA could have on conversion, there is a broad lack of clarity about what issuers and PSPs could (and should) be doing to mitigate this.
Businesses are also divided on their readiness to communicate to their customers. While some are actively communicating, others worry that reaching out proactively will spook their users into churning.
Many businesses are still waiting to take action on SCA and the communication approaches of those that are taking action differ widely. The reason for these differences stems from the very real worry that making the necessary changes could lead to a significant drop in conversion.
As mentioned above, the point of SCA is to reduce fraud and make online payments more secure. The question is whether payers really value this over the convenience of existing checkout flows.
While we know that customers want convenience and a lack of friction, and regardless of the intentions of SCA, the new regulations add an extra barrier to successfully completing a transaction. Nobody knows for certain that customers want, or would even tolerate, more security measures than are already in place.
In a recent GoCardless survey of 1,000 payers, 45% of those asked would be ‘frustrated’ by a more secure but more lengthy checkout process when buying from their favourite brand, while an additional 23% would go as far as shopping with them less often because of it.
A common point of reference for businesses is a similar legislation rolled out in India in 2014. Local businesses reported an overnight drop in conversion of 25%. Companies affected by SCA are understandably keen to avoid a similar scenario.
With SCA likely to remain on the agenda for the foreseeable future, the best course of action is to keep the industry-wide discussion flowing, especially as more businesses begin to take note and begin developing appropriate strategies.
GoCardless will be attending Money 20/20 Europe in Amsterdam on the 3-5 June. If you’d like to talk to us more about SCA and the wider payments landscape, you’ll find us at booth K103 in Hall 1.