-
Virtual POS
Virtual POS Transactions General Concepts
Garanti Virtual POS is a secure payment solution created to receive credit card payments for online sales.
Merchants can open an online branch in their stores and turn it into a sales platform that never closes with Garanti Virtual POS. This contributes to increasing both the number of customers and turnover.
The following transactions are generally performed under Garanti Virtual POS:
- Sales Transactions
- Common Payment Page Operations
- Cancellation Procedures
- Refund Procedures
- Closing Operations
- Inquiry Procedures
This document describes the steps required for merchants to provide non 3Ds Additional Field transactions under Garanti Virtual POS, the operations that must be performed within each step, and the structures of the transaction requests sent and response messages received.
Virtual POS Additional Area Transactions
Within the Virtual POS request structure, the request structure can be modified with different additional fields in accordance with different needs. These additional fields and their purposes are briefly explained below.
1. Address Sending:
Address information can be sent to VirtualPoS during the transaction. The information sent is displayed on the order detail pages for information purposes.
2. Product Information Submission:
Information about the product sold during the purchase can be sent to the Virtual POS with the transaction. In this case, product information is displayed in transaction details and product report pages.Information about the product sold during the purchase can be sent to the Virtual POS with the transaction. In this case, product information is displayed in transaction details and product report pages.
3. Custom Field Submission:
It is a structure that allows some special information to be received during the transaction to appear on virtual pos screens and documents received from virtual mail.
The 1st special field among the special fields is sent to Garanti Bank. This field is shown in the reports received by the bank.
With the change made in the workplace definitions, it can be ensured that the values sent in this field appear in the card in-period transactions and card statements in the workplace name field.
For the use of custom fields, the workplace admin user must activate the custom fields to be used from the custom field definitions. Custom fields sent without being activated will cause an error. If you want the special field number 1 to go to the bank side, the phrase "appear on the bank side" should be checked.
In order for the custom fields to appear on the listing screens, they must be selected by the user from the custom field selection page. The selected custom fields appear as a column on the right side of the listing pages.
3D Concept
3D Secure is a version of the application on VirtualPoS where cardholders are verified with a password on PoS. The cardholder is directed to the verification screens of the card bank to use a password in the transaction. The cardholder enters the information requested by his/her bank on these screens and shows that the card actually used is his/her own card.
After verification, the verification status is returned to the merchant bank (merchant). Then, depending on the status of the 3D information, the authorization process is carried out or the transaction is terminated.
3D Secure is supported by Master, Visa and American Express (Amex) cards. Merchants using 3D model (information about merchant models is given below) are required to come directly to provisioning without performing 3D verification for cards other than Mastercard, Visa and Amex. Since 3D secure is not supported, the responsibility for Fraud in such transactions belongs to the merchant. The merchant must take measures to protect itself.
Virtual POS Transactions Non 3ds
This is when the transaction is concluded without touching any 3D secure stage during the authorization flow. In this type of transaction, the customer's "I didn't do it" objections turn into a chargeback request. The chargeback process is evaluated by requesting evidence from the merchant that the transaction was made by the customer. In 3D transactions with successful verification, "I did not do it" claims are terminated by the bank.
Test / Prod Environment Selections:
For Virtual POS Sales transactions, it is possible to proceed with 2 different methods by the merchant. If the merchant wishes, they can make all the improvements in the test environment. Alternatively, necessary improvements can be made for these transactions directly in the broadcast environment.
According to the method to be selected by the merchant, before starting Virtual POS sales transactions, the first transactions must be made according to the appropriate one of the following headings:
If the work to be done is carried out in a test environment, the following predefined values can be used as they are:
| Parameter | Value |
|---|---|
| MerchantID | 7000679 |
| ProvUserID | PROVAUT / PROVRFN / PROVOOS |
| ProvisionPassword | 123qweASD/ |
| TerminalID | 30691297 |
| StoreKey | 12345678 |
In the studies to be carried out in the test environment "https://sanalposprovtest.garantibbva.com.tr/VPServlet" url will be used.
A panel where the operations performed in the test environment can be monitored and displayed at this address you can access.
| Variable | Value |
|---|---|
| Kullanıcı Adı | 99999999999 |
| Passcode | Destek04 |
| Password | 147852 |
Not: In the event of an error in the password process, please try a second time before making a second attempt. Send Us a Question Please provide information with the form.
List of all test cards that can be used in the test environment from this page you can reach.
When proceeding with this method, the passwords to be used by the merchant in the setup as the first step are (“PROVAUT”,“PROVOOS”, “PROVRFN” ve “3D” (storekey) passwords) Virtual POS First Steps virtual POS management panel as specified in the document.
Passwords and accounts created in this way will be used in the next steps.
In the studies to be carried out in PROD environment "https://sanalposprov.garanti.com.tr/VPServlet" url will be used.
Hash Algorithm
This document explains step by step how to create the data required for the <HashData> tag in the request message, which is used under many transaction types.
The <HashData> tag in the request messages is the field that allows the password verification of the user. Hash creation details are explained separately below.
In the new VirtualPoS application, the HASH structure is used to prevent the password of the terminal from circulating openly.
Hash account:
1. SHA1 in the calculation of hashedpassword information
2. SHA512 algorithm is used to calculate the hashvalue.
In the hash calculation, a two-part HASH structure is used. In the first stage, the hashedpassword value will be obtained using the SHA1 algorithm by juxtaposing the provisioning password with the terminal number.
The operations required to generate hash are presented below for different programming languages:
public static string Sha1(string text) {\n var provider = CodePagesEncodingProvider.Instance;\n Encoding.RegisterProvider(provider);\n\n var cryptoServiceProvider = new SHA1CryptoServiceProvider();\n var inputbytes = cryptoServiceProvider.ComputeHash(Encoding.GetEncoding(\"ISO-8859-9\").GetBytes(text));\n\n var builder = new StringBuilder();\n for (int i = 0; i < inputbytes.Length; i++) {\n builder.Append(string.Format(\"{0,2:x}\", inputbytes[i]).Replace(\" \", \"0\"));\n }\n\n return builder.ToString().ToUpper();\n}\n\npublic static string Sha512(string text) {\n var provider = CodePagesEncodingProvider.Instance;\n Encoding.RegisterProvider(provider);\n\n var cryptoServiceProvider = new SHA512CryptoServiceProvider();\n var inputbytes = cryptoServiceProvider.ComputeHash(Encoding.GetEncoding(\"ISO-8859-9\").GetBytes(text));\n\n var builder = new StringBuilder();\n for (int i = 0; i < inputbytes.Length; i++) {\n builder.Append(string.Format(\"{0,2:x}\", inputbytes[i]).Replace(\" \", \"0\"));\n }\n\n return builder.ToString().ToUpper();\n}\n\npublic static string GetHashData(string userPassword, string terminalId, string orderId, string cardNumber, ulong amount, int currencyCode) {\n var hashedPassword = Sha1(userPassword + \"0\" + terminalId);\n return Sha512(orderId + terminalId + cardNumber + amount + currencyCode + hashedPassword).ToUpper();\n}
Public Shared Function Sha1(ByVal text As String) As String\n Dim provider = CodePagesEncodingProvider.Instance\n Encoding.RegisterProvider(provider)\n Dim cryptoServiceProvider = New SHA1CryptoServiceProvider()\n Dim inputbytes = cryptoServiceProvider.ComputeHash(Encoding.GetEncoding(\"ISO-8859-9\").GetBytes(text))\n Dim builder = New StringBuilder()\n\n For i As Integer = 0 To inputbytes.Length - 1\n builder.Append(String.Format(\"{0,2:x}\", inputbytes(i)).Replace(\" \", \"0\"))\n Next\n\n Return builder.ToString().ToUpper()\nEnd Function\n\nPublic Shared Function Sha512(ByVal text As String) As String\n Dim provider = CodePagesEncodingProvider.Instance\n Encoding.RegisterProvider(provider)\n Dim cryptoServiceProvider = New SHA512CryptoServiceProvider()\n Dim inputbytes = cryptoServiceProvider.ComputeHash(Encoding.GetEncoding(\"ISO-8859-9\").GetBytes(text))\n Dim builder = New StringBuilder()\n\n For i As Integer = 0 To inputbytes.Length - 1\n builder.Append(String.Format(\"{0,2:x}\", inputbytes(i)).Replace(\" \", \"0\"))\n Next\n\n Return builder.ToString().ToUpper()\nEnd Function\n\nPublic Shared Function GetHashData(ByVal userPassword As String, ByVal terminalId As String, ByVal orderId As String, ByVal cardNumber As String, ByVal amount As ULong, ByVal currencyCode As Integer) As String\n Dim hashedPassword = Sha1(userPassword & \"0\" & terminalId)\n Return Sha512(orderId & terminalId & cardNumber & amount & currencyCode & hashedPassword).ToUpper()\nEnd Function
public static String calculateHash(String data, String algorithm, String charset) throws UnsupportedEncodingException, NoSuchAlgorithmException {\n\tMessageDigest md = MessageDigest.getInstance(algorithm);\n\tbyte[] databytes = data.getBytes(charset);\n\t\n\tmd.update(databytes);\n byte[] hashBytes = md.digest();\n \n return byteArray2HexaDecimal(hashBytes);\n}\n\npublic static String sha1(String data) throws UnsupportedEncodingException, NoSuchAlgorithmException { \n return calculateHash(data, \"SHA-1\", \"ISO-8859-9\").toUpperCase();\n}\n\npublic static String sha512(String data) throws UnsupportedEncodingException, NoSuchAlgorithmException { \n return calculateHash(data, \"SHA-512\", \"ISO-8859-9\").toUpperCase();\n}\n\npublic static String getHashData(String userPassword, String terminalId, String orderId, String cardNumber, Long amount, int currencyCode) {\n var hashedPassword = sha1(userPassword + \"0\" + terminalId);\n return sha512(orderId + terminalId + cardNumber + amount + currencyCode + hashedPassword);\n}
private function GenerateSecurityData($terminalId)\n {\n $password = \"password\";\n\n $data = [\n $password,\n str_pad((int)$terminalId, 9, 0, STR_PAD_LEFT)\n ];\n\n $shaData = sha1(implode('', $data));\n\n return strtoupper($shaData);\n }\n\n public function GenerateHashData()\n {\n $orderId = \"order_id\"; //must be uniqe\n $terminalId = \"terminal_id\"; //must be integer\n $cardNumber = \"1234123412341234\"; //card number\n $amount = \"100\"; //amount\n $currencyCode = \"currency_code\"; //must be int\n\n $hashedPassword = GenerateSecurityData($terminalId);\n\n $data = [\n $orderId, $terminalId, $cardNumber, $amount, $currencyCode, $hashedPassword\n ];\n \n $shaData = strtoupper(hash(\"sha512\", implode('', $data)));\n\n return strtoupper($shaData);\n }
Request Structure
The request structure required for the Virtual POS non 3Ds private field submission process is specified in the table below. The information and explanations required for each tag under the main tag in the first column in the table should be examined and the request message should be provided according to the rules specified in this table:
<?xml version=\"1.0\" encoding=\"iso-8859-9\"?>\n<GVPSRequest>\n\t<Mode>TEST</Mode>\n\t<Version>512</Version>\n\t<Terminal>\n\t\t<ProvUserID>PROVAUT</ProvUserID>\n\t\t<HashData>E88EA8FBFAECA0516911851A22D3F06C3D7CB64B830B20D1B4DEB7F4C0CCD4773AA9F872F28124F843EBB06B41D0CA137F5C61775A043CEBDA985A8E85BA0DEF</HashData>\n\t\t<UserID>PROVAUT</UserID>\n\t\t<ID>30691297</ID>\n\t\t<MerchantID>7000679</MerchantID>\n\t</Terminal>\n\t<Customer>\n\t\t<IPAddress>192.168.0.1</IPAddress>\n\t\t<EmailAddress>eticaret@garanti.com.tr</EmailAddress>\n\t</Customer>\n\t<Card>\n\t\t<Number>5406697543211173</Number>\n\t\t<ExpireDate>0323</ExpireDate>\n\t\t<CVV2>465</CVV2>\n\t</Card>\n\t<Order>\n\t\t<OrderID>da4009cff27645978084d04c7accaf46</OrderID>\n\t\t<GroupID />\n\t\t<CommentList>\n\t\t\t<Comment>\n\t\t\t\t<Number>1</Number>\n\t\t\t\t<Text> Special description field</Text>\n\t\t\t</Comment>\n\t\t</CommentList>\n\t</Order>\n\t<Transaction>\n\t\t<Type>sales</Type>\n\t\t<Amount>10000</Amount>\n\t\t<CurrencyCode>949</CurrencyCode>\n\t\t<CardholderPresentCode>0</CardholderPresentCode>\n\t\t<MotoInd>N</MotoInd>\n\t</Transaction>\n</GVPSRequest>\n
Within this structure, many tags contain sub-tags within themselves. Under the relevant heading where each tag is described, the usage rules of tags without subtags and the details of tags with subtags are presented in a separate heading.
| Bottom Label | Max Size | Data Writing Format | Description and notes |
|---|---|---|---|
| <Mode> | PROD | This is the field where the process mode is written | |
| <Version> | 16 byte | No format requirement | This is the field where the Api version used is written. Within the scope of hash calculation as Sha512, 512 value must be sent in this field. |
| <Terminal> | This tag contains sub tags. The tags it contains and their rules are given in the following headings. | ||
| <Customer> | This tag contains sub tags. The tags it contains and their rules are given in the following headings. | ||
| <Order> | This tag contains sub tags. The tags it contains and their rules are given in the following headings. | ||
| <Transaction> | This tag contains sub tags. The tags it contains and their rules are given in the following headings. |
<Terminal> Tag and the Tag to be placed under it and its Details
Virtual such as virtual pos number user information to ensure pos verification parameters are sent.
<Terminal>\n\t<ProvUserID></ProvUserID>\n\t<HashData></HashData>\n\t<UserID></UserID>\n\t<ID></ID>\n\t<MerchantID></MerchantID>\n</Terminal>
The sub-tags within this tag and their details are given below:
| Bottom Label | Max Size | Data Writing Format | Description and notes |
|---|---|---|---|
| <ProvUserID> | 32 byte | No format requirement | This is the field where the provision user code of the terminal is sent. Prov user, Cancel refund user or OOS user can be found here |
| <HashData> | 32 byte | Hash algorithm SHA512 format. After hash conversion, lower case letters must be converted to upper case. Details are given below. | This is the field where the user's password verification is performed. Hash creation details are explained separately in this document. |
| <UserID> | No format requirement | This is the field where the user who made the transaction (Agent - Sales Representative) is sent. | |
| <ID> | 9 byte | Nümerik | The field where the terminal number is sent |
| <MerchatID> | 9 byte | Nümerik | This is the field where the workplace number is sent. |
<Customer> Tag and Rules for the <Customer> Tag and Tags Below it
This is the field where Customer Information is sent. It is mandatory to send the information in the tag.
<Customer>\n <IPAddress></IPAddress>\n <EmailAddress></EmailAddress>\n</Customer>
| Bottom Label | Max Size | Data Writing Format | Description and notes |
|---|---|---|---|
| <IPAdress> | 20 byte | No format requirement | This is the field where the IP address of the customer who made the transaction is sent. It must be sent compulsorily in order to ensure fraud controls. |
| <EmailAddress> | 64 byte | This is the field where the E-Mail address of the customer who made the transaction is sent. |
<Card> Label and Rules for the <Card> Label and the Label to be placed under it
This is the field where card information is sent. Credit card information is a mandatory field except for some transaction types.
Note: Unlike other credit cards, American Express cards consist of 15 digit numbers instead of 16, so your card information entry screens must be arranged to accept 15 digits. Unlike other credit cards, the CVV, i.e. security codes of American Express cards have 4 digits instead of 3 and are located on the front of the card. Your security code entry screens must be configured to accept 4-digit codes.
<Card>\n\t<Number></Number>\n\t<ExpireDate></ExpireDate>\n\t<CVV2></CVV2>\n</Card>
| Bottom Label | Max Size | Data Writing Format | Data Writing Format Description and notes |
|---|---|---|---|
| <Number> | Min: 15 - Max : 19 | Nümeric | This is the field where the card number is sent. |
| <ExpireDate> | 4 byte | MMYY (Last 2 digits of Month and Year) | This is the field where the expiration date of the card is sent. |
| <CVV2> | Min : 3 Max : 4 (Amex) | Nümeric | This is the field where CVV information of the card is sent. |
<Order> Label and Rules for the <Order> Label
This is the field where the information and details of the order are sent.
<Order>\n\t\t<OrderID>da4009cff27645978084d04c7accaf46</OrderID>\n\t\t<GroupID />\n\t\t<CommentList>\n\t\t\t<Comment>\n\t\t\t\t<Number>1</Number>\n\t\t\t\t<Text>Special description field</Text>\n\t\t\t</Comment>\n\t\t</CommentList>\n\t</Order>\n
| Bottom Label | Max Size | Data Writing Format | Description and notes |
|---|---|---|---|
| <OrderID> | 36 byte | No format requirement | This is the field where the Order Number is sent. Order based must be unique. It must be produced by companies. |
| <GroupID> | 36 byte | No format requirement | This field is used to categorize (group) orders. For example: Orders sent with campaigns can be separated with an information written to GroupID. |
| <CommentList> | This is the field where the Order Number is sent. Order based must be unique. It must be produced by companies. |
<CommentList> Tag and Details
This is the field where the description information is sent. For example: Policy No.
| Bottom Tag | Description and notes |
|---|---|
| <Comment> | This tag contains sub tags. The tags it contains and their rules are given in the following headings. |
<Comment> Alt Tag and Details
This is the field where the custom field content is sent. Max. 10 different custom information fields can be sent.
***Reminder : In order for comments to be sent. Custom field definitions must be made from the virtualpos screens with the workplace admin user.
| Bottom Tag | Max Size | Data Writing Format | Description and notes |
|---|---|---|---|
| <Number> | 2 byte | Numeric | The number indicating in which private information field the sent private information will be saved. It can be written from 1 to 10. |
| <Text> | 22 byte | Alphanumeric | This is the field where the special information text is entered. |
<Transaction> Tag and its Rules
This is the field where transaction information and financial information are sent.
<Transaction>\n\t<Type></Type>\n\t<Amount></Amount>\n\t<CurrencyCode></CurrencyCode>\n\t<CardholderPresentCode></CardholderPresentCode>\n\t<MotoInd></MotoInd>\n</Transaction>\n
| Bottom Label | Max Size | Data Writing Format | Description and notes |
|---|---|---|---|
| <Type> | 32 byte | Alphanumeric | This is the field where the Transaction Type is sent. Details about transaction types will be given separately in the document. Attention should be paid to the use of other fields according to the transaction type. |
| <Amount> | 17,2 number | The numeric is sent as LLLLLLKK. The last 2 digits represent cents. 1,00 TL -> 100 11,22 TL->1122 0,01TL -> 1 | This is the field where the amount information is entered. If the transaction is a "Partial Refund" transaction, the amount entered in this field is refunded. |
| <CurrencyCode> | 3 byte | Numeric | This is the field where exchange rate information is sent. 949 -> TL will be informed for other exchange rates according to your authorization. |
| <CardholderPresentCode> | 2 byte | Numeric | Enter 0 for normal transactions and 13 for 3D transactions. |
| <MotoInd> | 1 byte | Alphanumeric | It takes Y and N values. N is sent for Ecommerce transactions. Y is sent for transactions with Moto transaction status. |
| <InstallmentCnt> | 2 byte | Numeric | Enter the number of installments. |
Response Structure
The response structure returned from the service after the request sent in the previous headings for the Virtual POS non 3Ds Private Area Submission process is specified in the table below. The information and explanations required for each tag under the main tag in the first column in the table should be examined and the request message should be provided according to the rules specified in this table:
The response structure in the Virtual POS custom field submission process is generally as follows:
<GVPSResponse>\n\t<Mode></Mode>\n\t<Terminal>\n\t\t<ProvUserID>PROVAUT</ProvUserID>\n\t\t<UserID>PROVAUT</UserID>\n\t\t<ID>30691297</ID>\n\t\t<MerchantID>7000679</MerchantID>\n\t</Terminal>\n\t<Customer>\n\t\t<IPAddress>192.168.0.1</IPAddress>\n\t\t<EmailAddress>eticaret@garanti.com.tr</EmailAddress>\n\t</Customer>\n\t<Order>\n\t\t<OrderID>da4009cff27645978084d04c7accaf46</OrderID>\n\t\t<GroupID></GroupID>\n\t\t<CommentList>\n\t\t\t<Comment>\n\t\t\t\t<Number>1</Number>\n\t\t\t\t<Text>Özel açıklama alanı</Text>\n\t\t\t</Comment>\n\t\t</CommentList>\n\t</Order>\n\t<Transaction>\n\t\t<Response>\n\t\t\t<Source>HOST</Source>\n\t\t\t<Code>00</Code>\n\t\t\t<ReasonCode>00</ReasonCode>\n\t\t\t<Message>Approved</Message>\n\t\t\t<ErrorMsg></ErrorMsg>\n\t\t\t<SysErrMsg></SysErrMsg>\n\t\t</Response>\n\t\t<RetrefNum>210707283439</RetrefNum>\n\t\t<AuthCode>101786</AuthCode>\n\t\t<BatchNum>004568</BatchNum>\n\t\t<SequenceNum>005662</SequenceNum>\n\t\t<ProvDate>20220417 20:18:55</ProvDate>\n\t\t<CardNumberMasked>540669****1173</CardNumberMasked>\n\t\t<CardHolderName>4517*** 4517****</CardHolderName>\n\t\t<CardType>BONUS</CardType>\n\t\t<HashData>F61A96E0E8E154C3D51BB4695644A9410E828EDB2B4285CBBDBDABB952E70375E759E4D84B372CDDF14C952593F64CEB51CB9E005E75C1F99A2CCB7782BF71B6</HashData>\n\t\t<HostMsgList></HostMsgList>\n\t\t<RewardInqResult>\n\t\t\t<RewardList></RewardList>\n\t\t\t<ChequeList></ChequeList>\n\t\t</RewardInqResult>\n\t\t<GarantiCardInd>Y</GarantiCardInd>\n\t</Transaction>\n</GVPSResponse>\n
The tags in the answer structure given above and the sub tags under these tags are given in the heading below:
| Bottom Label | Data Writing Format | Description and notes |
|---|---|---|
| <Mode> | PROD - TEST | This is the field where the process mode is written |
| <Customer> | This is the field where the customer information sent in the request structure is sent back for verification purposes. | |
| <Order> | This tag contains sub tags within itself. The sub tags it contains are given in the headings below. | |
| <Transaction> | This tag contains sub tags within itself. The sub tags it contains are given in the headings below. |
<Response> Subtags and Descriptions
| Bottom Tags | Description and notes |
|---|---|
| <Source> | This is the field where the source information is returned. |
| <Code> | This is the field where Approved - declined information is returned. |
| <ReasonCode> | The field where the response code is returned. |
| <Message> | Field where message information is returned. |
| <ErrorMsg> | The field where the error message is returned. |
| <SysErrMsg> | This is the field where the system error message is returned. |
<RewardInqResult> Tag, Subtags and Descriptions
| Bottom Tags | Data Writing Format | Description and notes |
|---|---|---|
| <RewardList> | This tag contains sub tags. Details about the sub-tags are given in the headings below. | |
| <ChequeList> | This tag contains sub tags. Details about the sub-tags are given in the headings below. |
<RewardList> Tag and Descriptions
| Bottom Tags | Data Writing Format | Description and notes |
|---|---|---|
| <Reward> | This tag contains sub tags. Details about the sub-tags are given in the headings below. |
<Reward> Tag and Descriptions
| Bottom Label | Data Writing Format | Description and notes |
|---|---|---|
| <Type> | Alphanumeric | This is the field where the reward type is returned. The values that can come in this field and their meanings are as follows:BNS: Bonus PointsFBB: Company Based Bonus Points |
| <TotalAmount> | The numeric is sent as LLLLLLKK. The last 2 digits represent cents. 1,00 TL -> 100 11,22 TL->1122 0,01TL -> 1 | This is the field where the award amount is returned. |
| <LastTxnGainAmount> | The numeric is sent as LLLLLLKK. The last 2 digits represent cents. 1,00 TL -> 100 11,22 TL->1122 0,01TL -> 1 | This is the field where the last won prize amount is returned. |
<ChequeList> Tag and Explanations
| Bottom Tags | Data Writing Format | Description and notes |
|---|---|---|
| <Cheque> | This tag contains sub tags. Details about the sub-tags are given in the headings below. |
<Cheque>Tag and Descriptions
| Bottom Tags | Data Writing Format | Description and notes |
|---|---|---|
| <Type> | Alfanümerik | The field where the check type is returned. |
| <Count> | The field where the number of checks is returned. | |
| <ExpireDate> | Check expiration date is returned. | |
| <Amount> | The numeric is sent as LLLLLLKK. The last 2 digits represent cents. 1,00 TL -> 100 11,22 TL->1122 0,01TL -> 1 | Check amount is returned. |
| <UsageRate> | Check utilization rate is returned. | |
| <MinTxnAmount> | Nümerik LLLLKK şeklinde yollanır. Son 2 hane kuruşu ifade eder. 1,00 TL -> 100 11,22 TL->1122 0,01TL -> 1 şeklinde | It is the field where the minimum transaction amount required for check usage is returned. |
| <ID> | It is the field where the Campaign ID information is returned. | |
| <Bitmap> | It is the field where the Bitmap ID produced by the bank is returned. |
Code Examples
Below are the github repo links for custom code examples written in different programming languages, including this transaction type. You can examine the codes written with predefined values through the link of your preferred programming language.
- C# For Code Examples click here.
- VB.Net For Code Examples click here.
- For Java Code Examples click here.
- For PHP Code Examples click here.
Error Codes
Error codes from this page you can reach.
Test Cards
List of test cards from this page you can reach.
