This should be an exciting time for ecommerce merchants. As more of the world stays at home, the opportunities for ecommerce sales have rocketed. Global retail platforms have seen an unprecedented spike in traffic since the start of the year: up from 16 billion web visits in January to nearly 22 billion in June.¹ However, where there’s money, there’s also cybercrime and fraud.

Merchants have been hit hard by carding attacks over recent years, as fraudsters look to leverage the huge volumes of breached financial data up for sale on the cybercrime underground. The impact can go way beyond the cost of chargebacks. But with Fraud Protection, merchants have proven, enterprise-grade capabilities at their fingertips.

From breaches to carding

In the U.S. alone, there were over 1,470 separate incidents reported by organizations last year, exposing almost 165 million records.² What does this mean for fraud? It means a readymade supply of financial and identity data flooding the underground cybercrime economy. However, fraudsters need to know whether the card details that they’re buying are still usable, or if the rightful owner and/or issuer has already canceled them.

This is where carding comes in. Fraudsters typically use bot scripts to automate the process of testing large numbers of stolen cards across various sites. Here’s what happens:
1. The fraudster procures a trove of card details from the dark web or other channels.
2. They use a bot to attempt to make small online purchases with the card data across multiple sites, in order to validate them. This could happen thousands of times until they are successful.
3. They filter the validated card details from the rest, and either use them for high-value fraudulent purchases or sell them onwards on another underground site.

Unfortunately for merchants, this kind of activity can have a significant financial and reputational impact. It could lead to:

• Chargeback losses, after the customer complains to their bank that someone has made a purchase using their card.
• Lost revenue in terms of the fraudulently purchased products which may never be recovered.
• Reputational damage and potential customer attrition. Social media and review sites can amplify negative customer experiences today.
• Operational overheads associated with customer support and dealing with an incident.
• Being placed on a card issuer’s fraud monitoring program.

Of these negative outcomes, the latter is particularly serious for a smaller business as it can entail extra administrative overheads in the form of remediation plans that need to be filled out with the issuer. There could also be additional fees added to the merchant’s service agreement with the issuer while in the program, and even the chance that the merchant account can be closed if they remain in the program for several months.

Enter Fraud Protection

Fortunately, Fraud Protection offers merchants an integrated and easy-to-manage solution that helps empower smaller businesses with enterprise-grade fraud prevention capabilities. Customized fraud filters are provided out-of-the-box, and filters stay optimized with continuous recommendations based on new transactions and evolving fraud.

Most importantly, Fraud Protection has been proven to detect and block carding attacks — helping to reduce chargebacks and operational costs, and is designed to keep merchants out of issuer fraud monitoring programs.
For example:

• A game rental company’s previous fraud protection tool used to only decline about 1% of fraudulent transactions while the issuer was declining around 95%. Now the company is able to decline 75% of fraudulent transactions by using Fraud Protection, preventing a majority of bad transactions from being sent to the issuer and thereby improving the game rental company’s authorization rates.³
• A marketing software company’s decline rate using another fraud tool was between 1-10%, while the issuer was declining 40-50%. Now with Fraud Protection, the company is able to decline about 20-30% of bad transactions before they get rejected by the issuer and result in authorization fees.⁴

As David Mattei, a Senior Analyst in the Fraud & AML Practice at Aite Group recently said: “Fraud Protection is an easy-to-use solution to help protect small and medium size businesses from fraudulent transactions.”

He continued to highlight that: “Leveraging the consortium insights into consumer risk enabled by PayPal’s 12 billion annual transactions and advanced machine learning, merchants can manage fraud without needing specialized expertise. The on-demand filter recommendations allow merchants to keep fraud strategies up-to-date with minimal effort.”

Fraud Protection is available to all Braintree merchants, and can be easily enabled in the Fraud Management section of the Braintree Control Panel. For more information on Fraud Protection, check out our guides.

PSD2’s Strong Customer Authentication (SCA) enforcement in Europe is just around the corner! Here’s what you can do to make sure that your checkout is ready for the new regulatory requirements.

Strong Customer Authentication

The SCA regulations set a new standard for online payments in Europe. For details on the requirements and standards, take a look at our previous blog on the subject. What this ultimately means is that in order to accept card payments online, 3DS will need to be used to provide authentication. Specifically, if you accept debit/credit cards, Visa Checkout, Secure Remote Commerce, or Non-Network Tokenized Google Pay payment methods in the EEA, you’ll need to ensure that 3DS is ran in order to successfully process those payments.

Other payment methods not mentioned, like Apple Pay and Network-Tokenized Google Pay payment methods, presently include SCA mechanisms as processed through Braintree, and do not require and additional 3DS call.

Enforcement

The European Banking Authority’s (EBA) current end for the “migration period” for PSD2 SCA is December 31st, 2020, where it is expected that it will be broadly enforced by the EEA member states.

Each country’s National Competent Authority (NCA) has flexibility regarding when and how to enforce the SCA requirement on its issuing banks. While it’s expected that enforcement will track with the migration period end date, issuers in each country may begin to decline payments falling in scope of the regulations before the end of the migration period.

The United Kingdom

The United Kingdom’s NCA, the Financial Conduct Authority, has announced that they will be delaying enforcement until at least June of 2021, with expectations to have issuers fully enforcing the regulations by September of that year.

NCA’s are setting these ramp targets ahead of the December date to ensure that merchants and PSP’s can comply with the regulations

How will regulations be enforced?

The regulatory bodies in Europe will largely be carrying out supervision of issuers within their national jurisdiction. As such, issuers will be under instruction to decline transactions that do not adhere to the SCA requirements. Fortunately, issuing banks have new specific decline codes that they can use to signal to merchants that transactions are being declined because of regulatory requirements, which Braintree has distilled to a single response code to use across card networks, decline code 2099:

Our recommendation is to use 3DS up-front for transactions whenever possible, however this decline code can be used to trigger a second transaction attempt with 3DS as a processing strategy as well.

What do I need to do?

To ensure there is not disruption to your checkout experience, we recommend that all European merchants:

1. Confirm that you are using the latest version of the Braintree SDK’s where possible.
   a) If you’re not sure, check in with your developer to see if your SDK is on the most recent version, which can be found by looking at the SDK’s respective changelog: iOS, Android, Web
2. Review the 3DS 2 Adoption Guide and ensure you are collecting and passing the data points needed to qualify for a 3DS 2 authentication
3. Validate 3DS 2 readiness by sending at least one test transaction for each payment method available in the checkout flow.
   a) You can verify this by checking the presence of three d secure info in transaction response payloads, and/or checking for a 3D Secure Information section in a transaction in the Control Panel.

Even prior to the global coronavirus outbreak, the incentives and opportunities for online payment fraud have become substantial. Last year ecommerce represented over 14% of total global retail sales, totaling more than $3.5 trillion dollars.¹

Now with the impact of COVID-19 and the accelerated shift of socially-distanced consumers to digital commerce channels, it's inevitable that incidents of online fraud and sophisticated schemes will continue to keep pace. For merchants, the increase in fraudulent transactions can mean a big decrease in revenue: Juniper Research predicts that global merchants will lose a combined $130 billion between 2019 and 2023 via card-not-present (CNP) fraudulent transactions.

Keeping up with fraud types and identifying effective solutions can be a daunting, time-consuming challenge as merchants are in business to sell their products and services, not fight fraud. Merchants are looking for tools to help on multiple fronts: to protect against losses from fraudulent credit card activity, to mitigate chargebacks, and to unblock revenue from overly aggressive or simplistic filters. In addition, such tools need to be sufficiently easy to navigate and use, allowing merchants to focus on their own core businesses.

With merchants' needs top of mind, we are launching Fraud Protection. Fraud Protection gives merchants an integrated solution that leverages the deep intelligence of the PayPal and Braintree networks, a vast array of data analytics, and state-of-the-art machine learning. Fraud Protection adapts to changing fraud patterns and provides the flexibility to choose rules and filter settings specific to merchants' businesses.

Data makes the difference

When it comes to fraud management solutions, the big differentiator is data. Why? Because more relevant data facilitates more automated learning that can be applied to risk decision-making. And with over 20 years of global data and risk decisions that are based on access to both buyer and seller sides of more than 12 billion transactions a year, PayPal and Braintree have a rich ecommerce and mobile dataset to learn from.

In the case of Fraud Protection, that learning is applied to the process of evaluating transactions for suspected fraud. Fraud Protection aims to help merchants more easily view and manage the relationship between the fraud they catch in real-time and the chargebacks they may incur later. Finding the ideal operating point between fraud rejections and chargebacks requires a solution that learns from both and adjusts accordingly. Our machine learning capabilities balance those data results for optimal performance and were named best-in-class in an independent study of fraud and advanced machine learning platform vendors.

Better transparency and control for merchants

Fraud Protection provides a foundational solution that’s easy to enable and configure. The initial set-up requires little effort and merchants can set their own operating points to control their experience:

• Increased transparency and visualization: The dashboard presents a holistic view of Total Processing Volume reviewed by the tool, fraud rejections, and fraud chargeback value over time, plus transaction history for insights into fraud event triggers.

• Business-need customization: Fraud Protection unlocks personalized, out-of-the-box filters -- starting the very first day it’s enabled. Filters are based on a merchant’s total payment value, chargebacks, and age of the account, providing the best filter set based on past transactions and behaviors.

• Filter recommendations: As the tool gathers more data about a merchant’s business, it will recommend changes to filters to further optimize rejections and chargebacks.

• Real-time filter testing: Merchants can test and assess the impact of filter changes based on past transaction data before implementing the changes.

Fraud Protection is now available

Since June 2019, select merchants have been participating in our Fraud Protection pilot program with successful results. Pilot merchants in regions around the globe have realized fewer fraud rejections and chargebacks.

Fraud Protection is now generally available to all Braintree merchants and is fully integrated into our platform.² Merchants can easily enable the tool and access the new UI from the Braintree control panel to better protect their businesses from payment fraud.

If you have questions or want to learn more about Fraud Protection, contact us or read more on our website.

We know the spread of the coronavirus and its impact on the global economy has serious implications for your business. We are here to support you.

On March 31, PayPal announced a set of relief measures to help more than 24 million merchants around the world impacted by the coronavirus. We want to take a moment to share with Braintree merchants what these relief efforts may mean for your business.

To help alleviate the financial impacts you may be experiencing, Braintree has implemented the following measures, which may vary based on your account type, size, and other factors specific to each merchant:

Dispute auto-response for refund evidence

We will automatically submit refund evidence on your behalf for chargebacks raised on US-based credit and debit card transactions greater than $30 USD, if you have not submitted evidence by the deadline.

The automation of dispute response is a new functionality intended to help you manage the rising volume of disputes. This functionality will also help merchants who are receiving disputes on already-refunded transactions avoid potentially refunding the same customer twice. This does not guarantee that you will win the dispute, so we encourage you to continue to attach additional evidence to the dispute if available.

This functionality went into effect on April 3, 2020 for merchants of all sizes processing in the US. The pilot program and duration of the program is subject to be changed or adjusted at any time, and we encourage you to respond to every dispute in the Control Panel or SDK/API integration.

Chargeback fee waivers

For eligible Braintree merchants, primarily our hardest hit small and medium businesses, we have waived chargeback fees from April 1, 2020, through at least April 30, 2020.

To determine if your fees were waived, refer to your monthly account statement.

We’re here to help

We understand this may be a difficult time for businesses, and we want to do our part to support you. If you have any questions, don't hesitate to contact us.

Update (June 9, 2020): Updated post to reflect sandbox availability.

The payments industry is moving to an authorization model for refund processing. Refund authorizations introduce real-time decline responses to refunds. This blog post provides details on Braintree’s plans for refund-related API changes: we recommend that you review the technical changes outlined here as well as the guidelines in our previous post to ensure your integration is prepared for refund declines.

Technical changes

To reduce integration friction, Braintree will introduce two refund decline workflows. The workflow that you experience will depend on the SDK version your integration uses to connect to Braintree: new SDK versions or previous SDK versions.

New SDK versions

In Q1 2020, Braintree will release the following new SDK versions:

• Ruby 3.0 or newer
• Python 4.0 or newer
• Java 3.0.0 or newer
• Node.js 3.0.0 or newer
• PHP 5.0.0 or newer
• .NET 5.0.0 or newer

If your integration uses one of these new SDK versions, and the processor declines a refund, the response will have the processor response code available. The processor response code will pull from the existing pool of 2000-class decline codes, allowing you to determine the cause of the decline in real time. Common refund decline codes include:

• 2004 - Expired Card
• 2005 - Invalid Card Number
• 2014 - Fraud Suspected
• 2047 - Pick Up Card

Note: GraphQL users will receive processor response codes for all refund declines.

Previous SDK versions

If your integration uses an SDK version older than those listed above, and the processor declines a refund, you will receive one of the following two validation errors in lieu of a processor response code:

• Hard decline: 915200 - Failed to refund transaction.
• Soft decline: 915201 - Failed to refund transaction. Please try again at a later time.

Sandbox testing

These changes are currently available in the Braintree sandbox. We recommend testing refund declines so that you can prepare for the upcoming launch of refund authorizations.

In order to simulate a refund decline in sandbox, follow these steps:
1. Simulate a successful sale using an amount between $3001.00-4000.99
2. Submit the sale for settlement; once the transaction updates to a Settled or Settling status, it is eligible for a refund
3. Specify the sale’s transaction ID in a refund request
4. In order to simulate a refund decline, specify a refund amount between $2000-2999.99
5. The amount specified will determine the decline code: for example, submitting a refund for $2004.00 will generate a decline response of 2004 - Expired Card if using a current SDK version

General guidelines

Our previous post provides a comprehensive list of rules and guidelines – here are a few key requirements:

• If the refund attempt is hard declined, do not reattempt the refund to the same card.
• If the initial refund attempt declines, you are permitted to refund an alternate card that matches the same card brand used to create the original sale. This reattempt must be performed via a detached credit.
• It is against scheme rules to refund a card that does not match the same brand used to create the sale. For example, you cannot refund a Mastercard if the original sale was created with a Visa card.
• If all attempts to refund the cardholder are declined, you are permitted to issue a refund via store credit, check, or alternative method, depending on your refund policy.

Questions?

If you have any questions about these changes, contact us.

Braintree has updated Amex processing to allow eligible merchants to settle for greater than the original authorization amount. This functionality is available to merchants who utilize accounts obtained directly from Amex. Note: Amex does not support auth adjustment functionality.

Merchant benefits

• Removes friction when processing tip adjustments, order adjustments, and rental extensions
• Minimizes the number of transactions per order

American Express requirements

Amex permits the following merchant categories to settle within designated thresholds, respective to the original authorization amount:

• Up to 20% tip/order adjustment:

  • 4121 (taxicabs and rideshares)
  • 5812 (restaurants)

• Up to 15% rental adjustment:

  • 7011 (lodging)
  • 7512, 7513, and 7519 (vehicle rentals)

Technical changes

If you’d like to implement this functionality:
1. Confirm you fall within one of the merchant categories outlined above.
2. Contact us to enable this feature
3. Update your integration to support increased submit for settlement amounts in your API requests

If a transaction is submitted with an amount that exceeds Amex’s 15% or 20% thresholds, Braintree will return the following validation error:

91522 - Settlement amount is too large

If your settlement adjustment exceeds the allowed threshold, you should create a second authorization for the additional amount.

How does this differ from auth adjustments?

It is important to note that this American Express functionality is not the same as Visa/Mastercard authorization adjustments. While you may be able to settle American Express transactions for a larger amount than was originally authorized, the authorization amount itself will not change; the settlement attempt will not trigger an auth adjustment object or result in validation errors.

Questions?

If you have any questions, contact us.

To enable greater transparency for customers, Visa is updating its rules related to transactions for merchants that offer free trials or introductory promotions as part of an ongoing subscription service. Starting on the enforcement date of April 18, 2020, Visa will require merchants to provide specific information and resources to cardholders regarding subscription services. These updates are intended to keep cardholders better informed about their purchases. This increased transparency may also help lower chargebacks.

Visa requirements

Here’s the breakdown of the Visa requirements that go into effect on April 18, 2020:

• Merchants must obtain cardholder consent before entering them into a subscription service.
• Merchants must provide cardholders a copy of their terms and service conditions at the point of enrollment. Enrollment is considered the point at which the cardholder signs up for a trial or promotional period. These terms must include the following:
  • Cardholder confirmation entering them into the subscription service
  • Subscription start date
  • Details of goods/services
  • Transaction amounts and billing date/frequency
  • Link or simple mechanism to cancel the subscription online
• Merchants must notify cardholders at least 7 days before the cardholder’s trial or promotional period expires.
• Merchants must enhance the descriptor of the subscription transaction that immediately follows a trial or promotional period to include a trial reference.
• For each subscription transaction, merchants must provide a receipt that includes the following details:
  • Trial or promotional details (if applicable)
  • Transaction date and amount, even if the trial or promotion lowers the initial transaction amount to $0
  • Link or simple mechanism to cancel the subscription online

Required technical changes

If you use Braintree subscriptions, we recommend making these technical changes to comply with Visa’s new requirements:

• Include a reference to the trial or promotional period in the descriptor name of the subscription.create call. The words “trial period”, “promotional period”, “free trial”, or anything similar are permitted. When the subscription becomes active, Braintree will include the enhanced descriptor in the first subscription transaction.
• After the first subscription is successfully processed, remove the trial reference from the descriptor name via a subscription.update call. Subsequent subscriptions will process without trial or promotional references.

If you use custom subscription logic, we recommend making these technical changes to comply with Visa’s new requirements:

• Update the descriptor name in the transaction.sale call to include a trial or promotional reference.
• For subsequent subscription transactions, remove the trial reference from your descriptors.

Questions?

For more information about subscriptions, check out our Recurring Billing guide. If you have any questions, contact us.

Last week, the European Banking Authority (EBA) published its opinion on the deadline and process for completing the migration to Strong Customer Authentication (SCA). The new date that the EBA recommends the requirements will begin to be enforced by national regulators is December 31, 2020.

This unified transition period means that merchants are expected to have additional time to prepare for enforcement. But what exactly is the transition period? And what does it mean for everyone involved?

SCA enforcement: a quick recap

As you may recall, the original date that the EBA identified for enforcement was September 14, 2019. But it was widely known (at least among those closely watching this situation) that there was limited readiness for 3D Secure 2 (3DS2), the industry-standard solution for meeting strong customer authentication requirements. And that limited readiness was not just on the part of merchants: payments service providers, issuers, acquirers, and payment networks were all scrambling to prepare. That’s likely why nearly every country in the European Economic Area (EEA) announced its support of some kind of an extension. Now, a little over a month later, the EBA has agreed, recommending a 14-month pan-European transition period for SCA enforcement.

The EBA made the right decision. To begin enforcing SCA on the original date would have not only been detrimental to the very cardholders the requirements were meant to protect, but may have had widespread negative economic impacts due to SCA-related declines. But the transition period doesn’t let merchants -- or the entire payments ecosystem -- off the hook. SCA is still coming, and next time everyone will need to be ready or face the consequences.

What exactly does ‘transition period’ mean?

By calling this a transition period, the implication is that everyone is moving toward a common deadline, at which point the switch will flip and issuers will all begin to enforce SCA. But the reality is more nuanced. From now until December 31, 2020, individual issuers in specific markets may begin to enforce SCA requirements at any time. That means merchants whose transactions pass through an enforcing issuer will risk increased declines if they do not authenticate according to the requirements.

What do merchants need to do?

To be prepared for and help reduce the risk of declines during this period of potentially disparate authentication requirements, we strongly recommend you integrate and begin testing Braintree’s 3DS2 solution as soon as possible. Our flexible solution has been built to support both 3D Secure 1 and 2 authentication protocols, meaning if a particular issuer isn’t ready to support 3DS2, Braintree will automatically divert your transactions to 3DS1 to help ensure your transactions are SCA compliant. It will also tell you whether SCA is even required by a certain country, so you can make an informed decision on whether to invoke 3DS for your customers.

A word on exemptions

The transition period does not change anything when it comes to exemptions. Issuers, not regulators, have the final decision of whether or not to accept exemption requests or require SCA on any given transaction. As we’ve mentioned before, Braintree’s 3DS2 solution will have the capability to pass flags and indicators when an exemption is requested -- in other words, we will accommodate exemptions if merchants decide to use them. But it’s important to remember that by obtaining an exemption, merchants will miss out on any potential liability shift to the issuer and also likely give up any recourse to successfully challenge disputed transactions.

Closing thoughts

While we hope that the EBA’s opinion will promote issuers and acquirers to handle things at least somewhat synchronously, being prepared sooner rather than later is the best thing merchants can do to minimize disruption. By testing and having the code ready to deploy -- even if you do not authenticate transactions now -- merchants can address any unforeseen reactions in any given market before SCA requirements are enforced.

Merchant resources

For instructions on how to integrate, refer to our 3D Secure developer docs.

If you have already integrated 3DS, make sure you have the latest SDK with the most up-to-date features. For details, refer to our 3DS2 migration guide.

