Guides
  1. How-To

Deal with Strong Customer Authentication (SCA) declines

Strong Customer Authentication (SCA) is a European regulatory requirement designed to reduce fraud and make online payments more secure. When a payment is declined with an SCA-required error, the steps to resolve it depend on your integration method.

Hosted payment page

No action is required on your side. The Hosted Payment Page handles SCA automatically by prompting the customer to enter their CVV.

Server-to-server

When you receive an SCA-required decline, initiate a retry payment request with additional browser and device data collected from the customer's session. This gives the gateway the information it needs to complete 3DS authentication.

What to collect

In addition to the standard paymentSource, sku, and consumer fields, include the following in your retry request:

From the customer's payment form:

  • cvv

From the customer's browser:

  • deviceId
  • userAgent
  • browserAcceptHeader
  • browserJavaEnabled
  • browserLanguage
  • browserColorDepth
  • browserScreenHeight
  • browserScreenWidth
  • browserTimezone

Option 1: Retry with raw card data

Send a POST /payment request with paymentSource.type = "card", including all the fields above alongside the standard card fields (number, expirationMonth, expirationYear, cvv).

Option 2: Retry using a stored payment account

Send a POST /payment request with paymentSource.type = "paymentAccountIdWithCvv", including all the browser fields above alongside paymentAccountId and cvv.

Tokenization

When you receive an SCA-required decline on a tokenization integration, re-tokenize the card using the stored payment account and the customer's fresh CVV, then retry the payment with 3DS enabled.

Step 1: Re-tokenize

Tokenize the following fields by calling POST /tokenizeWithPaymentAccountId:

  • paymentAccountId
  • consumerId
  • cvv

You receive both paymentAccountId and consumer.id in the IPN for each transaction. Display the masked card number (number) from the IPN to your customer on the payment form. This lets them identify which card they're entering the CVV for. The number field contains the first six and last four digits of the card. If you don't have it in context, retrieve it via the Feed API.

Step 2: Collect browser data

While the customer is on your payment form, collect the following from their browser:

  • deviceId
  • userAgent
  • browserAcceptHeader
  • browserJavaEnabled
  • browserLanguage
  • browserColorDepth
  • browserScreenHeight
  • browserScreenWidth
  • browserTimezone

Step 3: Retry the payment

Send a POST /payment request with:

  • paymentSource.type = "token"
  • paymentSource.value set to the token from Step 1
  • paymentSource.3ds = true
  • All browser fields from Step 2 in the consumer object