Payment can be made in 3D via TAMİ. 3D payment process consists of 2 steps. Firstly, 3D sales transaction is initiated, and as a result of this process, the service returns html content information which is decoded from base64 to obtain an html. This html is then directed to the 3D verification page, where the verification code is entered to complete the 3D verification and see the result. To convert a successful 3D verification process into a sale, the 3D Complete service must be called to complete the transaction.
Test/Prod Envirenement API User Information
You can access the Sandbox Test Portal at https://sandbox-portal.tami.com.tr. When you log in to the test portal using a
test user account, you can view the transactions performed by the merchant
associated with that user. These transactions can also be cancelled or
refunded. To obtain the test user credentials,
please contact TeknikDestek@tami.com.tr.
Hash Calculation
The request sent for many transaction types should include the PG-Auth-Token in the header information. The PG-Auth-Token consists of the values "MerchantNumber:TerminalNumber:Hash".
When calculating the hash here, the merchantNumber, terminalNumber, and secretKey information belonging to the merchant are hashed with sha256 and converted to a string.
public class SHA256Example {\n public static String sha256(Long merchantNumber, Long terminalNumber, String secretKey) {\n String text = merchantNumber.toString() + terminalNumber.toString() + secretKey;\n try {\n MessageDigest digest = MessageDigest.getInstance(\"SHA-256\");\n byte[] hash = digest.digest(text.getBytes(StandardCharsets.UTF_8));\n String sha256Hex = DatatypeConverter.printBase64Binary(hash);\n return sha256Hex;\n } catch (NoSuchAlgorithmException e) {\n e.printStackTrace();\n return null;\n }\n }\n}
TAMİ Test Portal Information
You can access the Tami test portal at https://sandbox-portal.tami.com.tr. From this address, you can view the portal screen with the users specified above.
For your production environment information you can become a member at https://portal.tami.com.tr or You can apply to the e-commerce support unit.
Starting the 3D Sales Transaction
The first step of a 3D secure sales transaction. The 3D secure sales transaction is initiated by adding the member merchant's callbackUrl address as shown in the example request format below. At the end of the process, the member merchant receives html content information. This content is decoded in base64 to obtain an html. The obtained html is redirected to the 3D authentication page, where the authentication code is entered and the result of the 3D authentication is seen.
3D Sale Initiation API Information
In test environment, the "https://sandbox-paymentapi.tami.com.tr/payment/auth" URL will be used.
In production environment, the "https://paymentapi.tami.com.tr/payment/auth" URL will be used.
Request Parameters and Descriptions
The request structure required for 3D Secure Virtual POS transactions (lump-sum or installment) is specified in the table below. The information and explanations in the request message should be reviewed, and the request message must be prepared in accordance with the rules outlined in this table.
Field
Format
Maximum Size
(O)ptional/(C)onditional/(M)andatory
Description
orderId
String
(2-36)
M
The payment request is a singular communication information used in the interaction between Tami-customer. For the merchant and POS pair, this value must be singular.
amount
Decimal
M
The amount is the transaction. The fractional separator must be a period (.).
currency
String
3
M
Specifies the currency code of the transaction. Example: TRY should be sent for TL.
installmentCount
Number
M
This is the installment information of the desired transaction. For cash transactions, 1 must be sent. Sending 0 is not accepted.
paymentGroup
String
M
Payment group, default PRODUCT should be forwarded
paymentChannel
enum
O
Payment channel. Valid values are provided in the enum: WEB, MOBILE, MOBILE_WEB, MOBILE_IOS, MOBILE_ANDROID, MOBILE_WINDOWS, MOBILE_TABLET, MOBILE_PHONE
callbackUrl
String
C
If a transaction is desired to be carried out in 3D, it must be sent. The address to which the 3D verification result will be returned is the address associated with the merchant.
card
Object
M
cvv
String
M
The security code of the card from which the payment will be taken.
expireMonth
Number
(1-12)
M
Expiration date and month of the card from which the payment will be taken.
expireYear
Number
4
M
The expiration date and year of the card from which the payment will be taken.
holderName
String
30
M
Name and surname of the cardholder from whom the payment will be received.
number
String
(5-35)
M
The card number from which the payment will be received.
billingAddress
Object
O
address
String
400
O
Billing address information on the merchant side.
emailAddress
String
O
E-mail information of the merchant
city
String
30
O
Billing address city information on the merchant side.
companyName
String
100
O
Trade name information of the merchant.
country
String
50
O
Country of the billing address on the merchant side.
contactName
String
30
O
Billing address, name and surname information on the merchant side.
phone
String
O
GSM number of the buyer on the merchant side.
zipCode
String
15
O
Postal code of the billing address on the merchant side.
district
String
50
O
Neighborhood information of the billing address on the merchant side.
shippingAddress
Object
O
address
String
400
O
Delivery address information on the merchant side.
emailAddress
String
O
E-mail information of the merchant
city
String
30
O
Delivery address city information on the merchant side.
country
String
50
O
Delivery address country information on the merchant side.
contactName
String
30
O
Delivery address, name and surname information on the merchant side.
zipCode
String
15
O
Postal code information of the delivery address on the merchant side.
district
String
50
O
Delivery address neighborhood information on the merchant side.
buyer
Object
M
Contains information about the buyer on the merchant side
ipAddress
String
M
It is the IP address of the buyer on the merchant side. The real IP address of the recipient must be transmitted.
buyerId
String
50
M
The buyer's id on the merchant side.
name
String
30
M
Name of the buyer on the merchant side.
surName
String
30
M
Last name of the buyer on the merchant side. Buyer object is an optional field, but if any field from the buyer object is sent, surname is required.
identityNumber
String
11
O
Identification number of the buyer on the merchant side.
city
String
50
O
City information of the recipient on the merchant side.
country
String
50
O
Country information of the buyer on the merchant side.
emailAddress
String
M
The e-mail information of the recipient on the merchant side. The e-mail address must be a valid and accessible address of the recipient.
phoneNumber
String
M
The GSM number of the buyer on the merchant side.
registrationAddress
String
400
O
Recipient's registration address on the merchant side.
zipCode
String
15
O
Postal code of the recipient on the merchant side.
registrationDate
Date
O
Recording date of the buyer on the merchant side. The date format should be 2015-09-17 23:45:06.
lastLoginDate
Date
O
Last receipt date for the merchant-side buyer. The date format should be 2015-09-17 23:45:06.
basket
O
basketId
String
50
C
The id of the basket on the merchant side. If an item is sent in the basket, it is mandatory to send basketId.
basket/basketItems
List
0
itemId
String
50
C
The id of the product in the basket on the merchant side. If the item is transmitted in the basket, it is mandatory to send itemId.
itemType
String
50
C
The type of the product in the cart at the merchant. Valid enum values: PHYSICAL and VIRTUAL. If an item is sent in the basket, the itemType must be sent.
name
String
50
C
The name of the product in the basket on the merchant side. If the item is sent in the basket, it is mandatory to send the name.
category
String
50
O
The category of the product in the cart on the merchant side.
subCategory
String
100
O
Subcategory of the product in the cart on the merchant side.
unitPrice
Decimal
min 0.0
O
The single amount of the product in the basket on the merchant side.
totalPrice
Decimal
min 0.0
C
The total amount of the product in the basket on the merchant side. It cannot be 0 and less than 0, the sum of the amounts must be equal to the basket amount. If an item is sent in the basket, totalPrice must be sent. Unitprice * numberOfProducts = totalPrice
numberOfProducts
Number
1-99999
O
The number of products in the basket on the merchant side.
securityHash
String
M
It is the value expected to be calculated and transmitted according in the document. If it is missing or incorrect, the transaction is not routed to the bank, an error is given.
The card issuer's 3D verification screen will be displayed using the HTML data obtained after initiating the 3D pre-authorization. Once the cardholder enters the password received on their mobile phone, the verification result will be transmitted to the address specified in the `callbackUrl` parameter. Tami will POST the following values to this address.
Funds are not yet deducted from the card when the 3D verification is successful. If the `success` field in the response is `true`, you may proceed to the next step—completing the 3D sale transaction—to finalize the payment.
When the 3D verification response is transmitted to the merchant's callback address, Tami includes a `hashedData` parameter in the response to ensure transaction security. Merchants must verify this value by recalculating it on their end using the method specified in the relevant documentation.
If the value calculated by the merchant matches the `hashedData` value transmitted by Tami, the transaction is deemed secure, and the process should proceed to the 3D completion step. Implementing this verification process and confirming the security of the transaction is entirely the merchant's responsibility.
3D Verification Response Parameters and Descriptions
Parametre Adı
Format
Açıklama
cardBrand
String
Card Brand
cardOrganization
String
Card Organization
cardType
String
Card Type
currencyCode
String
Transaction Currency
hashedData
String
Value to be used to check the accuracy of the information returned in the answer
installmentCount
Number
Number of Transaction Installments
maskedNumber
Number
Card number as masked
mdStatus
String
It is the mdStatus value returned for informational purposes. It can return 1 for successful cases and 0, 2, 3, 4, 4, 5, 5, 6, 7, 8 for unsuccessful cases.
orderId
String
Order number
success
String
Reports the result of the 3d verification process. Returns true if the operation is successful, false if the operation is failed
systemTime
DateTime
Transaction date
txnAmount
Number
Transaction amount
hashParams
String
Information regarding the parameters used to generate the Hashed Data value is transmitted in the specified order. The calculation of the Hashed Data value must be performed based on this field.
In case the Success field returned in the 3D Validation response is false, the table below will help with the cause of the error.
mdStatus
Format
mdStatus = 0
3D Secure signature or verification invalid
mdStatus = 2
Cardholder or bank not registered in the system
mdStatus = 3
The bank of the card is not registered in the system
mdStatus = 4
Verification attempt, cardholder chose to register later in the system
mdStatus = 5
Unable to verify
mdStatus = 6
3D Secure error
mdStatus = 7
System error
mdStatus = 8
Unknown card no
HashedData Calculation
To verify that the information returned in the 3D Verification response originates from a legitimate source, you can calculate the `hashedData` based on the fields listed below and compare it with the corresponding information in the response.
When calculating the `hashedData` provided in Tami’s 3D Verification response, a data string (`hashItems`) is created by concatenating the fields specified in the `hashParams` field of the verification response in the given order. The merchant's `secretKey` is appended to the end of this string, and the result is hashed using SHA-512. Finally, it is Base64 encoded to produce the encrypted `hashedData`. Sample code is provided below.
By always calculating `hashedData` based on the fields specified in the `hashParams` field of the 3D Verification response, merchants will not need to make additional integration changes if fields are added to or removed from this list in the future.
NOTE: For upfront (non-installment) transactions, the `InstallmentCount` is expected to be sent as 1. This value is also included in the `hashedData` calculation.
When generating the `hashedData`:
Step 1) The values within the `hashParams` data returned in the 3D Verification response are split to obtain the `hashItems`.
Example `hashParams` value in the verification response:
Step 2) Using the data generated with the required information (Step 1), the merchant's `secretKey` is hashed using SHA-512. This hashed data is then Base64-encoded to obtain the "HashedData"..
It is used for Tami merchants to complete transactions that have been successfully 3d verified. By calling this service, the card is not charged for transactions that are not completed in 3d.
3D Transaction Completion API Information
In test environment, the "https://sandbox-paymentapi.tami.com.tr/payment/complete-3ds" URL will be used.
In production environment, the "https://paymentapi.tami.com.tr/payment/complete-3ds" URL will be used.
3D Sales Completion Request Parameters and Descriptions
Field
Format
Max Size
(O)psiyonel
/ (M)andatory
Description
orderId
String
(2-36)
M
Order number information with successful completion of 3d verification
securityHash
String
M
It is the value expected to be calculated and transmitted according to the fields specified in the document. If it is missing or incorrect, the transaction is not routed to the bank, an error is given.
In the header section, correlationId and PG-Auth-Token parameters are expected to be transmitted. correlationId must be transmitted as a string unique value for each transaction. PG-Auth-Token parameter consists of merchantNumber, terminalNumber and hash information of the merchant as stated in the table. For hash information, merchantNumber, terminalNumber and secretKey information of the merchant is obtained by hashing with sha256 and converting it to string.
"PG-Auth-Token" parameter should be passed in the header in all sales, cancellation/refund, pre-authorization, pre-authorization closure, 3D sales and 3D sales completion requests.
This information consists of "merchantNumber:TerminalNumber:Hash" information of the merchant. The hash information is expected to be calculated according to the requested values and added to the PG-Auth-Token parameter.
"PG-Auth-Token" parameter should be passed in the header in all sales, cancellation/refund, pre-authorization, pre-authorization closure, 3D sales and 3D sales completion requests.
This information consists of "merchantNumber:TerminalNumber:Hash" information of the merchant. The hash information is expected to be calculated according to the requested values and added to the PG-Auth-Token parameter.