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.

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. Strong Customer Authentication refers to the usage of the 3-D Secure (3DS) protocol to verify the identity of a buyer at the time of an online purchase. Square applies 3DS to a payment in accordance with the UK/EEA PSD2 SCA Mandate, the Japan SCA METI Mandate, and/or individual seller risk rules set up in Risk Manager.

Currently, when paying online, buyers 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.

3DS - also known as "3-D Secure" 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 markets wherever Strong Customer Authentication (SCA) is required by local mandates.

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

With 3DS, 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 successfully authenticated through 3DS and the card involved is a Mastercard, American Express, JCB, Visa, Diners Club International or Discover card. Any of these cards that can be saved on file with Square can also use 3DS. For more information, see Charge and Store Cards for Online Payments.

Square advises all Square developers and partners operating in the European Economic Area (EEA), including the UK, or in Japan to take appropriate steps to be compliant with SCA enforcement to avoid an increase in declined payments for European or Japanese cardholders, respectively.

In the UK, banks have required cardholders to complete SCA, with full requirements in place since March 14, 2022. Across the rest of the EEA, banks have applied SCA in full since January 1, 2021, following a staggered rollout through 2021. In Japan, banks have required SCA for their cardholders since April 1, 2025.

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.

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 buyer initiated payments and seller keyed-in payment details:

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:

• If the buyer is present and initiates the payment, verify the buyer and set CustomerDetails.customer_initiated to true.

• If the buyer initiates the payment, but is not present (such as for a mail order / telephone only (MOTO) payment), then you don't need to verify the buyer, but instead set CustomerDetails.customer_initiated to true, and CustomerDetails.seller_keyed_in to true.

• If the seller initiates the payment and the buyer is not present, then you don't need to verify the buyer, but instead set CustomerDetails.customer_initiated to false.

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

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

To enable SCA in a non-mandated market, the seller uses an application integrated with a Square payments SDK to take a payment with a debit or credit card. If the application can verify a buyer, the seller can enable SCA in Risk Manager for the location that is taking the payment. When enabled, SCA is active until the seller disables it. SCA cannot be enabled until the integration has been added by the application.

For in-app transactions that require SCA and are made with a digital wallet, we recommend verifying the buyer. See Integrate Digital Wallets with the In-App Payments SDK for more information. For the Web Payments SDK, tokenizing the digital wallet will automatically verify the buyer’s card.

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

Step	Flow illustration
Call tokenize() with verification details included in the request
Square automatically checks if authentication required during tokenization
If challenge needed, display authentication challenge inline
Single payment token returned

Implement SCA in your application to start the SCA flow by reading the following topics:

• For Web Payments SDK: Add Strong Customer Authentication to a Card Payment
• For In-App Payments SDK: Verify a Buyer