Skip to main content

Handling Soft Declines

In markets where the SCA regulation applies, card issuers possess the authority to "soft decline" an authorization that lacks full authentication.

A soft decline refers to a temporary rejection of a payment transaction by a financial institution due to reasons that can be resolved or mitigated.

Handling Soft Declines in Browser Flow​

If you are not redirecting to the PayU hosted payment page and using , there are two possible ways to deal with soft declines for browser flow:

When you opt not to redirect to the PayU hosted payment page and instead utilize card tokenization, there are two potential approaches to address soft declines for browser flow:

  • Resubmit the authorization.
  • Use PayU authentication page.

Resubmitting the Authorization​

To resubmit the authorization, follow this logic:

  1. For each failed card payment, retrieve the transaction data using transaction data retrieval.
  2. If the cardResponseCode in the response takes the value of SSD (soft decline), create a new order request with threeDsAuthentication.challengeRequested set to MANDATE.

By setting threeDsAuthentication.challengeRequested to MANDATE, you are prompting the card issuer to perform full authentication through a challenge.

IMPORTANT

After implementing the solution that involves sending a new OrderCreateRequest with threeDsAuthentication.challengeRequested set to MANDATE for resubmitting authorizations, please notify our to be excluded from the solution based on the PayU authentication page.

Using PayU Authentication Page​

Notes

This solution does not require any integration changes related to handling the WARNING_CONTINUE_3DS value returned in the order create response. However, it's important to note that this approach will result in PayU returning the redirection link for EVERY non-authenticated (one-click) card payment that is not flagged as RECURRING or STANDARD_MERCHANT.

To maintain the existing "one-click" experience for stored cards, the PayU system will attempt to utilize one of the available exemptions to avoid Strong Customer Authentication (SCA) on your behalf. However, if a soft decline occurs, the handling process will depend on the applicable flow.

For payments initiated from a website in a desktop or mobile web-view environment (known as the browser flow), the payer will be prompted to authenticate on PayU's authentication page.

Handling Soft Declines in SDK Flow​

To handle soft declines in the SDK flow, you need to check the decline reason code for each CANCELED order by retrieving transaction details.

If you find that a soft decline occurred (with cardResponseCode set to SSD), you can retry the payment by creating a new order with the challengeRequested parameter set to MANDATE. This value indicates that you want the card issuer to perform full authentication by means of a challenge.

Testing​

Notes

Below instruction regards testing when your sandbox account has been excluded from default configuration (soft declines not handled by PayU). To exclude your account from default config please and provide the shop id you are using.

To test a soft decline for any type of card payment, follow these steps:

  • Use the card data: 5100052384536818 with the expiry date 02/2032 and any CVV value.
  • Enter the card data either on the PayU hosted payment page, tokenize it via secure form (tokenization type SINGLE) or submit it to PayU in plain text (without tokenization),
  • Send a new order with totalAmount equal to or less than 300 pennies (regardless of currency) to exclude your payment from being authenticated via 3DS.

After performing above steps, you will receive an response with a SUCCESS status and a notification with a CANCELED status. To verify that the SSD status was the reason for the cancellation, you can retrieve the transaction details. This will allow you to confirm that the soft decline was properly handled in the transaction flow.

On this page