Antifraud Fiserv
#
Required credentialsAs mentioned in the "Overview - Required credentials" chapter, each institution has credentials that must be obtained for the integration. Fraud Detect services demand the credentials below:
- Private Key (Merchant Identification) - Private key of the merchant on Fraud Detect .
- Public Key (Merchant Code) - Public key of the merchant on Fraud Detect .
IMPORTANT: The credentials above should be obtained from Fraud Detect . It is recommended to contact Fraud Detect and receive guidance on how to obtain the credentials. Then, the merchant should contact Carat Portal support and send the credentials to register on Carat Portal.
#
Web Hook URL ConfigurationIn order for us to receive status updates from the risk analysis transactions, it is necessary to configure the Webhook URL on the Fraud Detect configuration environment.
Production URL:
https://esitef.softwareexpress.com.br/e-sitef/processarPost.se?src=fraud_detect
Homologation URL:
https://esitef-homologacao.softwareexpress.com.br/e-sitef/processarPost.se?src=fraud_detect
This URL must be configured for any status changes. To perform this configuration, please contact Fraud Detect Support.
#
Fraud Detect supports any card brand. Allowed card brandsIMPORTANT: Only credit transactions will be effectively analyzed by Fraud Detect . Debit transactions will be sent to the institution, but will only be stored for reporting and will not be analyzed.
#
Supported Carat Portal interfaces- Payment Link via Portal
- HTML Payment Link via API
- REST Payment
- REST Pre-Authorization
- HTML Payment
- HTML Pre-Authorization
#
Fraud Detect anti-fraud parameters (Payment Link via HTML)For now, the data collected for the risk analysis will only be informed during the payer's checkout. Soon, new fields may be sent in the payment creation request.
#
Fields collected during CheckoutThe fields collected during checkout are:
Field | Field Description | Required |
---|---|---|
Primeiro Nome do Comprador | First name of the payer. | Yes |
Sobrenome do Comprador | First name of the payer. | Yes |
CPF do Comprador | CPF of the payer. | Yes |
Telefone | Phone number of the payer. | Yes |
E-mail | Email of the payer. | Yes |
Nome (como está no cartão) | Name that is printed on the card used for the purchase. | Yes |
Endereco completo | Full billing address. | Yes |
Complemento | Complement of the billing address. | No |
CEP | Zip code of the billing address. | Yes |
País | Country of the billing address. | Yes |
Estado | State of the billing address. | Yes |
Cidade | City of the billing address. | Yes |
#
ExampleExample of the HTML payment request with risk analysis at Fraud Detect :
#
Fraud Detect Anti-Fraudin the Payment Link via PortalTo enable Fraud Detect anti-fraud for Payment Links generated by the Merchant Portal, please contact Carat Portal's support team.
#
Fraud Detect Antifraud via RESTAfter finishing your registration on Carat Portal, enabling the antifraud service integration, when initializing a REST payment (learn more) or REST pre-authorization (learn more), the merchant must send the anti_fraud
property and the antifraud parameters (depending on the institution you're using), both included in the additional_data
object.
The anti_fraud
field determines how the risk analysis will be applied and may contain the following values:
enabled_before_auth
- The antifraud will be executed BEFORE the payment authorization. If the analysis is rejected, the payment won't be initiated. In the case of a pre-authorization with a non-SiTef routing, if the antifraud requires a manual analysis, the pre-authorization transaction will be confirmed, and it will be up to the merchant to decide whether to capture or cancel the transaction.enabled_after_auth
- The antifraud will be executed AFTER the payment authorization. If the analysis is rejected, the payment that was already authorized will be cancelled. In the case of a pre-authorization with a non-SiTef routing, the transaction will always be confirmed, and it will be up to the merchant to decide whether to capture or cancel the transaction.
For customers who are using REST, it is interesting to add the settings from the links below to improve risk analysis and also to obtain the visitor_id.
#
Fraud Detect antifraud parametersBelow are described the antifraud parameters supported by Fraud Detect .
Note: If payer, shipment and billing_data structures are provided in the HTML call, they will not be requested in the checkout screen.
Parameter | Description | Format | Mandatory | |||
---|---|---|---|---|---|---|
additional_data | Additional transaction data. | |||||
visitor_id | Visitor identifier obtained using Fraud Detect JavaScript. | < 40 AN | NO | |||
additional_data .items[] | Shopping cart information | |||||
unit_price | Item unit price in cents | NO | < 10 N | |||
sku | Item product code | NO | < 100 AN | |||
quantity | Item quantity | NO | < 10 N | |||
id | Unique item identification, that may be its bar code or UPC. | NO | < 100 AN | |||
title | Product or service name | NO | < 100 AN | |||
discount_amount | Discount amount of the product in cents | NO | < 10 N | |||
description | Product description | NO | < 100 AN | |||
creation_date | Indicates the date of publication of the product on the merchant's site (Format: DD/MM/YYYY ) | NO | = 10 AN | |||
additional_data .payer | Customer information | |||||
id | Unique customer identifier. It may be any value (sequential, document, e-mail), as long as it's consistent on future orders. | YES | < 100 AN | |||
name | Customer name. | YES | < 100 AN | |||
surname | Customer surname. | YES | < 100 AN | |||
email | Customer e-mail. | YES | < 100 AN | |||
born_date | Customer birth date (format : YYYY-MM-DDTHH:MM:SS ) | NO | = 19 AN | |||
identification_number | Customer document number | NO | < 100 AN | |||
creation_date | Account creation date on the site (format: DD/MM/YYYY ) | NO | = 10 AN | |||
is_new_client | Boolean that indicates if the customer is using a recently created account in this purchase. | NO | < 5 T/F | |||
is_vip_client | Boolean that indicates if the customer is VIP or a frequent buyer. | NO | < 5 T/F | |||
additional_data .payer .phones[] | Customer phone information | |||||
ddi | Customer phone IDD | NO | < 100 AN | |||
ddd | Customer phone DDD | NO | < 100 AN | |||
number | Customer phone number. | NO | < 100 AN | |||
additional_data .billing_data .address | Billing address information | |||||
street_name | Billing street name. | NO | < 255 AN | |||
street_number | Billing street number. | NO | < 255 AN | |||
complement | Billing address complement. | NO | < 100 AN | |||
city | Billing city. | NO | < 100 AN | |||
state | Billing state. | NO | < 100 AN | |||
zip_code | Billing zip code. | NO | < 100 A N | |||
country | Billing country code, following ISO 3166-1 alfa-3. | NO | = 3 AN | |||
additional_data .shipment | Shipment information | |||||
name | Name of the recipient. | NO | < 100 AN | |||
surname | Surname of the recipient. | NO | < 100 AN | |||
additional_data .shipment .address | Shipment address information | |||||
street_name | Delivery street name. | NO | < 255 AN | |||
street_number | Delivery street number. | NO | < 255 AN | |||
complement | Delivery address complement. | NO | < 255 AN | |||
city | Delivery city. | NO | < 100 AN | |||
state | Delivery state. | NO | < 100 AN | |||
zip_code | Delivery zip code. | NO | < 100 AN | |||
country | Delivery country code, following ISO 3166-1 alfa-3. | NO | = 3 AN | |||
additional_data .travel | Travel information | |||||
transport_type | Travel transport type. (flight or bus ) | YES | < 6 AN | |||
expiration_date | Expiration date. (format: DD/MM/YYYY ) | NO | = 10 AN | |||
additional_data .connections[] | Travel connections information | |||||
journey_type |
| YES | < 7 AN | |||
origin_city | Origin city. | YES, if transport_type =bus | < 100 AN | |||
destination_city | Destination city. | YES, se transport_type =bus | < 100 AN | |||
from | IATA airport code of the origin airport | YES, if transport_type =flight | = 3 AN | |||
to | IATA airport code of the destination airport | YES, if transport_type =flight | = 3 AN | |||
departure_date | Departure date and time (format: YYYY-MM-DDTHH:MM:SS ) | YES | < 17 AN | |||
class | Seat class name (Ex: economy , business or first ) | NO | < 8 AN | |||
class_code | Seat class code. | NO | < 20 AN | |||
company | Airline name. | NO | < 20 AN | |||
additional_data .passengers[] | Passengers information | |||||
name | Passenger first name | YES | < 100 AN | |||
last_name | Passenger last name | YES | < 100 AN | |||
legal_document | Passenger document. | YES | < 100 AN | |||
legal_document_type | Passenger document type (5 = passport, any other number = id) | YES | < 8 AN | |||
birth_date | Passenger birth date (format: YYYY-MM-DDTHH:MM:SS ) | NO | < 17 AN | |||
nationality | Passenger nationality, following ISO 3166-1 alfa-3 | NO | = 3 AN | |||
is_frequent_traveler | Frequent traveler boolean | NO | < 5 T/F | |||
is_with_special_needs | Boolean which indicates if it's a passenger with special needs | NO | < 5 T/F | |||
frequent_flyer_card | Loyalty program type | NO | < 255 AN | |||
customer_class | Loyalty program category | NO | < 255 AN | |||
additional_data .hotel_reservations[] | Hotel reservation information | |||||
hotel | Hotel name. | YES | < 100 AN | |||
category | Hotel category. | NO | < 100 AN | |||
additional_data .hotel_reservations[] .address | Hotel address information | |||||
street_name | Hotel street name. | NO | < 255 AN | |||
street_number | Hotel street number. | NO | < 255 AN | |||
complement | Hotel address complement. | NO | < 100 AN | |||
city | Hotel city. | NO | < 100 AN | |||
state | Hotel state. | NO | < 100 AN | |||
zip_code | Hotel zip code. | NO | < 100 AN | |||
country | Hotel country code, following ISO 3166-1 alfa-3. | NO | = 3 AN | |||
additional_data .hotel_reservations[] .rooms[] | Hotel rooms information | |||||
number | Room number. | NO | < 100 AN | |||
code | Room code | NO | < 100 AN | |||
type | Room type. | NO | < 100 AN | |||
check_in_date | Check-in date and time (format: YYYY-MM-DDTHH:MM:SS ) | YES | < 17 AN | |||
check_out_date | Check-out date and time (format: YYYY-MM-DDTHH:MM:SS ) | NO | < 17 AN | |||
number_of_guests | Number of guests. | NO | < 9999 N | |||
board_basis | Feeding regime. | NO | < 100 AN | |||
additional_data .hotel_reservations[] .rooms[] .guests[] | Hotel room guests information | |||||
name | Guest name. | YES | < 100 AN | |||
document | Guest document. | NO | < 8 AN | |||
document_type | Guest document type:
| NO | < 8 AN | |||
birth_date | Guest birth date (format: YYYY-MM-DDTHH:MM:SS ) | NO | < 17 AN | |||
nationality | Guest nationality, following ISO 3166-1 alfa-3. | NO | = 3 AN | |||
additional_data .events[] | Event information | |||||
name | Event name. | YES | < 255 AN | |||
date | Event date and time (format YYYY-MM-DDTHH:MM:SS ) | YES | < 17 AN | |||
type | Event type:
| YES | < 9 AN | |||
subtype | Event type details. | NO | < 255 AN | |||
additional_data .events[] .venue | Event venue information | |||||
name | Venue name | NO | < 255 AN | |||
street_name | Venue street name | NO | < 255 AN | |||
street_number | Venue street number | NO | < 255 AN | |||
city | Venue city | NO | < 255 AN | |||
state | Venue state | NO | < 255 AN | |||
country | Venue country code, following ISO 3166-1 alfa-3. | NO | = 3 AN | |||
capacity | Venue capacity | NO | < 255 AN | |||
additional_data .events[] .tickets[] | Event tickets information | |||||
id | Unique ticket identifier. | NO | < 255 AN | |||
category | Ticket category:
| YES | < 10 AN | |||
section | Ticket section. | NO | < 255 AN | |||
premium | Premium ticket indicator. | NO | < 5 T/F | |||
additional_data .events[] .tickets[] .atendee | Event atendee information | |||||
name | Atendee name. | NO | < 255 AN | |||
document | Atendee document. | YES | < 100 AN | |||
document_type | Atendee document type:
| NO | < 100 AN | |||
birth_date | Atendee birth date (format: YYYY-MM-DDTHH:MM:SS ) | NO | < 17 AN |
ATTENTION: Parameters that exist in
payer
,billing
andshipment
when not passed to the transaction creation service viaadditional_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.
#
ExampleBelow is an example of a REST payment creation request with Fraud Detect risk analysis: