3DS Authentication
To enhance the security of your transactions, you can use the 3DS authentication feature, which involves cardholder validations directly with the card issuer. This feature depends on the offerings of the card network and the issuer, but most major networks already provide 3DS authentication in newer versions, such as 2.0 or above.
With a transaction authenticated by the issuer using 3DS in versions 2.0 or higher, the liability for chargebacks due to fraud shifts to the issuer. This process is known as the liability shift. It also prevents fraud from occurring without the cardholder's knowledge, as they may be challenged to confirm their possession of the card right before the authorization occurs.
Through our APIs, you have control over when to use 3DS authentication, and you can also choose when to proceed with the transaction authorization based on the authentication result.
To learn more about 3DS authentication: https://www.emvco.com/emv-technologies/3-d-secure/
Standard Checkout e Lightbox
At the moment of creating a checkout, it is possible to request the use of 3DS authentication. Additionally, the decision to proceed with the authorization based on the authentication response must be specified. If desired, the authorization will only be initiated after a successful authentication. Conversely, it is also possible to proceed with the authorization even if the authentication has not been successful.
Through the threeDomainSecurePolicy field, you specify whether:
- You want to authorize even without authentication by sending
ACTIVE - You want to authorize only if authenticated by sending
EXCLUSIVE
Transparent Checkout
In this type of integration, you have complete control over the operational flow. Right before requesting the transaction authorization, you can request authentication using the payer's provided data and then decide whether or not to proceed with the transaction authorization.
How it works?
During the payment process, the payer will fill in the data for the transaction, such as personal identification information and the card details they wish to use. Using this data, we can perform the following operations:
- Setup: Validates the possibility of initiating authentication with the provided data and ensures a unique key so that all operations identify the same authentication process.
- Enrollment: The first stage of authentication, where the card network and issuer are contacted with the cardholder's and card's data. The response to this operation can indicate a successful authentication, a failure, or that a challenge to the cardholder is required (next operation).
- Challenge: If the enrollment operation returns the need for a challenge, the payer should see an information confrontation experience (iframe), where the issuer may decide to:
- Send an SMS to the phone number registered by the cardholder in their records, which must be filled in directly in this experience;
- Request the content of a token generated by a device or application;
- Request confirmation directly in an application;
- Or any other method they wish to use to validate the authenticity of the payment with the cardholder.
- Authorization: The authentication data is sent along with the payment authorization request so that the card network and issuer are informed of this authentication and can cross-check the information. If this cross-check fails for any reason, the issuer and network may issue an authorization response indicating an authentication downgrade, meaning the issuer will not assume liability in case of a chargeback.
Accepted card brands
Authentications are accepted for cards from Mastercard, Visa, and Elo brands. If the payer enters a card from other networks, the setup stage will already indicate a denial, but authorization can still be performed if you choose to do so.
How to get access to the 3DS?
To enable the use of 3DS authentication in your operation, you should contact your commercial representative at PicPay to assess the cost variation in transaction fees.
See the API Reference