Scheme of work


Diagram


Description of the scheme of work

  1. On the page for choosing a product or service from a merchant, after confirming the order form, a request is sent to the merchant's web server.
  2. On the side of the merchant's web server, if necessary, preliminary checks of the order are made, a data signature is generated, and the request is redirected by the GET method to the eCom server (https://jpay.jysanbank.kz/ecom/api).
  3. eCom system makes preliminary checks of the order. If all checks are successful, then eCom generates a payment page for the client (step 3). If in the request at step 2 the identifier of the client authenticated on the merchant's website was provided CLIENT_ID, then on the page the client is provided with a list of cards for selection, with which this client has already made successful payments. Note: the option of choosing a card is available only if the bank has decided to store the data of customer cards, for details, contact a bank representative. If any of the checks are not passed, then a page with a description of the error is generated for the client, and the result of order processing is sent to the merchant's website (step 8).
  4. The client enters the details of his payment card, with which he is going to pay for the order, and confirms the payment for the order.
  5. eCom performs order checks. If all checks are successful, then eCom sends a request to MPI to pay for the order using the entered or selected customer card (step 5). If any of the checks are not passed, then a page describing the error is generated for the client and the result of order processing is sent to the merchant's website (step 8).
  6. MPI, if necessary, asks the client for the 3DSecure password, then performs the payment operation. MPI then returns the result of the operation to eCom (step 7).
  7. The eCom system generates a page for the client describing the result of the operation.
  8. If the address is specified in the BACKREF parameter (description after the table) or the default address in the APM for this merchant, then the eCom system, after processing the payment in the background, generates a POST request with the result of the operation to this address:
    Request parameters
    Parameters Description
    order Order number
    mpi_order MPI order number
    amount Transaction amount
    currency Transaction currency
    res_code Result code:
    0 - Transaction completed successfully
    1 - Repeated transaction
    2 - Transaction declined
    3 - Transaction processing error
    4 - Announcement
    rc MPI Result Code
    rrn RRN (returned only in case of successful operation)
    sign Sign
    terminal Terminal (for compatibility with older versions, does not participate in signature)
    result Result code (repeats the res_code value, for compatibility with old versions, does not participate in the signature)

    For example, if you specify https://www.google.kz in BACKREF, then the browser will be redirected to the address: https://www.google.kz with order = 529619375 & mpi_order = 1012121121529619375 & amount = 0.9¤cy = EUR & res_code = 28 & rc = 00 & rrn parameters = 12345678901 & sign = 124542232343.

    The algorithm for verifying the signature of the sign field is as follows, you need to collect in one line the values of all parameters in the specified order, separated by the separator ";", then add this line to the value of the secret key SHARED_SECRET (this key is individual for each merchant), and calculate the hash value from the resulting string SHA512. For example, in PHP it would look like this:

    vSign=hash("sha512",C_SHARED_KEY.
    .$_POST["order"].";"
    .$_POST["mpi_order"].";"
    .$_POST["amount"].";"
    .$_POST["сurrency"].";"
    .$_POST["res_code"].";"
    .$_POST["rc"].";"
    .$_POST["rrn"].";" );

  9. If the email of the client was specified in step 2, then an email is sent to this address with the result of the operation.