To see how SCA will apply to different transaction types, including recurring transactions, read How SCA Applies to Common Payment Scenarios.

If you are still unclear about the details of SCA, or would like an overview on the mandate and its requirements, read PSD2: Strong Customer Authentication Explained.

For more information on the background and benefits of the 3DS2 protocol, as well as how Braintree’s solution works, read 3D Secure 2: Next-generation Authentication.

As always, we’re here to help. If you have questions or need help with your integration, contact us.

Thanks to EMV chip technology, Australian merchants have enjoyed a significant reduction of fraudulent in-person credit card transactions, with losses from counterfeit/skimming fraud at their lowest since 2006.¹

However, that doesn't mean credit card fraud went away. As in-person fraud became more difficult, criminals shifted their efforts to the digital realm and began focusing on what’s known as Card-Not-Present (CNP) fraud. As a result, almost 85% of all credit card fraud in Australia now takes place online.²

In an effort to combat this considerable increase in online card fraud, the Australian Payments Network (AusPayNet) recently issued new rules requiring Strong Customer Authentication (SCA) for merchants identified as “high-risk.” Here's how those rules may impact your business.

Combating fraud with SCA

You may already be familiar with SCA as a part of Europe's PSD2 regulations. Under that mandate, applicable transactions are required to have two independent authentication factors performed in order to be approved. These factors are categorized in three ways: "knowledge," as represented by something like a password or PIN; "possession" of something, like a device or card; and "inherence," as proven by a fingerprint or other biometric. As a global standard, SCA is a key element in AusPayNet's efforts to mitigate CNP fraud.

How the fraud mitigation framework works

In its CNP Fraud Mitigation Framework, AusPayNet defined new fraud thresholds that merchants and issuers are required to meet. AusPayNet set the initial fraud threshold for merchants at 20 basis points (0.20% of CNP transaction value) and $50,000 in fraudulent CNP losses per quarter, while the initial fraud threshold for issuers was set at 15 basis points (0.15% of CNP transaction value).

Merchants with fraud rates below those levels are not required to apply SCA to any transactions. Merchants unable to meet that threshold for two consecutive quarters will be deemed “high-risk” and will be required to apply SCA to most transactions. Low-risk transaction types such as recurring payments, trusted customers, and wallet transactions are also exempt from SCA requirements regardless of whether or not a merchant has been deemed “high risk.”

Key dates

The new rules went into effect on July 1, 2019, with acquirers reporting on merchant data chargebacks as of Q2 2019. Currently, enforcement is scheduled to begin on December 31, 2019.

What's next for ‘high-risk’ merchants?

Braintree has already begun reporting on chargeback rates in order to remain compliant with AusPayNet's CNP Fraud Mitigation Framework. Any Braintree merchant that has been identified as “high-risk” will be contacted to discuss how to integrate 3D Secure (3DS), the solution we recommend to perform SCA on transactions acquired in Australia.

If you are contacted, it’s important to integrate 3DS as soon as possible. “High-risk” merchants that neglect to use 3DS to authenticate transactions risk an increase in declines. Continued failure to apply SCA to applicable transactions could lead to a scenario in which the merchant’s acquirer demands that the merchant’s payments processor (i.e., Braintree) stop processing for that merchant altogether.

Questions?

As the commerce platform for large and fast-growing enterprises that are building the most innovative commerce experiences globally, Braintree is committed to keeping you informed about the latest news and information regarding SCA requirements in Australia. If you have questions about the CNP Fraud Mitigation Framework or Braintree’s 3DS solution, contact us.

Update (October 1, 2021): Add Forward API production rollout date; a Previous rollout was completed April 6, 2020

Update (February 27, 2020): Updated production rollout date.

As part of Braintree’s effort to increase stability and extend our global footprint, we are expanding our IP space to accommodate new endpoints – introducing more IP addresses in addition to the ones we currently use.

In November 2021, Braintree will update the IP addresses we use for sandbox and production API traffic. If you whitelist Braintree IP addresses in your integration, you must include these new IP addresses to ensure that you will be able to process payments.

When will the changes take place?

The new set of IP addresses will take effect in production on November 19, 2021. The new IP addresses are already live in sandbox. We’re sharing this information in advance so that you have time to review your integration and make any updates needed to avoid processing interruption.

What’s changing?

We are adding new IP addresses. Our existing IP addresses will not change. This update could impact your ability to process payments if your server administrator or IT security team maintains an allowlist (i.e. whitelist) of IP addresses for Braintree API traffic.

We have already updated the Braintree IP Addresses page in our developer docs to reflect this new set of endpoints. Additionally, we’ve published this new list in JSON format to https://assets.braintreegateway.com/json/ips.json.

If we add more IP addresses again in the future, we will update this JSON and the Braintree IP Addresses page in advance.

Note: this change does not impact IP and hostname restrictions configured through the Braintree Control Panel.

What action is required?

If you do not whitelist Braintree IP addresses, or if you only use IP and hostname restrictions in the Braintree Control Panel, no action is required from you.

If you do whitelist Braintree IP addresses in your integration, you must include these new addresses before November 19, 2021 to ensure that you will be able to process transactions. You can update your whitelist now or at anytime before November 19 using the new list – you should not wait until the IP address change officially takes effect.

What’s an IP address whitelist?

A whitelist provides access to specified IP addresses and programs when your security policy would otherwise prevent that access. Whitelisting domains or IP addresses can be useful, but it comes with additional overhead and complication. It’s also worth noting that our IP addresses are always subject to change. For more information, see Braintree IP Addresses.

If you’re unsure if you are whitelisting Braintree IP addresses, we recommend checking with your server administrator or IT security team. Because whitelists are maintained on your end, we are unable to confirm that for you.

If you have any questions, contact us.

The payments industry is ever-evolving and card brands are frequently implementing changes to make the payments space more secure. Visa recently rolled out some significant changes to their chargeback and fraud programs in the fall of 2019, which you can read about in our blog post. Now, Mastercard is implementing some changes of their own regarding their monitoring programs. This blog is meant to keep merchants updated of these changes and provide a comprehensive source for Mastercard chargeback and fraud programs, along with upcoming changes that may impact your account.

Overview

Effective October 2019, Mastercard is implementing a brand-new fraud monitoring program, called the Excessive Fraud Merchant Compliance Program (EFM). The goal of this program is to reduce the amount of ecommerce fraud globally.

Mastercard’s chargeback monitoring program is called the Excessive Chargeback Program (ECP). It contains two tiers of program thresholds (CMM and ECM) and your account will fall into one or the other, depending on the severity of the chargeback issue. Just as with their fraud program, the goal of this program is to reduce chargebacks -- due to either fraud or consumer dispute reasons -- and improve the payment experience. This program is not new and there are no changes to this program at this time.

Excessive Fraud Merchant (EFM)

Mastercard identifies merchant activity at the merchant account level. If a merchant account meets the following conditions in a calendar month, they can be placed in the EFM program:

• At least 1,000 Mastercard sales transactions in the previous month
• At least $50,000 in Mastercard fraud chargebacks under reason codes:
  • 4837 (No Cardholder Authorization)
  • 4863 (Cardholder Does Not Recognize -- Potential Fraud)
• At least 0.50% fraud chargebacks-to-sales ratio
• Less than 10% of volume passing through 3D Secure in non-regulated countries or less than 50% of volume passing through 3D Secure in regulated countries

Non-regulated countries refers to countries without a legal or regulatory requirement for strong cardholder authentication (e.g. US, Canada, some European countries). Regulated countries refers to countries with legal or regulatory requirements for strong cardholder authentication (e.g. some European and APAC countries).

Once in the EFM program, the account is eligible for the fines as shown in the table below. However, while the program is rolling out in October 2019, Mastercard will not start assessing these fines until March 2020 for most regions. The exception is Canada, who will not receive fine assessments until October 2020.

To be removed from the EFM program, a merchant must be in compliance for three consecutive months, meaning the account did not meet the criteria listed above to be flagged in the program. Once a merchant exits the EFM program, any subsequent flagging would start over at Month 1 again. While enabling 3D Secure is not a requirement of this program, it is recommended to help mitigate fraud by authenticating transactions.

Excessive Chargeback Program (ECP)

Just as with the EFM program, merchants are identified in the Mastercard chargeback program at the merchant account level. Mastercard calculates chargeback ratios by taking the total number of first chargebacks received in a given calendar month and dividing it by the prior month’s sales.

For example: June’s chargebacks / May’s sales

There are two different thresholds in Mastercard’s ECP program in which a merchant could be identified. Those are:

Chargeback Monitored Merchant (CMM)

A merchant can be placed in the CMM program when the following criteria is met in a calendar month:

• First chargebacks received: 100
• Chargeback-to-sales ratio: 1.0%

There are no fine assessments at the CMM level.

Excessive Chargeback Merchant (ECM)

A merchant can be placed in the ECM program when the following criteria is met in a calendar month:

• First chargebacks received: 100
• Chargeback-to-sales ratio: 1.5% for two consecutive months

Mastercard can assess fines the first month a merchant enters the ECM program. These fines are assessed at the discretion of Mastercard and, in general, can be up to the total amount of Mastercard confirmed chargebacks in the ECM identification. For example, if your account had $5,000 in confirmed Mastercard chargebacks in your ECM identification, this fine would not exceed $5,000.

To be removed from the ECP, a merchant must be below CMM thresholds, which is 100 chargebacks and 1.0% chargeback to sales ratio, for two consecutive months. Once a merchant exits the ECP they begin a clean slate, and any subsequent flaggings would start their standings from the beginning.

Other considerations

If a merchant breaches the thresholds for both the Excessive Fraud Merchant (EFM) program and the Excessive Chargeback Program (ECP), they would be entered into the EFM program and not the ECP.

For merchants that have their merchant accounts through Braintree, our Disputes team will notify you if you’re flagged in any of the above programs, work with you to reduce the chargeback or fraud activity, and remediate your account out of the program. You can read more about this process in our blog post.

Mastercard may request a remediation plan along with any of these program identifications. The purpose of a remediation plan is to show Mastercard that steps are being taken to mitigate fraud and chargebacks. We’ll ask for the following details, but you may also share any additional information you find pertinent to the activity:

1. Business Description
2. Events leading to the increased chargeback and fraud
3. Actions taken to reduce chargebacks and fraud, including implementation dates
4. Description of all fraud tools currently enabled

Common Questions

How does Mastercard calculate fines for the ECP?

Fines can be assessed the first month the account reaches ECM thresholds. The formula is:

$100 Reporting Fee + Issuer Recovery + Violation Assessment

