Payment Notification Form
This form is sent by PaySoft to the Merchant’s Result URL immediately after successful payment acceptance. The request sends Result URL value is specified in configurations of Merchant’s Store Profile.
Action - Result URL
Method – POST
|Merchant ID||LMI_MERCHANT_ID||Merchant’s ID from Merchant’s Store Profile.|
|Payment amount||LMI_PAYMENT_AMOUNT||Payment amount.|
|Total amount||LMI_PAID_AMOUNT||Total amount paid including Financial institution’s additional fees.|
|The reference to uniquely identify a payment||LMI_PAYMENT_NO||Order number according to the Merchant’s record-keeping system which is received from the Merchant in Payment request form.|
|Test mode attribute||LMI_MODE||Indicates the mode of payment acceptance: 0 - operating mode; 1 - test mode.|
|PaySoft system's reference number of payment||LMI_SYS_PAYMENT_ID||PaySoft system's reference number of payment|
|Payment method ID||LMI_PAYMENT_SYSTEM||Identifier of a payment method used to make a payment. NOTE: Test mode merchants can use just one payment system - test one (LMI_PAYMENT_SYSTEM = 18). It doesn’t involve any real settlements.|
|Payment acceptance date and time||LMI_SYS_PAYMENT_DATE||Payment acceptance date and time within PaySoft system in a format YYYY-MM-DD hh:mm:ss (Kyiv time).|
|Client information||LMI_PAYER_IDENTIFIER||Client’s payment data (for example, masked banking card number). Format depends on payment method which was used to make a payment.|
|Payment purpose||LMI_PAYMENT_DESC||Description of a product/work/service being paid for. Maximum length is 255. UTF8 encoding.|
|Client’s phone number||LMI_PAYER_PHONE_NUMBER||Client’s phone number in a format 380xxxxxxxxx.NOTE: Field value may differ from the one passed in Payment request form, if the flag With the right to modify if passed via protocol for the setting Require phone number is set in the Merchant’s User Profile.|
|Client’s email||LMI_PAYER_EMAIL||Client’s email.NOTE: Field value may differ from the one passed in Payment Request Form, if the flag With the right to modify if passed via protocol for the setting Require email is set in the Merchant’s User Profile.|
|Checksum||LMI_HASH||Payment notification form checksum which is used for received data integrity check and unambiguous sender identification.
Checksum is the result of encryption of a row obtained by joining (without separators) of values of the following parameters in the strictly specified order:
Encryption algorithm and Secret Key are set by the Merchant in configurations of its User Profile and is known solely to the Merchant and PaySoft system. Recommended encryption algorithm is SHA256.
|Additional parameters||Defined by Merchant||All the fields received from the Merchant in Payment request form without LMI_ prefix.|
Payment Notification Form lets the Merchant know that the payment was successfully accepted.
The Merchant must provide for data verification which is received from PaySoft in Payment notification form the way it is recommended for Initial request form. In addition, the Merchant must verify checksum (LMI_HASH). To do this the Merchant:
- generates a row by joining values of parameters received in Payment notification form in the order specified for checksum generation by PaySoft (see LMI_HASH parameter description above);
- using algorithm set in the Merchant’s User Profile, calculates the cipher of obtained row;
- translates obtained row into uppercase;
- compares the calculated cipher value to the LMI_HASH parameter value received via Payment Notification Form. If at least one verification failed the Merchant must postpone order processing, this kind of case should be manually reviewed by the Merchant’s employees.
PaySoft doesn’t expect any response to Payment Notification Form.
Since the Result URL gets 2 forms (Initial request form and Payment notification form), it is recommended to define which form is transferred by checking if the parameters are present: LMI_PREREQUEST (absent in Payment notification form) and/or LMI_HASH (absent in Initial request form) and/or LMI_SYS_PAYMENT_ID (absent in Initial request form) and so on.
If the Send Payment notification form repeatedly in case of failures flag is set in User Profile, payment notification form will be periodically sent again to Result URL until response with HTTP 200 code is received.
Recommended encryption algorithm is SHA256.