After performing the registration alignment with Carat Portal support to enable integration with the anti-fraud service, at the start of a transaction HTML Payment (Learn more) the merchant must configure the property anti_fraud and send the appropriate anti-fraud parameters (depends on the institution that your merchant was set up), both properties must be within the scope of theadditional_data object.
The field anti_fraud determines how anti-fraud is applied and can contain the following values:
enabled_before_auth - Risk analysis will be performed BEFORE authorization of the payment. If the analysis is rejected, payment will not be started.
enabled_after_auth - Risk analysis will be performed AFTER authorization of the payment. If the analysis is rejected, the payment that has already been authorized will be canceled.
Attention:
For cases where the limits of intervals for automatic activation of Anti Fraud are configured in the merchant and a value of anti_fraud is passed in the creation of the transaction, the Carat Portal will only accept the value of anti_fraud passed if the transaction is between activation limits. And if the Anti Fraud automatic activation interval limits are configured in the merchant and an anti_fraud value is not passed in the transaction, the value enabled_after_auth will be assumed as default for the anti-fraud type. Important: intervals that allow the use of 3ds and anti-fraud together must not be used.
Anti-fraud parameters
The parameters depend on the institution that provides the anti-fraud service. Therefore, not all anti-fraud parameters available on Carat Portal will be effectively used.
Below are all anti-fraud parameters (regardless of institution).
Some parameters may appear repeatedly (for example, the gift property) and this is due to the risk analysis characteristic of each institution. For more details on how each institution uses each anti-fraud parameter, see the page for each anti-fraud integration.
Property
Description
Format
Required
currency
Payment currency
3 A
Yes
b2b_b2c
e-commerce type
3 A
No
item_amount
Value in cents of the total sum of the values of the items
< 1024 N
Yes
total_order_amount
Value in cents of the orders
< 1024 N
Yes
delivery_time_cd
Delivery time
< 50 A
No
qty_payment_types
Number of payments
1 N
No
ip (deprecated)
Order IP
< 50 A
Yes
gift
1 - If order is a gift 0 - If order is not a gift
1 N
No
gift_message
Gift message
< 8000 A
No
obs
Order observations
< 8000 A
No
sla_custom
Analysis SLA
4 N
No
origin
Order origin
< 150 A
Yes
reservation_date
Date of the flight reservation. Only for flight tickets.
Format da data: yyyy-mm-ddThh:mm:ss
No
nationality
Nationality of the order (for request of international analysis)
< 50 A
No
list_type_id
List type ID (only for customers that have a specific list)
1 N
No
list_id
Store’s list ID
< 200 A
No
sequential
Sequence of the payment
1 N
No
interest
Interest rate. Example: 5.00
< 4 N
No
interest_value
Absolute value of interest in cents. Example: 1000 (10 reais).
It can range from 1 to 100 defined by the merchant in an agreement with Cybersource
< 255 A
No
value
Value of the field defined by the merchant in an agreement with Cybersource
< 255 A
No
For payments using Konduto, Cybersource and Antifraude Fiserv: Parameters that exist in payer, billing and shipment when not passed to the transaction creation service via additional_data, will be requested in the payment screen. If the parameters are passed in the transaction creation service, you will not be asked to fill in the fields on the payment screen.
For payments using Konduto, Cybersource and Antifraude Fiserv: Parameters that exist in payer, billing and shipment when not passed to the transaction creation service via additional_data, will be requested in the payment screen. If the parameters are passed in the transaction creation service, you will not be asked to fill in the fields on the payment screen.