This means there is no set fine amount for each ECM identification. However, the fine assessment will not be more than the total amount disputed in the ECM identification as referenced above.

How can I calculate my Mastercard chargeback ratio?

Check out our blog post that reviews how merchants can calculate their ratios, and how Braintree can help reduce them.

Why do my numbers vary from what Mastercard reported?

Chargeback numbers displayed in the Control Panel are considered estimates, as these will differ from the card network’s official figures due to multiple factors, including but not limited to timing differences in reporting, auto-representation, and multiple merchant processors.

Do won chargebacks count against my Mastercard ratio?

Yes. Regardless of outcome, if a chargeback opens, it is counted against the ratio.

Are pre-arbitrations and retrievals counted in the ECP?

No. Only first chargebacks count against the ratio.

Do chargebacks received on already refunded transactions count towards my ratio?

Yes. If a chargeback opens against any transaction, it is counted against the ratio, even if the transaction was previously refunded.

Some of the chargebacks I received this month were on transactions processed months ago. What month are these counted in my chargeback count?

Chargebacks are counted in the month they are raised, not when the transaction was processed. Many times, chargebacks are raised in the months after they were processed.

Are the program fines included in my Braintree chargeback fee?

No. Program fines issued by Mastercard are supplemental fees which are not included in the chargeback fee.

Can I change how Mastercard calculates my chargeback and fraud rates?

No. By choosing to process Mastercard credit and debit cards, merchants agree to their mandated rules and regulations.

If you have any questions, reach out to us at any time.

Braintree has supported SMS and authenticator app two-factor authentication in the Control Panel since 2015. As part of our ongoing mission to keep your data secure, Braintree is pleased to announce that we now support hardware two-factor authentication (H2FA) in the Control Panel, providing a new way for merchants to help keep their accounts secure. In this blog post, we’ll outline how merchants can get started with H2FA.

Two-factor authentication is a crucial tool for helping protect merchants from unauthorized account access, typically by requiring a time-sensitive code during sign in. It is effective against various forms of phishing attacks, where malicious actors trick users into giving them login credentials. These threats are becoming increasingly sophisticated and are one of the most common causes of security breaches.¹

Traditional two-factor authentication methods, like SMS codes and authenticator apps, offer protection against basic types of phishing attacks. However, the generated codes can be vulnerable to interception.

The protocol used by hardware tokens -- FIDO’s U2F in our case -- is designed to protect against malicious interception and is proven to be more effective than SMS codes and authenticator apps.² All merchants are encouraged to enable H2FA to speed up the login process and increase protection against phishing.

The security key

H2FA security keys can have many forms, including thumbdrive-like plugins, fingerprint readers, browser-supported Android devices, and Touch Bar enabled Apple devices.

When a user activates H2FA, the specific key used is linked to their user account. On subsequent logins, the user will be prompted to insert and activate their security key, which will then generate a secure code for authenticating the user. This fast, easy authentication method doesn’t require the user to open an app or check their phone for a text – just plug in your key and go!

Enabling H2FA in your account

For instructions on how to use hardware 2FA and log in with your key, see our 2FA documentation.

Related resources

For more information about FIDO standards, check out The FIDO Alliance’s documentation and press release. If you’re interested in learning more about the effectiveness of H2FA against account takeover, read more in this 2019 study.

Questions?

To learn more about the support of hardware two-factor authentication, contact us.

Updated (October 17, 2019): The EBA has published its opinion on the deadline and process for completing the migration to SCA. The new enforcement deadline is December 31, 2020. See below for details on this official transition period.

Updated (September 14, 2019): SCA requirements have gone into effect in Europe. Braintree is actively monitoring bank activity.

Updated (September 10, 2019): Croatia, Cyprus, Czech Republic, Estonia, Finland, Hungary, Lithuania, Luxembourg, Portugal, Slovakia, Slovenia, Spain, and Sweden have been added to the list of countries that confirmed their views in favor of a transition period.

Updated (August 30, 2019): Belgium, Greece, Ireland, Malta, and Norway have been added to the list of countries that officially confirmed their views in favor of a transition period.

Understanding if, when, and how Strong Customer Authentication (SCA) applies to your business can be confusing -- especially with all the rumors circulating and changes being announced by the European Banking Authority (EBA) and national regulators.

As the commerce platform for large and fast-growing enterprises that are building the most innovative commerce experiences globally, Braintree is committed to keeping you informed about the latest news and information regarding SCA requirements.

In which cases will SCA apply?

The way SCA will need to be applied will vary by transaction. It will depend on both the location of your acquiring bank and the location of the bank that issued your customer’s credit card -- not necessarily where your business is domiciled. Please refer to this list to see which countries are affected by SCA requirements.

What are the most recent announcements regarding SCA enforcement timelines?

The EBA, working in partnership with payment service providers, acquirers, issuers, merchants, and the payment networks, published its opinion on the deadline and process for completing the migration to SCA. The new date that the requirements will begin to be enforced is December 31, 2020. It’s important to note that individual issuers may begin to enforce SCA requirements at any time within this official transition period, leaving unprepared merchants at risk of increased declines.

What do I need to do?

As ever, Braintree strongly recommends you integrate and test our 3D Secure 2 (3DS2) solution as soon as possible to help reduce the risk of SCA-related declines if and when issuers begin to enforce the requirements.

What else do I need to know?

