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:
This document describes the steps required for member merchants to be able to perform non 3Ds Inquiry 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.
The sub-transaction types under the Virtual POS Inquiry transactions are generally as follows:
Garanti Sanal POS, internet üzerinden yapılan satışlarda kredi kartı ile ödeme alınabilmesi için oluşturulan güvenli bir ödeme çözümüdür.
Üye işyerleri, mağazalarında internet üzerinde bir şube açıp, Garanti Sanal POS ile, onu hiç kapanmayan bir satış platformu haline gelebilir. Böylece hem müşteri sayıları, hem de cironun artırılmasına katkı sağlanır.
Garanti Sanal POS altında genel olarak aşağıdaki işlemler gerçekleştirilmektedir:
Bu doküman içerisinde, üye işyerlerinin Garanti Sanal POS altında 3D’li Peşin Satış işlemlerinin sağlanabilmesi için gerekli olan adımlar, her bir adım içerisinde yapılması gereken işlemler ve gönderilen işlem istekleri ve alınan cevap mesajlarının yapıları anlatılmaktadır.
İptal, yapılan bir işlemin gün içerisinde geçersiz olması için yapılan işlemdir.
İşlemler aynı gün içerisinde iptal edilebilir. Takip eden günler için işlemin iptal edilmesi gerekiyorsa yapılması gereken işlem iadedir.
İptal işleminin iptali yoktur. Bu sebeple yanlışlıkla bir iptal yapılırsa bu durumda ipal edilen işlemin tekrar yaptırılması gerekmektedir.
İptal işlemleri kart üzerinden iz oluşturmaz. Kart ekstrelerinde ya da dönemi içi işlemlerde gözükmez.
3D Secure , PoS üzerinde kart sahiplerinin şifre ile doğrulandığı uygulamanın, SanalPoS üzerinde yapılan halidir. Kart sahibi, işlemde şifre kullanması için kart bankasına ait doğrulama ekranlarına yönlendirilir. Kart sahibi bu ekranlar üzerinden bankasının istediği bilgileri girerek, gerçekten kullanılan kartın kendisine ait bir kart olduğunu gösterir.
Doğrulama sonucunda, doğrulama durumu işyeri bankaya (işyerine) döndürülür. Daha sonra 3D bilgilerinin durumuna göre provizyon işleminin gerçekleştirilmesi ya da işlemin sonlandırılması gerçekleştirilir.
3D Secure Master, Visa ve American Express(Amex) kartların desteklediği bir uygulamadır. 3D model (aşağıda işyeri modelleri hakkında bilgi verilmektedir) kullanan işyerlerinin Mastercard, Visa ve Amex dışındaki kartlar için 3D doğrulaması gerçekleştirmeden direk provizyona gelmeleri gerekmektedir. 3D secure desteklenmediği için bu tür işlemlerde Fraud sorumluluğu işyerine aittir. İşyeri kendisini koruyacak önlemleri almalıdır.
Gerçekleşen işlemin provizyon akışı sırasında herhangi bir 3D secure aşamasına değmeden sonuçlanmasıdır. Bu işlem tipinde müşterinin “ben yapmadım” itirazları chargeback talebine dönüşür. İşyerinden işlemin müşteri tarafından yapıldığına yönelik kanıtlar talep edilerek chargeback süreci değerlendirilir. 3D’li işlemlerde başarılı doğrulaması yapılan işlemlerde işlemi “ben yapmadım” talepleri banka tarafında sonlandırılır.
Sanal POS Satış işlemleri için, üye işyeri tarafından 2 farklı yöntem ile ilerlenmesi mümkündür. Üye işyeri dilerse yapacağı tüm geliştirmeleri Test ortamında yapabilir. Alternatif olarak doğrudan yayın ortamında da bu işlemler için gerekli geliştirmeler yapılabilir.
Üye işyeri tarafından seçilecek yönteme göre, Sanal POS satış işlemlerine başlamadan önce aşağıdaki başlıklardan uygun olana göre ilk işlemlerin yapılması gerekmektedir:
Yapılacak çalışmaların test ortamında yürütülmesi durumunda, aşağıda belirtilen ön tanımlı değerler oldugu gibi kullanılabilir:
Parametre | Değer |
---|---|
MerchantID | 7000679 |
ProvUserID | PROVAUT / PROVRFN / PROVOOS |
ProvisionPassword | 123qweASD/ |
TerminalID | 30691297 |
StoreKey | 12345678 |
Test ortamında yapılacak çalışmalarda "https://sanalposprovtest.garanti.com.tr/VPServlet" url'i kullanılacaktır.
Test ortamında yapılan işlemlerin takip edilebileceği ve görüntülenebileceği panele bu adresten erişebilirsiniz.
Değişken | Değer |
---|---|
Kullanıcı Adı | 99999999999 |
Parola | Destek.3 |
Şifre | 147852 |
Not: Parola işlemlerinde hata alınması durumunda 2.kez deneme yapılmadan önce lütfen Bize Soru Gönderin formu ile bilgi veriniz.
Test ortamında kullanılabilecek tüm test kartlarının listesine bu sayfadan ulaşabilirsiniz.
Bu yöntem ile ilerlendiğinde, üye işyeri tarafından ilk adım olarak kurulumda kullanılacak olan şifreler (“PROVAUT”,“PROVOOS”, “PROVRFN” ve “3D” (storekey) şifreleri) Sanal POS İlk Adımlar dokümanı içerisinde belirtildiği şekilde sanal pos yönetim panelinden oluşturmalıdır.
Sonraki adımlarda, bu şekilde oluşturulan şifre ve hesaplar kullanılacaktır.
PROD ortamında yapılacak çalışmalarda "https://sanalposprov.garanti.com.tr/VPServlet" url'i kullanılacaktır.
Bu doküman içerisinde, birçok işlem tipi altında kullanılan ve istek mesajı içerisinde <HashData> şeklinde yer alan etiket için gerekli olan verinin nasıl oluşturulacağını adım adım anlatılmaktadır.
İstek mesajları içerisinde yer alan <HashData> etiketi; kullanıcıya ait şifre doğrulamasının yapılmasını sağlayan alandır. Hash oluşturma detayları aşağıda ayrıca anlatılmaktadır.
Yeni SanalPoS uygulamasında, terminale ait şifrenin açık şekilde dolaşmasının engellenmesi için HASH yapısı kullanılmaktadır.
Hash hesabı:
Hash hesaplamasında, İki parçalı HASH yapısı kullanılmaktadır. İlk aşamada provizyon şifresinin, terminal numarası ile yanyana getirilmesi ile SHA1 algoritması kullanılarak hashedpassword değerinin elde edilmesi sağlanacaktır.
Hash oluşturmak için gerekli olan işlemler, aşağıda farklı programlama dilleri için sunulmuştur:
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:
The request structure required for Virtual POS Bonus Inquiry transactions 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.
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. |
<ChannelCode> | 1 byte | Alphanumeric | Channel information will be sent. It must be empty. |
<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. | ||
<Card> | 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. |
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:
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. |
This is the field where Customer Information is sent. It is mandatory to send the information in the tag.
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.
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. |
This is the field where the information and details of the order are sent.
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 generated by companies |
<GroupID> | 36 byte | No format requirement | It is the field used to categorize (group) orders. For example: Orders sent with campaigns can be separated with an information written in GroupID. |
This is the field where transaction information and financial information are sent.
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. |
For Virtual POS Bonus Inquiry transactions, the response structure returned from the service after the request sent in the previous headings is generally 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:
In the Virtual POS cash sales transaction, the response structure is generally as follows:
The tags in the answer structure given above and the sub tags under these tags are given in the heading below:
Bottom Labels | Data Writing Format | Description and notes |
---|---|---|
<Mode> | PROD - TEST | This is the field where the process mode is written |
<Terminal> | This tag contains sub tags within itself. The sub tags it contains are given in the headings below. | |
<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. |
It is the field where the parameters sent in the request, such as virtual pos number user information, are returned in the response in the same way in order to provide virtual pos verification.
Bu etiket içerisinde yer alan alt etiketler ve detayları aşağıda verilmiştir:
Bottom Label | Maks 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 |
<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. |
This is the field where the customer information sent in the request is returned in the same way in the response.
Bottom Label | Maks 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. |
This is the field where the order information sent in the request is returned in the same way in the response.
Bottom Label | Data Writing Format | Description and notes |
---|---|---|
<OrderID> | Alfanümerik | This is the field where the order number is returned. |
<GroupID> | Alfanümerik | The field where the GroupID number is returned. This tag contains sub tags. Details about the sub tags are given in the headings below. |
Bottom Tags | Data Writing Format | Description and notes |
---|---|---|
<Response> | This tag contains sub tags. Details about the sub-tags are given in the headings below. | |
<RetrefNum> | Nümerik | The transaction number generated by Virtualpos is returned |
<AuthCode> | Nümerik | This is the field where the confirmation code is returned. |
<BatchNum> | This is the field that returns which batche the transactions will enter. | |
<SequenceNum> | This is the field where the name of the cardholder is sent. | |
<ProvDate> | YYYYMMDD | This is the field where the provision date is returned. |
<CardNumberMasked> | This is the field where the first 6 and last 4 digits of the card number and the fields in between are returned with *. | |
<CardHolderName> | This is the field where the name of the cardholder is sent. | |
<CardType> | This is the field where the type of card processed is returned. | |
<HashData> | This is the field where the HashData information of the transaction is returned. | |
<HostMsgList> | This tag contains sub tags. Details about the sub-tags are given in the headings below. | |
<RewardInqResult> | This tag contains sub tags. Details about the sub-tags are given in the headings below. | |
<GarantiCardInd> | ||
<CampaignChooseLink> |
Alt 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> | This is the field where the answer code is returned. |
<Message> | This is the field where the message information is returned. |
<ErrorMsg> | This is the field where the error message is returned. |
<SysErrMsg> | This is the field where the system error message is returned. |
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. |
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. |
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. |
Bottom Labels | Data Writing Format | Description and notes |
---|---|---|
<Reward> | This tag contains sub tags. Details about the sub-tags are given in the headings below. |
Bottom Labels | Data Writing Format | Description and notes |
---|---|---|
<Type> | ||
<MilAmount> | ||
<MilValue> | ||
<UseRate> |
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. |
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. |
Below are github repo links to virtual POS Advance Sales transaction examples written in different software languages. You can review the codes written with predefined values via the link of your preferred programming language.
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.
Error codes from this page you can reach.
List of test cards from this page you can reach.
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