Card Storage and Switch Application offers a professional API set that enables businesses to manage online payments securely and efficiently. This special API set allows businesses to securely store customer card information, while also enabling them to initiate payment orders to multiple bank Virtualpos through this stored card data or unmasked card information.
Thanks to the Switch Management screens, businesses can manage their payment processes effectively by easily performing transactions such as cancellation, refund and pre-authorization closure. In addition, the application provides businesses with up-to-date data and information by offering the ability to instantly track transaction and order status.
Card Storage and Switch Application aims to provide businesses with a reliable payment infrastructure by focusing on the security of customer data and the smooth functioning of payment processes. With its professional and reliable service approach, it is designed to facilitate the payment acceptance processes of businesses and provide customers with an uninterrupted payment experience.
The TEST BASE URL to be used for testing Card Storage and Switch services is as follows:
TEST BASE URL: https://gbtaksimtunel-integration.garanti.com.tr/
Note: This TEST BASE URL represents the virtual environment offered by Garanti Bank and is intended to be used for testing purposes instead of real transactions. Transactions in this environment do not have real financial implications as in the live environment and only work through test scenarios.
The test environment allows testing the performance and reliability of the application by simulating different scenarios and error conditions. It can also be used to verify that API requests and responses are processed correctly.
During testing, it is important to know how to react to possible error situations, how to handle errors and make sure that the system is working correctly. Testing is also important for security and compliance, and a successful testing phase must be achieved before going live.
Keep in mind that bugs in the test environment may be temporary. The development team should prefer to contact ETicaretDestek@garantibbva.com.tr support in case of recurring bugs. In this way, problems will be solved more quickly and effectively, ensuring that the testing process proceeds efficiently. Successful testing contributes greatly to the safe and smooth transition of the application and systems to the live environment.
The following information can be used to send API requests in the test environment. These values will be used in all request types:
Title | Value |
---|---|
Switch ID: | CC82C381E078482AB328943FCCB7100C |
Switch Password : | 123asdASD@ |
This is the authentication information that will be used to test the Card Storage and Switch APIs. Care must be taken to use these credentials correctly in order to perform the tests successfully and get accurate results. Making sure that API requests are made with these credentials is important for the reliability and success of the tests.
In order to send requests with real data in the production environment of the merchant, after the integration is completed in the test environment, the merchant must obtain the Switch ID value by sending the Garanti Sanalpos terminal number to ETicaretDestek@garantibbva.com.tr.
Based on the obtained Switch ID value, the hash data created for security purposes in API requests must be calculated. The Switch Password of the merchant must also be included in this hash data account. Details about the hash calculation will be explained in the following sections.
The Switch Password of the member workplace must be created under the Password Update menu on the management screens of the member workplace. This process is performed by the admin user of the merchant.
Detailed information about creating a Switch Password can be found under the "Password Update" heading. In this way, merchants can securely make API requests with real data and successfully complete the GarantiBBVA Switch integration.
The following describes the header tag and fields of a sample request message to be sent to the Warranty Switch APIs:
The "HashedData" field is used to verify the integrity of the API request for security purposes. The following steps are followed to calculate this field:
• Concatenate: First, the values "requestId", "swtId", "userId" and "timestamp" are concatenated.
• Hashing: Next, this concatenated value is converted into a hash value using the SHA256 algorithm.
• Uppercase: Finally, the resulting hash value is converted to uppercase.
The sample response header information and the hash calculation method for this information to verify the hashedData parameter in the response returned in the transaction results are as follows:
The "timestamp" field in the Response is returned as Unix Timestamp, but this value must be used in String format for hash calculation. Therefore, the Unix Timestamp value must be converted to String format.
The following steps are followed for HashedData calculation:
• Concatenate: Concatenate "requestId", "swtId", "returnCode", "reasonCode", "message" and "timestamp.getTime()". With "timestamp.getTime()" the Unix Timestamp value is converted into String format.
• Hashing: This concatenated value is converted into a hash value using the SHA256 algorithm.
• Uppercase: Finally, the resulting hash value is converted to uppercase.
The hashedData value is the same as the value specified in the sample response header. In this way, the correctness of the hashedData value in API responses can be verified and data integrity is ensured.
With Switch Common Payment page, payment flow can be started by offering "Payment by Card" and "Payment by GarantPay" options to the customer. These flows are only used for sales (auth) payment type.
In this flow, the flow is started with the parameters sent by the merchant to the service. In the parameters returned from the service, there is a link specific to the relevant request. This link is transaction-specific, expires in 1 hour and is for single use only. Switch Common Payment page is opened via the relevant link and information is entered to the customer.
The parameters that should be sent to the SOS service in addition to the Request Header tag are as follows:
Field | Type | Requirement | Length | Description |
---|---|---|---|---|
additionalData | String | No | Max 120 Character | Used for sending information such as policy number etc. to be associated with the transaction. |
currencyNumber | String | Yes | 3 Character | Exchange rate information. 3 digit ISO standard codes must be sent. Example : 949 |
installmentCount | String | If the installments in the bank definition will be used or if the transaction will be made non installments; noIf the transaction will be made with installments; yes | Max3KCharacter | If an installment transaction will be sent, the number of installments should be sent in this field. For example; It should be sent as '3' for 3 installment transactions. |
motoInd | String | Yes, if MoTo operation will be performed | 1 Character | If Mail / Phone order transaction is sent, it should be marked as 'Y'. |
orderGroupId | String | No | Max 36 Character | Order group number of the transaction. |
orderId | String | No | Max 36 Character | Order number of the transaction. It must be determined specifically for each transaction. |
transactionType | String | Yes | - | The field where the transaction information is sent. It should be sent as "sales" for sales transactions. |
authType | String | Yes | This field is the field where the transaction validation type is selected." If "PAY" value is given, the transaction proceeds as non3DS, if "3D_PAY" value is given, the transaction proceeds as 3DS. | |
txnAmount | String | Yes | - | This is the field where the transaction amount is transmitted. It is necessary to separate the penny information with a period. Example : 1.45 |
Field | Type | Requirement | Length | Description |
---|---|---|---|---|
bankId | String | No | - | This field is used if the transaction is to be sent through the VirtualPOS of a specific bank. Value that can be sent: Bank Code and Name: 64: İŞ BANK A.Ş. 62: T.GARANTİ BANKASI A.Ş. 46: AKBANK T.A.Ş. 111: QNB FINANSBANK A.Ş. 10: T.C. ZİRAAT BANKASI A.Ş. 12: T. HALK BANKASI A.Ş. |
Field | Type | Requirement | Length | Description |
---|---|---|---|---|
addressDetail | String | No | Max 256 Character | Invoice address details (District, neighborhood, street, door code etc.). |
city | String | No | Max 50 Character | City information to send invoice. |
companyName | String | No | Max 64 Character | Company information to send invoice. |
country | String | No | Max 50 Character | Country information to send the invoice. |
String | No | Max 128 Character | E-mail address of the person to whom the invoice will be sent. | |
gsm | String | No | Max 16 Character | Cell phone number of the person to whom the invoice will be sent. |
lastName | String | No | Max 50 Character | Surname of the person to whom the invoice will be sent. |
name | String | No | Max 50 Character | Name of the person to whom the invoice will be sent. |
phone | String | No | Max 36 Character | Telephone information associated with the location where the invoice will be sent. |
zipCode | String | No | Max 16 Character | Postal code of the address where the invoice will be sent. |
Field | Type | Requirement | Length | Description |
---|---|---|---|---|
cvv | String | No | 3 Character | The 3-digit number on the back of the card. |
expireMonth | String | No | 2 Character | The month on the card. |
expireYear | String | No | 2 Character | The year on the card. |
first6 | String | No | 6 Character | The first 6 digits of the card. |
holderName | String | No | Max 50 Character | The name on the card. |
last4 | String | No | 4 Character | The last 4 digits of the card. |
number | String | No | Min : 15 CharacterMax : 30 Character | The number of the card. |
token | String | No | 32 Character | TokenID associated with the card returned as a result of the Token Import operation. |
Field | Type | Requirement | Length | Description |
---|---|---|---|---|
customerNumber | String | No | Max 20 Character | Garanti Bank customer number. |
String | No | Max 128 Character | Customer e-mail address information. | |
gsm | String | No | Max 16 Character | Customer cell phone number information. |
ip | String | No | Max 20 Character | Customer IP address information. It must be sent in ipv4 format. |
lastName | String | No | Max 50 Character | Customer last name information. |
name | String | No | Max 50 Character | Customer first name information. |
nationalNumber | String | No | Max 20 Character | Customer ID number information. |
taxIdNumber | String | No | Max 20 Character | Customer tax number information. |
Field | Type | Requirement | Length | Description |
---|---|---|---|---|
list | List | Yes | - | This is the field where the installment information list is sent. List details can be accessed via Table-1 |
useBankInstallmentRates | String | No | - | This is the field where company bonus usage information is sent. If company bonus usage is desired, "true" can be sent, if not, "false" can be sent. |
Field | Type | Requirement | Length | Description |
---|---|---|---|---|
errorUrl | String | Yes | - | The address of the workplace where the erroneous transaction response will be returned will be included in this field. |
resultPageCountdow n | String | Yes | - | This is the field where the countdown time for redirection to the merchant result page is specified. |
successUrl | String | Yes | - | The address of the workplace where the successful transaction response will be returned will be included in this field. |
Field | Type | Requirement | Length | Description |
---|---|---|---|---|
addressDetail | String | No | Max 256 Character | The detailed address field information of the shipping address will be included. |
city | String | No | Max 50 Character | The city name of the shipping address will be included. |
companyName | String | No | Max 64 Character | The company name of the shipping address will be included. |
country | String | No | Max 50 Character | The country name of the shipping address will be included. |
String | No | Max 128 Character | Mail information of the shipping address will be included. | |
gsm | String | No | Max 16 Character | GSM information of the shipping address will be included. |
lastName | String | No | Max 50 Character | The surname information of the person belonging to the invoice address will be included. |
name | String | No | Max 50 Character | The name of the person belonging to the invoice address will be included. |
phone | String | No | Max 36 Character | Phone information of the shipping address will be included. |
zipCode | String | No | Max 16 Character | The postal code information of the shipping address will be included. |
Field | Type | Requirement | Length | Description |
---|---|---|---|---|
inquiryCardRew ard | String | No | - | This is the field where card reward type usage information is sent. If card reward type usage is desired, "true" can be sent, if not, "false" can be sent. |
inquiryFirmRew ard | String | No | - | This is the field where company bonus usage information is sent. If company bonus usage is desired, "true" can be sent, if not, "false" can be sent. |
Field | Type | Requirement | Length | Description |
---|---|---|---|---|
amount | String | Yes | - | This is the field where the installment information list is sent. List details can be accessed via Table-1 |
count | String | Yes | Max 3 Character | This is the field where the number of installments is transmitted. |
The fields to be returned from the SOS service in addition to the response header tag are as follows:
Field | Type | Description |
---|---|---|
url | String | This is the field where the Sw itch co-payment page link is transmitted. |
expireDate | String | This is the field where the expiration time of the sw itch common payment page link is transmitted. |
The URL returned from the SOS service opens the Switch Common Payment Page shown below. On this screen, there are "Payment by Credit Card" and "Payment by GarantiPay" options.
Customers using BonusFlaş with the GarantiPay flow can make payments by selecting a card through the application.
Payment with GarantiPay can be made with two pieces of information:
GSM login
With TCKN entry
The flow is the same for both options. When the customer presses the "Continue" button after entering his/her GSM or Turkish ID number, a notification is sent to his/her BonusFlaş installed device that matches the information he/she entered.
When the notification is clicked, the BonusFlaş application directly opens the "Payment with GarantiPay" screen on the device and takes the card and installment / reward usage preferences, if any.
After the customer makes their selections and completes the payment, the transaction result information is displayed on the Switch common payment page, including the transaction code and authorization code information.
In cases where the fields sent in API requests do not comply with the Card Storage and Switch system, the API will return a Map<String, String> named "errorMap" in addition to the "header" section in the response. This "errorMap" will contain information about which data is corrupted and why the data is corrupted. In this way, the relevant fields need to be edited and resubmitted.
The sample request response with ErrorMap is as follows:
• Smart Switch system is integrated with more than one bank and the data format of the orderid fields of these banks may be different from each other. In order to prevent primary transactions from receiving an error due to the orderid field, a new orderid specific to the virtualpos where the Switch will route the transaction can be generated. Switch's decision whether to generate a new orderid or not can be managed with the generateOrderId parameter to be sent by the workplace.
• vposOrderId is the orderId value generated by the Switch and transmitted to the virtualpos if generateOrderId is sent as "Y" or empty in the request message or if this field is not sent at all.
• If the generateOrderId field is sent as "N", the Switch will not generate a new vposOrderId according to the format of the virtual platform to which the transaction will be routed. Since the orderid transmitted by the workplace will be forwarded to the destination virtualpos in the transaction, if the orderid is not in the format expected by the virtualpos, the virtualpos may error the transaction request due to the related field.
• If generateOrderId field "N" is sent but orderid value is not transmitted, Switch generates an orderid but this id is not created according to the format of the destination pos.
• If the orderId field is full in transaction requests where the generateOrderId field is sent "Y", sent empty or this field is not sent at all, this value continues to return in the orderId field in the response message. However, the transaction must be displayed with the vposOrderId value from the bank screens. Both orderId values will be displayed on the Switch screens; on these screens, the vposOrderId value is displayed under the Bank Order Number, and on the Transaction Detail screen, it is displayed in the ORDER_ID field under the Bank Provision Detail. If the orderId field is empty in transaction requests where the generateOrderId field is sent "Y", sent empty or this field is not sent at all, the Switch creates a different vposOrderId value with a different orderId value.
• If the orderId field is empty in operation requests where the generateOrderId field is sent "Y", sent empty, or not sent at all, an orderid and a vposOrderID value are generated.
• In transaction requests where the generateOrderId field is sent "N", the orderId value of the transaction and the vposOrderId value will be the same.
• In the order inquiry service, the value in the orderId field returned as a result of the primary transaction should always be sent
The return-reason codes to be returned from the Card Storage and Switch system and their descriptions are given in the table below.
Refund Code | Reason Code (Sub-Return Code) | Description |
---|---|---|
00 | 00 | The transaction was successful. |
01 | 01 | This error is received when the Acquirer does not validate the discarded transaction. For example, this error will be received in a case where the sales request fails or the validation fails in the 3D HTML request. The order query service returns the error code 01 in the header for failed transactions in the query response. |
01 | 02 | The order inquiry service returns for transactions that do not have virtualpos in the query response. Reason Code 01, not 02, will be returned for canceled transactions that could not be forwarded to Nestpay virtualpos. |
02 | 04 | The order inquiry service returns for 3D transactions for which there is no sanalposta in the query response. When this answer is received, it is possible that the 3D transaction has not been completed yet, so a new query can be sent. The query can be sent until Reason Code 00 or 01. However, if the cardholder has abandoned the transaction and it has not been finalized, the Reason Code will always remain 04. |
03 | 03 | Virtualpos requested to send a request cannot be processed |
10 | 1000 | Invalid http request type. This error is received when the system cannot read the incoming http request. |
11 | 1100 | Request validation error. The errorMap returned in the response contains the details of the error. It is necessary to edit according to the instructions here. |
12 | 1200 | The transaction could not be performed with the orderId value found in the transaction. A request should be made with a new orderId. |
12 | 1201 | The exchange rate in the request is not the same as the exchange rate in the order. |
12 | 1202 | Valid order not found error. The order information to be processed is not available in the system. For example, this error is received if a cancellation or return is sent for a transaction that is not sold. |
13 | 1300 | No valid transaction found error. The transaction information to be processed is not available in the system. For example, if there is an order in the request, but the transaction could not be found, it will give this error. |
13 | 1301 | Invalid transaction type. The transaction being attempted is not allowed. For example, a return request can only be applied to transactions with a sale. This error is received if a return request is sent to a different transaction type than the original sale. This also applies to a cancel request. |
13 | 1302 | This error is received if a cancel or refund request is sent for a failed sale. |
31 | 3101 | The virtualpos response could not be processed by Switch. |
67 | 6700 | Encryption error. Generally a temporary error. It is necessary to try several operations again. In case it happens too often, please contact ETicaretDestek@garantibbva.com.tr. |
78 | 109 | To get the token you need to send (full card + skt) or (first 6 - last 4 and customer/ID number). |
78 | 300 | An error was encountered while encrypting the card during the token request. The transaction should be tried again. |
78 | 401 | The token could not be generated because the status of the card sent in the token request was not available for authorization. The status of the card should be checked. |
78 | 402 | The status of the token request card is not available for token retrieval. The status of the card should be checked. |
78 | 500 | No valid parameter definition found during token request. A parameter definition is required for the sw tId sent in the request. For this, please contact ETicaretDestek@garantibbva.com.tr. |
78 | 500 | Token not found. The sent token information should be checked. There may be an attempt to make a transaction with a deleted token. |
78 | 99 | General error. In some cases it may be temporary. In case it is received too often, ETicaretDestek@garantibbva.com.tr can be contacted. |
83 | 8300 | Data error. The data in the request sent should be checked. If the problem is not detected, the E-Commerce Support team should be contacted. |
99 | 99 | System error. In some cases it may be temporary. If it is received too often, ETicaretDestek@garantibbva.com.tr can be contacted. |
Below are links to custom code examples written in various programming languages. You can examine in detail the code written in your preferred programming language with predefined values.
These examples contain code for the relevant type of operation and since they are written in different languages, you can 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 here for C# Code Examples.
Click here for VB.Net Code Examples.
Click here 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 to use them in real projects.
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