Braintree’s flexible 3DS2 solution has been built to support both 3D Secure 1 and 2 authentication protocols. That means if issuers aren’t ready for 3DS2, Braintree will automatically divert your transactions to 3DS1 to help ensure your transactions are SCA compliant.

Where can I learn more?

For instructions on how to integrate, refer to our 3D Secure developer docs.

If you have already integrated 3DS, make sure you have the latest SDK with the most up-to-date features. For details, refer to our 3DS2 migration guide.

To see how SCA will apply to different transaction types, including recurring transactions, read How SCA Applies to Common Payment Scenarios.

If you are still unclear about the details of SCA, or would like an overview on the mandate and its requirements, read PSD2: Strong Customer Authentication Explained.

For more information on the background and benefits of the 3DS2 protocol, as well as how Braintree’s solution works, read 3D Secure 2: Next-generation Authentication.

As always, we’re here to help. If you have questions or need help with your integration, contact us.

Update (December 3, 2019): Updated production roll out date.

Update (November 21, 2019): Added detail around changing token length.

Update (August 7, 2019): Since posting this we have received a number of support requests about how this change will affect subscription billing or vaulted payment methods. We want to make clear that this change applies only to client tokens, meaning the tokens used to authorize clients such as browsers and mobile apps. This change will not affect any vaulted payment method or recurring billing.

Braintree merchants currently have two different ways to collect payment information through clients (mobile devices, web pages, etc.): tokenization keys and client tokens. To help improve performance and increase security, we will soon be changing the system we use for client tokens.

What’s changing?

In the new system, Braintree will be issuing JSON web tokens (JWTs) as a replacement for the current authorization fingerprint implementation. Our client tokens have always been defined as single use, and this change will enforce a 24-hour lifespan. That means client tokens issued after the change is implemented will expire after 24 hours, and attempts to use an expired token will result in an error. While the change is backwards-compatible and transparent for most, some merchants may have to update their integration to be fully compatible with the new system. If you’re unsure about compatibility, you can test against it now in our sandbox environment.

When will the changes take place?

We plan to roll out this change to 100% of merchants in production on January 6, 2020.

Why are we making these changes?

With the impending regulatory mandate for PSD2: Strong Customer Authentication (SCA) in Europe taking effect in September 2019, and the gradual move toward SCA globally, we anticipate that the relative usage of client tokens will continue to increase over the next few years. We confidently base this assumption on the fact that 3D Secure 2, the industry-standard authentication solution for SCA -- and the one Braintree is suggesting our merchants adopt in order to be SCA-ready -- is only supported by client tokens. As the payments platform solution for the large and fast-growing enterprises that are building the most innovative commerce experiences globally, we felt this was the right time to optimize the way they collect payment information.

What is the benefit for merchants?

For our merchants -- regardless of whether or not they are required to meet SCA requirements -- this change has the benefit of reducing the peak latency of collecting client-side payment information. That should mean faster checkouts, fewer timeouts, and potentially an increase in revenue. Merchants will also have clearer visibility into exactly when a token expires and when a new one is required, helping to reduce accidental errors that could negatively affect conversion.

What action is required?

This change is backwards-compatible, and no action is required for most integrations. Integrations that rely on client tokens remaining valid for longer than 24 hours will need to be updated to ensure that clients are using tokens generated within the last 24 hours. In addition, minor changes in length of the token will occur. If you believe your systems may be affected by this, we recommend testing these changes in sandbox. If you have any questions, contact us.

A little over two years ago, PayPal and Google partnered to allow consumers in 24 countries around the world to link their PayPal and Google Pay accounts. The collaboration has helped to expand consumer choice by offering PayPal -- one of the most trusted¹ and highest converting² digital wallets -- as a payment option within Google services. It also extended the availability of features such as PayPal Purchase Protection and Return Shipping for eligible purchases to Google Pay users.

Google Pay gives customers a fast, simple way to pay on the web across all browsers and operating systems, in native Android apps, and in stores -- driving incremental transactions for merchants and a convenient experience for their customers. Hundreds of Braintree merchants already benefit from the Braintree integration of PayPal in Google Pay in the US. Today, we are excited to announce a new back-end change that extends the possibility to pay with PayPal in Google Pay in all 24 countries where the wallets can be linked.

PayPal Seller Protection benefits

In addition to the ability to offer added convenience and choice to their customers, Braintree merchants will also be able to reduce risk on eligible transactions with PayPal Seller Protection. In the event of a claim or chargeback that the buyer claims are the result of an unauthorized transaction or an item the buyer didn't receive, PayPal will cover the full amount on eligible transactions for merchants when consumers check out with PayPal via Google Pay. PayPal will not assess you a chargeback fee if the transaction is eligible for PayPal Seller Protection.

Additional operational insight

With the new transaction flow, the Braintree Control Panel will now include the PayPal Account as the Payment Type, and Google will appear as the Transaction Channel.

To find PayPal transactions from the Google Pay wallet, choose "PayPal" as the "Payment Instrument Type" and "Google" as the "Payment Method Source" in the new selection of filters for transaction search in the Control Panel.

Enabling Google Pay + PayPal

Merchants that already offer Google Pay and PayPal at checkout can get access to the new benefits by simply updating their SDK to our latest version. New merchants making their first integration will be able to offer PayPal to millions of Google Pay users globally as well as get access to PayPal Seller Protection by enabling Google Pay in their Control Panel. Here is the Google Pay switch toggled “ON” in the Braintree Control Panel: