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.

Request Structure

The request structure required for Virtual POS non 3Ds address addition 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:

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.

<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.

The sub-tags within this tag and their details are given below:

<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.

<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.

<Order> Label and Rules for the <Order> Label

This is the field where the information and details of the order are sent. 

<AddressList> Tag and Details

This is the field where address information is sent. Two different addresses, delivery address and billing address, can be sent once.

<Address> Tag and Details

Used for sending invoice and delivery address details.

<Transaction> Tag and its Rules

This is the field where transaction information and financial information are sent.

Cevap (Response) Yapısı  

Sanal POS 3D’siz Adres Ekleme işlemi için, önceki başlıklarda gönderilen istek sonrası, servisten dönen cevap (response) yapısı aşağıdaki tabloda belirtilmiştir. Tablo içerisinde ilk kolonda yer alan ana tag altında yer alanabilecek her tag için gerekli olan bilgi ve açıklamalar incelenmeli ve istek mesajı bu tabloda belirtilen kurallara göre sağlanmalıdır: 

Sanal POS adres ekleme işleminde cevap yapısı genel biçimde aşağıdaki şekildedir: 

Yukarıda verilen cevap yapısı içerisinde yer alan etiketler ve bu etiketlerin altında yer alan alt etiketler aşağıdaki başlıkta verilmiştir: 

<Transaction> Tag Label and Rules of the <Transaction> Tag

<Response> Subtags and Descriptions

<RewardInqResult> Tag, Subtags and Descriptions

<RewardList> Tag and Descriptions

<Reward> Tag and Descriptions

<ChequeList> Tag and Explanations

<Cheque>Tag and Descriptions

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.