This document details the requirements for merchants that will integrate Garanti BBVA Fraud Module.
In addition to the information in the document, information such as endpoints used, request/response field names and types, error codes can be accessed via the link below and a sample post request can be sent.
Title | Value |
---|---|
MerchantId | 7000679 |
Password | 123qweASD/ |
MerchantId | 3424113 |
Password | 123qweASD/ |
Garanti Bank Security Platform Technical Integration Document
The fully authorized user determines the password to be used when creating the encoded hash value during messaging between the workplace system and Atalante services by entering the relevant values in the "Password" input fields on the screen.
This value is kept in the system by default when the fully authorized user first accesses the Fraud Module.
The user enters the password he/she has set in the "Password", "Password Repeat" fields and writes the values in the captcha on the screen in the relevant field and presses the SAVE button and the password is reset.
In Garanti BBVA Fraud Module, request messages are sent with the "requestHeader" header tag and its content. The fields that must be sent under the "requestHeader" tag and their contents are detailed in the table below.
Data Field | Necessity | Description | Length/Format/Values |
---|---|---|---|
gvpsMerchantNum | Mandatory | This is the field where the associated Garanti BBVA workplace number is sent. | The workplace number value allocated to the workplace by Garanti BBVA is sent in this field. |
hashData | Mandatory | It will be the information to be used to ensure the security of the sent request. With this information, sending transactions to the system other than the permitted workplace will be prevented. | The method of calculating the "hashData" value is detailed. |
orderId | Mandatory | This is the field where the order number of the transaction to be sent is sent. | |
transactionType | Mandatory | The transaction type information that the workplace will perform the provision must be sent in this field. Table 6 shows the values that the field can take. | |
uniqueId | Mandatory | It is the Unique ID value returned to the workplace during the device ID determination process. | The unique value obtained when the PageLoad process is finished is sent in this field. 24 characters long, alphanumeric. |
Sample request header message fragment is given below.
How to perform the hash calculations in the document is explained under this heading. The "hashData" value is calculated in two stages.
HashData= SHA1(MerchantNum&TransactionType&OrderID&UniqeuID&HashedPassword)
HashedPassword: UPPERCASE (SHA1 (Password&MerchantNum))
For workplace numbers less than 8 characters 0 must be added to the beginning of the number to complete 8 digits.
Example 1;
Workplace number: 123456
Workplace number to be added to the calculation: 00123456
Example 2;
Workplace number: 1234567
Workplace number to be added to the calculation: 01234567
For 8 character workplace numbers will be written as it is without any addition at the beginning of the workplace number.
Example;
Workplace number: 12345678
Workplace number to be added to the calculation: 12345678
For workplace numbers with more than 8 characters The workplace number will be 8 digits and 1 or more characters will be trimmed from the right of the workplace number and included in the hash calculation.
Example 1;
Workplace number 123456780
Workplace number to be added to the calculation: 12345678
Example 2;
Workplace number: 1234567801
Workplace number to be added to the calculation: 12345678
For MerchantNum and Password values, you can get information from our E-Commerce Support ETicaretDestek@garantibbva.com.tr team.
Merchants using the Garanti BBVA Fraud Module can ensure that a score is generated for each transaction by sending the fields shared below in the score query request.
The message structure to be created by the merchant must be in JSON format.
The sample message structure of the score enquiry request is given below.
In the score query request, under the "sellerDetails" tag, if there is more than one seller in the e-commerce store, the information should be obtained.
The fields to be sent in the score query request are as follows.
Data Field | Necessity | Description | Length/Format/Values |
---|---|---|---|
seller | Optional | If there is more than one vendor in the e-commerce store, the vendor information of the transaction should be sent in this field. | Format: String |
sellerScore | Optional | If the seller of the transaction in the e-commerce store has a rating in the system, the evaluation score should be posted in this field. | Format: Numeric |
A sample message thread is given below.
As a result of the scoring request, a reply containing the following data will be sent to the workplace.
Data Field | Description | Length/Format/Values |
---|---|---|
errorType | This is the field where error type information is transmitted. | |
returnCode | This is the field where the result code of the request response will be returned. | “00” – Success“99” – General Error“01” – Authentication Error “04” – Input Data Error |
responseMsg | This is the field where the answer text of the error code will be returned in erroneous returns. | “00” – Success“99” – General Error“01” – Authentication Error “04” – Input Data Error |
riskScore | The value of the generated risk score will be in this field. | It will return a value between 0 - 10000. |
riskScoreCutoff | The risk level of the risk score will be communicated to the workplace in this field. | HR - High Risk MR - Medium Risk LR - Low Risk |
isInBlacklist | The information that the transaction is risked due to blacklist will be sent to the workplace in this field. | If it is risked due to blacklist, "Y" value will be found in this field. Otherwise, "N" value will be returned in this field. |
tdsInd | It is the field that returns information about the E-Commerce permission and limit adequacy status of the card being processed. The information returned in this field can be interpreted and it can be decided whether the transaction will be made in 3DS or not.Limit increase for cards with insufficient limit and opening the permission for cards with closed E-Commerce permission can be done at once through the payment verification transaction via 3DS flow. For this reason, in cases where the tdsInd field returns 1, the merchant can direct the transaction to the 3DS flow and the transaction can be realised. | 0 Limit is sufficient, E-Commerce permission is open1 At least one of the following conditions: Limit is insufficient or E-Commerce permission is closed |
An example of a successful score query answer is given below.
If the transaction is in the Blacklist, then the transaction will be forwarded as risky without any scoring for the transaction.
If the transaction is in the blacklist, no scoring is performed for the transaction and no score is returned to the workplace. A reply containing the following data will be sent to the workplace for the blacklisted transaction.
Data Field | Description | Length/Format/Values |
---|---|---|
isInBlacklist | The information whether the transaction is blacklisted or not is transmitted to the workplace in this field. | "Y" - the process is blacklisted."N" - the process is not blacklisted. |
blacklistType | If the transaction is stuck in the blacklist, the information about the type of blacklist is transmitted to the workplace in this field. | "C"//card number "I"//ip address "D"//device "E"//email "P"//phone number "ID"//national number "NS"//name and surname |
An example of the score query answer stuck in Blacklist is given below.
If the transaction is stuck in the rule defined by the workplace, a response message will be returned under the "ruleEngineResults" tag containing the details of the relevant rule and the following data.
Data Field | Description | Length/Format/Values |
---|---|---|
catchedRuleMasterId | The rule id information defined by the workplace. | Format : String |
actionCode | It is the action code defined by the workplace after the transaction is caught by the rule and requested to be taken for the related transaction. | "00";//clear transaction "01";//block transaction "02"; //generate warning |
additionalActionCode | If action code = 02 is selected, these are additional action codes defined by the workplace. | "01";//3D secure mandatory "02"; //Encrypted transaction mandatory "03"; //Continue with pre-authorisation "04"; //Verify transaction |
catched | The information whether the transaction is caught by the rule is transmitted in this field. | true - The transaction was caught by the rule false - The transaction was not caught by the rule |
Below are links to custom code examples written in various programming languages. You can examine the codes written with predetermined values in detail through the link of your preferred programming language.
These examples contain the codes containing the relevant operation type and since they are written in different languages, you can also observe various approaches and practices. In this way, you can find the opportunity to work with better understandable and original examples of your preferred programming language.
Click for C# Code Examples.
Click for VB.Net Code Examples.
Click for Java Code Examples..
Click here for PHP Code Examples.
Please note that these examples are written with predefined values and you may need to take necessary adaptation and security measures for use in real projects.
You can access the list of country codes from this page..
You can access the list of province codes from this page.
You can access the list of district codes from this page.
You can access the list of product category codes from this page.
You can access the list of transaction type values from this page.
You can find the list of test cards on this page.
We would love to hear from you. Do you have problems/questions about services ? Send us detailed email about it ?
Send Us a Question Send Us a Question