Introduction Intended Audience This overview document is written for technical people with a background in payments services; and implementing online payment functionality to the e-commerce sites and/or internal. ERP systems using Paratika. How to Contact Customer Support For problems with transaction processing or your connection to the server, please contact Customer Support via phone 02123190625 or destek@paratika.com.tr email. Phone number: 02123190625 e-Mail: destek@paratika.com.tr What is Paratika? Paratika is an online payment solution developed by Payten Turkey. It offers a secure, easy and convenient checkout experience for both, customers and merchants. While Customers (Card Holders) enjoy the secure e-wallet and flexible payment features on check out pages; the Merchants are handling the payment without touching the credit card data so they remain PCI DSS compliant; and therefore eliminate the risks around fraud & secure storage of financially sensitive data. Security Standards More about PCI DSS Data Security Standards Security Paratika is built on a robust and secure communication protocol. Paratika API is a set of instructions submitted with standard HTTPS Post requests. At the server end, we use a certificate delivered by Verisign. The SSL encryption guarantees that it is our servers you are communicating with and that your data is transmitted in encrypted form. There is no need for a client SSL certificate. When we receive a request, we check the level of encryption. Directly TLSv1.1 version and next version is supported. Supported Languages The API supports all platforms & languages that can implement HTTP Post methods. Response Parsing Paratika responses by default will be in form of JSON format. You can use any JSON parsing tool or framework to process Paratika responses. Test Environment An API test environment is available and all API action types given in this document can be tested using by Paratika API Test URL. All API requests should be sent to this URL address using HTTP POST method. Paratika API Test URL test/paratika/api/v2 Integration Environment An API integration environment is available and all API action types given in this document can be tested using by Paratika API Test URL. All API requests should be sent to this URL address using HTTP POST method. Paratika API Integration URL integration/paratika/api/v2
Request & Response Paratika API Requests A request to the Paratika API is made a by sending a POST HTTP request to Paratika API Endpoint URL. Each HTTP POST request send to the API URI should have a set of parameter-value pairs encoded in it, depending of the type of request being sent. Paratika API Responses The Paratika API response supports JSON data format. Each response, regardless of the success of the action, will return the RESPONSECODE and RESPONSEMSG parameters. Depending on the successfulness of the action the RESPONSECODE and RESPONSEMSG can have the specific value pairs. If an error has occurred and the API call is considered to be failed (RESPONSE is not equal to 00) the ERROR and ERRORCODE parameters will be present in the response. Possible values for RESPONSECODE and RESPONSEMESSAGE Response Code Response Message Description 00 Approved Action done successfully 98 General error Action failed due to general error. A general error can be a runtime error during action processing or a payment gateway error that is not yet mapped in our error set. 99 Declined Action failed due to invalid parameters or payment gateway error. Pagination TO BE PROVIDED TO BE PROVIDED
Authentication You authenticate to the API by providing your user information (secure credentials) in the request. You can manage your API user information from your account or by requesting related change from support team. Every API user have its own e-mail and password information. Your user e-mail and password pair carries many privileges, so be sure to keep them secret! All API requests must be made over HTTPS. Calls made over plain HTTP will fail. You must authenticate properly for all requests. API Request Authentication Parameters MERCHANTUSER: [MERCHANTUSER] MERCHANTPASSWORD: [MERCHANTPASSWORD] MERCHANT: [MERCHANT]
How to integrate? Hosted Page (HP) This model requires the merchants to use Paratika's payment page hosted in Asseco environment. It is based on one way communication of the ‘transaction result’ to the Merchant system occurring at Step 4. HPP model simply assumes that the Merchant site has received the transmitted information and updated its own records accordingly. It has the following steps: Step 1: The Merchant Web Site makes a sale request by specifying the integration model as HPP. Order/Billing/Shipping details can also be passed at this stage to be displayed on Paratika payment page for Customer’s information only. Step 2: The payment request is processed, a session token is created and sent back to the merchant site. Merchant Web Site receives the token and redirects Customer’s Browser to Paratika Payment Pages with the given session token. Step 3: If there is any saved card detail for the Customer, his/her e-wallet is displayed for quick payment. If not, new card entry screen is displayed. Customer clicks on ‘pay’ button after entering/selecting the card to be used in payment. Paratika processes the payment accordingly. Step 4: Paratika redirects the Customer Browser to Merchant Web Site and also returns the transaction result. Please note that Step 4 is a browser based HTTP re-direction and it all happens in customer's environment in which Asseco has no control over. There might be cases like where the customer may close the browser screen or internet connection may cuts off during this re-direction etc. Therefore merchants using this model should not completely rely on redirection process to obtain information about the payment result. They should use additional api calls to check the status of the payment. These details are available in API Model Integration document. Hosted Page (HP) Flow Direct POST - MOTO This integration model is based on the scenario that the Payment Page is being hosted by Merchants but its form action is Direct Post to Paratika so that any financially sensitive data will be collected still at the convenience of a merchant hosted page but to be fully compatible with PCI DSS. This will overcome the shortage of the API integration model for the merchants willing 100% compliance with PCI DSS without any additional effort on their side. Please see the flow below for details. Step 1: The Merchant Core System makes a Session Token request in order to get a valid key value for defining the session. Step 2: This session token request is processed; a session token is created and sent back to the merchant system in the API response. Step 3: Merchant system serves the payment page using the given secure session token. Extra Point Step: In Direct Post model merchant need to do a query points with SESSIONTOKEN, CARDPAN,CARDEXPIRY parameters. According to QUERYPOINTS response sample form points input should be set as sale by points samples. And to send the payment to related payment system, merchant needs to send payment system name as paymentSystem input parameter at sample form. Payment system name can be get via QUERYPAYMENTSYSTEMS with SESSIONTOKEN and BIN. Step 4: Cardholder interacts with the page and clicks on Confirm button. Merchant system submits all information received via this page to Paratika system. Step 5: Paratika processes the payment details via an invisible interim page. Step 6: Paratika forwards the payment to the relevant VPOS, receives the result and redirect the cardholder back to merchant return url. The merchant is expected to listen and parse the payment result within the posted form. TMX Javascript section in the HTML form below is mandatory. Direct Post (MOTO) Test Form Sample POST Form Pay with Card Token Card Owner Name Card Number (PAN) Expiration Date January February March April May June July August September October November December 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 2031 2032 2033 2034 Security Code (CVV) Save Card Card Name Installment Count >Card Token Installment Count Direct Post MOTO Flow Direct POST Response Parameter Set Paramater Name Get Value Description merchantPaymentId request.getParameter('merchantPaymentId') Get from sessionToken apiMerchantId request.getParameter('apiMerchantId') Get from sessionToken paymentSystem request.getParameter('paymentSystem') Get from card Number PIN paymentSystemType request.getParameter('paymentSystemType') Payment System Type information paymentSystemEftCode request.getParameter('paymentSystemEftCode') Eft code of the payment system pgTranId request.getParameter('pgTranId') Transaction Id which come from bank side pgTranDate request.getParameter('pgTranDate') Transaction date at bank side pgTranRefId request.getParameter('pgTranRefId') Transaction Reference Id which is come from bank side pgTranApprCode request.getParameter('pgTranApprCode') Transaction Approval Code which is come from bank side pgOrderId request.getParameter('pgOrderId') PgOrderId which is the order id at bank side customerId request.getParameter('customerId') customerId which is the customer Id merchant side sessionToken request.getParameter('sessionToken') Return the session token which is created at sessionToken action cardToken request.getParameter('cardToken') Returned if transaction make with card Token random request.getParameter('random') Random value which is used at veriyfing the SD_SHA512 hash value sdSha512 request.getParameter('sdSha512') Used for hash verification secretKey is the private merchant key defined once for each merchant, formula :SHA512 encodeHexString((merchantPaymentId+'|'+customerId+'|'+sessionToken+'|'+responseCode+'|'+randomKey+'|'+secretKey)) SD_SHA512 request.getParameter('SD_SHA512') Deprecated / Legacy - Do not use! Used for hash verification. secretKey is the private merchant key defined once for each merchant, formula :SHA512(sessionToken + merchantPaymentId + responseCode + responseMsg + random + secretKey) pgTranErrorText request.getParameter('pgTranErrorText') Return only in error case; contains bank transaction error message pgTranErrorCode request.getParameter('pgTranErrorCode') Return only in error case; contains bank transaction error code pgTranErrorCode request.getParameter('pgTranErrorCode') Return only in error case; contains bank transaction error code errorCode request.getParameter('errorCode') Return only in error case; contains PF error code errorMsg request.getParameter('errorMsg') Return only in error case; contains PF error message responseCode request.getParameter('responseCode') Response code of the Paratika responseMsg request.getParameter('responseMsg') Response message of the Paratika Sample response for Direct Post Non 3D merchantPaymentId: PaymentId-FbnzDdx04fZu apiMerchantId: 700100000 paymentSystem: My İÅbank VPOS Account (Test) paymentSystemType: ISBANK paymentSystemEftCode: 0064 pgTranDate: 20170113 12:20:35 pgTranId: 17013MUjC07014059 pgTranRefId: 701300002882 pgTranApprCode: 733185 pgOrderId: PaymentId-FbnzDdx04fZu sessionToken: FOEMQGVTVWOQCJRSS6DARRRV62RQK2FIKUY7ZMXKBNX6SOUJ random: -349886350 customerId: Customer-QjOnxH8Z SD_SHA512: bff497614a8767e3176fede4f3f8274225a8f619469a1c5eafe2e785fbc438aeb5345c51be30d976d53db5b73adf026347db1144c52cbc2133364aa13e933d45 sdSha512: 7f1485a24f1790e0791fe9de5ec33d4e98057578f77a4c39fdd4bd874079d6e3af9271da020c57ed8acd7642ec801ad80dae0c574462a58a6722fbfa361a0b65 responseCode: 00 responseMsg: Approved Direct POST - 3D Secure This integration model is based on the scenario that the Payment Page is being hosted by Merchants but its form action is Direct Post to Paratika so that any financially sensitive data will be collected still at the convenience of a merchant hosted page but to be fully compatible with PCI DSS. This will overcome the shortage of the API integration model for the merchants willing 100% compliance with PCI DSS without any additional effort on their side. Please see the flow below for details. Step 1: The Merchant Core System makes a Session Token request in order to get a valid key value for defining the session. Step 2: The payment session request is processed; a session token is created and sent back to the merchant system in the API response. Step 3: Merchant system serves the payment & wallet page using the given secure session token. Extra Point Step: In Direct Post model merchant need to do a query points with SESSIONTOKEN, CARDPAN,CARDEXPIRY parameters. According to QUERYPOINTS response sample form points input should be set as sale by points samples. And to send the payment to related payment system, merchant needs to send payment system name as paymentSystem input parameter at sample form. Payment system name can be get via QUERYPAYMENTSYSTEMS with SESSIONTOKEN and BIN. Step 4: Cardholder interacts with the page and clicks on Confirm button. Merchant system submits all information received via this page to Paratika system. Step 5: Paratika processes the payment details (and optionally starts 3D authentication process on behalf of the merchant) via an invisible interim page. Step 6: Paratika performs MOTO sale (or optionally directs the cardholder to 3D authentication servers). Step 7: ACS server serves the 3D authentication page where the cardholder enters a dynamic code sent to his/her mobile phone. Step 8: ACS server authenticates the user and returns back to Paratika invisible interim page. * Depending on authentication response, the transaction sent to bank either with full 3D details (if 3D authentication is done successfully) or as MOTO payment (if 3D authentication has failed). Step 9: Paratika make return the response to merchant return url TMX Javascript section in the HTML form below is mandatory. Direct POST (3D Secure) Test Form Sample POST Form Pay with Card Token Card Owner Name Card Number (PAN) Expiration Date January February March April May June July August September October November December 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 2031 2032 2033 2034 Security Code (CVV) Save Card Card Name Installment Count Card Token Installment Count Cardless Direct POST - 3D Secure "Cardless DIRECT POST (3D Secure) Test Form" example should be considered in order to integrate via cardless payment methods specified below. Maximum Mobil Cardless DIRECT POST (3D Secure) Test Form Sample Cardless POST Form Direct POST (3D Secure) Flow Sample response for Direct Post 3D merchantPaymentId: PaymentId-FVKAjOiFHeuE apiMerchantId: 700100000 paymentSystem: ISBANK TEST paymentSystemType: ISBANK paymentSystemEftCode: 0064 pgTranDate: 20170112 14:13:13 pgTranId: 17012ONNI07013454 pgTranRefId: 701200002832 pgTranApprCode: 733185 pgOrderId: PaymentId-FVKAjOiFHeuE customerId: Customer-u1Q4G1oG amount: 11.76 installment: 1 sessionToken: VYD7AXJ6C446GIN55V6KKOB677VRTOZHG5HTSMP3EJCMEQYF random: tpN2ynMYAn SD_SHA512: 0f2b4945aefc71f547107898c2002c40d9d4a1508f7f00ee894138f6bc247ebc1238ead5aa01b6ba09bc7932a5957235b7837cc0270781d0a45055fe31648b61 sdSha512: 099e32f8df3130457d2b1595b069794ef6ed08c85a679f72336c5371e91087b223536b317fc43643ae0da06ea29e985a3c8185ab611606308760b0c260aa412f responseCode: 00 responseMsg: Approved Direct Post 3D Authentication This integration model is based on the scenario that the process of 3D authentication is finished seperately from the Sale / Preauth API Call. Merchant offers a page where Card Holder enters his/her card data and submits them. This is where the process of 3D authentication starts. Depending on the response given from the authentication process, merchant issues authorization via API. Step 1: The Merchant Core System makes a Session Token request in order to get a valid key value for defining the session. Step 2: The payment session request is processed; a session token is created and sent back to the merchant system in the API response. Step 3: Merchant system serves the payment & wallet page using the given secure session token. Step 4: Cardholder interacts with the page and clicks on Submit button. Merchant system submits all information received via this page to MSU system. Step 5: MSU receives POST request from the merchant's page and directs it to the 3D ACS (Access Control Server) in order to continue with the 3D authentication flow. Step 6: ACS serves the 3D Security Page where the Card Holder must enter the correct (dynamic) code sent to his/her mobile phone in order to authenticate. Step 7: MSU handles the response of the 3D Authentication of success or failure. Step 8: The final response of the 3D Authentication process is forwarded to the merchant's page. The merchant is expected to listen and parse the result within the posted form later on issues authorization via API (Sale / Preauth). 3D Authentication Direct Post Test Form 3D Authentication with Card Data Form <form action="https://entegrasyon.paratika.com.tr/paratika/api/v2/post/auth3d/[SECURE_SESSION_TOKEN]" method="post"> <input type="text" name="cardOwner" placeholder="Card Owner" maxlength="32" /> <input type="text" name="pan" placeholder="PAN" maxlength="19" /> <select name="expiryMonth"> <option value="01">January</option> <option value="02">February</option> </select> <select name="expiryYear"> <option value="2019">2019</option> <option value="2020">2020</option> <option value="2021">2021</option> </select> <input type="password" name="cvv" placeholder="CVV" maxlength="4" /> <input type="checkbox" name="saveCard" /> <input type="text" name="cardName" placeholder="Card Name"/> <input type="text" name="cardCutoffDay" placeholder="Card Cutoff Day"/> <input type="text" name="installmentCount" placeholder="Installment Count"/> <input type="hidden" name="points" /> <input type="submit" value="Submit" /> </form> 3D Authentication with Card Token Form <form action="https://entegrasyon.paratika.com.tr/paratika/api/v2/post/auth3d/[SECURE_SESSION_TOKEN]" method="POST"> <input name="pan" type="text" size="20" /> <input name="cardOwner" type="text" size="20" /> <input name="expiryMonth" type="text" size="2"/> <input name="expiryYear" type="text" size="4"/> <input name="cvv" type="text" size="4"/> <input name="cardCutoffDay" type="text" size="2"/> <input name="callbackUrl" value="[merchant-return-url-handler]" /> <input type="submit" value="Complete Payment"/> </form> or if the payment will be done with an existing tokenized card <form action="https://entegrasyon.paratika.com.tr/paratika/api/v2/post/auth3d/[SECURE_SESSION_TOKEN]" method="POST"> <input name="cardToken" type="text" placeholder="Card Token"size="20" /> <input name="cvv" type="text" placeholder="CVV" size="4" /> <input type="submit" value="Complete Payment"/> </form> Direct Post 3D & 3D Authentication are similar processes. The only difference between them lays in the fact that Direct Post 3D finishes both 3D Authentication & Sale/Preauth in only one step. Regarding 3D Authentication, this process finishes only 3D Authentication. First, the 3D authentication is finished and after that, merchant issues authorization (Sale/Preauth) with the SESSION TOKEN provided with which 3D authentication was initiated. In order to use direct POS for shopping credit transactions, a SESSIONTOKEN must be created according to the parameters in the link below. SESSIONTOKEN Direct Post 3D Authentication Flow Sample response for 3D Authentication (Direct Post) sessionToken: 3URSNNY5C6ZATI656WIPXZXDSTAN3PNGLTXLY75H7FNBA7UJ auth3DToken: AUTH3DTOKEN responseCode: 00 responseMsg: Approved mdStatus: 1 mdErrorMsg: Authenticated BNPL Direct POS This integration model is based on the scenario that the Payment Page is being hosted by Merchants but its form action is Direct Post to Paratika so that any financially sensitive data will be collected still at the convenience of a merchant hosted page but to be fully compatible with PCI DSS. This will overcome the shortage of the API integration model for the merchants willing 100% compliance with PCI DSS without any additional effort on their side. Please see the flow below for details. Step 1: The merchant system sends a session token request by providing all necessary transaction/order details. None of the data in this step is considered sensitive information. Step 2: The session token request is processed, and if all the provided data is valid, a session token is generated and shared for the merchant's use. Step 3: Using the obtained session token information, the merchant displays a form on their web page. You can review the section below for an example of this form code. Step 4: The customer fills in the required fields on the form displayed on the merchant's page (or in any HTTP-supported mobile/desktop application) and submits the transaction request. The merchant then directly POSTs all the fields from this form to the Paratika system. Step 5: The Paratika system uses all transaction details and the data from the payment form to forward the request to the relevant bank/payment institution. Step 6: The customer provides the necessary information and completes the credit application. Step 7: The result of the credit application is sent from the payment institution/bank to the Paratika system. All fields in the HTML test form below are required to be sent to the Paratika system. The information for the paymentSystem field can be requested from the Operations team. Direct POST Test Form Sample POST Form