PayDala Terminal

There are several things you must consider when using requests for checking account existence in the PayDala Terminal method:

1. To verify the existence of the customer account, the payment platform sends the verify request to the web service URL using the HTTP method POST.
2. The request has the following parameters:
   • type—the operation type on the web service side (always verify)
   • customer_id—customer account name on the web service side. Customer enters this account name on the screen of the payment kiosk.
   • project_id—the project ID you obtained from JetPay
   • signature—signature created after you specify all the required parameters (for more information about signature generation, see Signature generation and verification)

   Figure: Example of data from a request for checking account existence

   {
       "type": "verify",
       "project_id": 1234,
       "customer_id": "7123456789",
       "signature": "e19695449545fac562843ca06e7e0f3e51281ad6"
   }

3. You need to send the response to the verify request synchronously. The response must contain the following parameters:
   • code—the response code
   • currency—the code of the purchase currency in the ISO-4217 alpha-3 format, required if the response code is 0

   Table 1. Allowed response codes

   Code	Description
   0	Success
   400	Signature error
   404	The customer account does not exist
   500	General error, the reason must be specified in the message parameter

   Your response can contain the following additional parameters:

   • additional_customer_id—the unique customer ID used for the customer identification in the JetPay payment platform
   • message—the free-form description of the response code

   If the existence account verification is successful, the response should contain the 0 response code to the request and the currency code.

   Figure: Example of a successful response

   {
       "code": 0,
       "currency": "KZT",
       "additional_customer_id": "customer_123"
   }

   If the request cannot be processed or the requested account is not found, the response should contain the 404 response code and the error description in the message parameter.

   Figure: Example of the request response with an error

   { 
       "code": 404,
       "message": "Account does not exist"
   }

There are several things you need to consider when dealing with requests for the transaction ID:

1. The payment platform sends the check_deposit request for the transaction ID on the web service side to the web service URL using HTTP method POST.
2. The request contains the following required parameters:
   • type—the operation type on the web service side (always check_deposit)
   • project_id—the project ID you obtained from JetPay
   • customer_id—customer account ID within the web service
   • amount—purchase amount in minor currency units without any decimal point or comma except for cases where the currency does not have any minor currency units. If the currency has no minor units (that is, the number of digits for minor currency units is zero), then you must set this parameter to the amount in the major currency units. For the information on whether the currency has any minor units, see Currency codes.
   • currency—code of purchase currency in the ISO-4217 alpha-3 format
   • payment_method—payment method name, set to terminal/paydala at all times
   • signature—signature created after you specify all the required parameters (for more information about signature generation, see Signature generation and verification)

   Figure: Example of the request for the transaction ID on the web service side

   {
       "type": "check_deposit",
       "project_id": 1234,
       "customer_id": "7123456789",
       "amount": 100000,
       "currency": "KZT",
       "payment_method": "terminal/paydala",
       "signature": "lY0LTSAzpR7...dOqRXJnL1kO0lUmkQ0YYLWRg=="
   }

3. You must respond to the check_deposit request synchronously. The response must contain the following parameters:
   • code—the response code
   • payment_id—the payment ID unique in the web service, required if the response code is 0

   Table 2. Applicable response codes

   Code	Description
   0	Success
   400	Signature error
   404	The customer account does not exist
   500	General error, the reason must be specified in the message parameter

   Your response can have the following additional parameters:

   • message—the free-form description of the response code
   • description—the description of the payment

   The response to the request for the transaction ID on the web service side must contain the response code and the unique transaction ID within the web service.

   Figure: Example of the response with the transaction ID

   {
       "code": 0,
       "payment_id": "payment_47",
       "description": "Success"
   }

   If the transaction ID cannot be found, the response must contain the response code and the error description in the message parameter.

   Figure: Example of the response with the information about an error

   {
       "code": 500,
       "message": "Something went wrong"
   }