Strong Customer Authentication

Applies to: In-App Payments SDK - Android | In-App Payments SDK - iOS | Web Payments SDK | Payments API | Customers API

Learn how to use Strong Customer Authentication to verify buyers for online and in-app payments.

Link to section


Use Strong Customer Authentication (SCA) with the Web Payment SDK and In-App Payments SDK to verify the buyer and reduce the chance of fraudulent transactions. SCA is also known as 3D Secure (3DS) in the European Economic Area (EEA).


Calling the verifyBuyer() method in any of these APIs starts the SCA flow.

Link to section

Requirements and limitations

Currently, when paying online, customers must enter their card number, expiration date, CVV, and postal code to make a payment. Buyers are required to complete two of the three factors of authentication when initiating a payment: something they know, something they own, and something they are. For online card payments, the SCA requirements are met by implementing 3DS. For in-store payments, SCA requirements are met through the use of chip and PIN or mobile wallets. Payments without this additional authentication are declined by the cardholder's bank. Payments initiated by sellers, such as recurring transactions or mail-order/telephone order (MOTO), don't require SCA.

A graphic showing the three elements of a multi-factor authentication, which are something you know, something you have, and something you are.

Link to section

What is SCA?

SCA is a standard protocol developed by a collaboration of several payment card issuers. It defines a multi-factor authentication mechanism that can be used to satisfy authentication requirements in regions wherever SCA is required.

SCA can also be used to authenticate buyers in countries where SCA isn't a requirement. In those countries, Square provides the SCA mechanism for those sellers who opt to use it. SCA creates the same buyer experience regardless of whether it's initiated from an SCA-required country. For more information about SCA, see Strong Customer Authentication FAQ.

Link to section

Liability shift

Before Square implemented SCA for payments, a seller could be liable for payment card chargebacks for online payments. For card present payments, sellers aren't liable for fraud. With SCA, the liability for fraudulent chargebacks is shifted to the card issuer in most cases. This liability shift to the issuer occurs when the payment is authenticated through SCA and the card involved is a Mastercard, American Express, JCB, Visa, Diners Club International or UnionPay card. Any of these cards that can be saved on file with Square can also use SCA. For more information, see Charge a Card on File with SCA.

As long as verifyBuyer has been called to start the SCA flow before processing payments, most of them will be protected from fraud liability when the issuer authorized the transaction. This still applies even if the issuer is unable to support 3D Secure.

Link to section

Do I need to support SCA?

Square advises all Square developers and partners operating in the European Economic Area (EEA), including the UK, to take appropriate steps to be ready for SCA enforcement starting January 1, 2021, to avoid an increase in declined payments for European cardholders.

In the UK, banks started asking their cardholders to complete SCA, with full enforcement of the SCA requirements by March 14, 2022. Across the rest of the EEA, banks are ramping up SCA enforcement starting January 1, 2021, with a staggered ramp-up through 2021.

Square provides SCA features for the Web Payments SDK and In-App Payments SDK within Europe, where the business taking the payment and the cardholder's bank are both in the EEA.


SCA isn't required for in-person payment solutions such as the Square Point of Sale API or Reader SDK applications.

Link to section

How is Square helping me prepare for SCA?

Sellers that integrate their applications with Square APIs need to flag buyer-initiated or seller-initiated payments by using the CustomerDetails object with the Payments API CreatePayment endpoint. The CustomerDetails object accepts booleans on customer initiated payments and seller keyed-in payment details:

KeyValue (boolean type)
customer_initiatedtrue or false
seller_keyed_intrue or false

Developers and partners that use Square developer products (such as the Web Payments SDK, In-App Payments SDK, and Square APIs) must ensure that their applications are SCA-compliant to minimize the impact of declined payments by following these guidelines:

Sellers that use Square Online and Square Invoices have their integrations managed by Square and don't need to flag transactions for SCA authentication.


  • SCA should be invoked through the verifyBuyer() function only when the buyer is present and has initiated the transaction.
  • In the EU, payments that don't provide authentication get a CARD_DECLINED_VERIFICATION_REQUIRED error for transactions that require authentication. This error means that the seller didn't implement verifyBuyer on the customer-initiated payments. For more information, see VerifyBuyerError.
Link to section

SCA in non-mandated markets

The SCA flow is started for a buyer if their payment card meets any of the conditions listed in the Square Risk Manager Glossary. For sellers outside of regions that require SCA, Square provides a mechanism in Risk Manager to let them opt in for 3DS on a location basis. For example, a seller might have an in-person location, an in-person and online location, and an online only location. Online payments are card-not-present payments and benefit from the added security of 3DS. In this case, a seller might opt in for 3DS in those locations.

A payment card might trigger the SCA authentication flow and verify the identity of the buyer without generating a payment alert. A payment alert is only created in Risk Manager if the payment appears to be suspicious or fraudulent. Sellers in the European Union can use Risk Manager to manage potential fraud even though 3DS is enabled for them by default.

Link to section

Enable SCA

To enable SCA, a non-EU seller uses an application integrated with a Square payments SDK to take a payment with a debit or credit card. If the application called the verifyBuyer function when getting a payment token, the seller can enable SCA in Risk Manager for the location that called the function. When enabled, SCA is active until the seller disables it. SCA cannot be enabled until verifyBuyer has been called by the application at least once.


SCA and Risk Manager are currently not supported for Japan-based sellers.

Link to section

Buyer verification and other authentication mechanisms

You can also configure the application to call verifyBuyer and enable other authentication mechanisms, as the buyer verification process checks if the application has any verification method to apply to the payment. Currently, SCA is the only authentication mechanism that Square supports.

Link to section

How it works

Learn how SCA works by walking through the steps in the following example:

StepFlow Illustration
1. Generate a token with the Square online payment SDK or in-app payment SDK. You can skip this step if you're charging a customer card on file.A graphic showing SCA being used.
2. Call verifyBuyer() with the payment token or the customer card ID and the transactional details. Square collects all the required device-based information.02
3. Square automatically checks whether the transaction requires Strong Customer Authentication.03
4. If a challenge is required, Square automatically displays the challenge to the buyer.04
5. When the SCA process is complete, you get back a verification token.05
6. Use the verification token along with the payment token and customer card ID to charge the customer using Square APIs, version 2019-06-12 or newer.06


Custom risk-score based SCA authentication private beta

If the seller has set up custom score rules and logic in Risk Manager, you can trigger SCA authentication based on the custom risk score by passing the custom risk score value in the verifyBuyer() method call with the customScore field. To try out this feature, contact your Square representative.

Link to section

Next steps

Read the following topic to learn how to modify a card entry method in your web application to verify a buyer's identity using additional secure authentication: