Interface for creating a transaction

This XML interface allows the Merchant to create a transaction and verify the card's participation in 3DSecure technology

Action - https://card.paysoft.solutions/api/xml/payment-create

Method - POST

XML request format:

<Command>
    <LMI_MERCHANT_ID> </LMI_MERCHANT_ID>
    <LMI_HASH> </LMI_HASH>
    <LMI_PAYMENT_NO> </LMI_PAYMENT_NO>
    <LMI_PAYMENT_AMOUNT> </LMI_PAYMENT_AMOUNT>
    <LMI_PAYMENT_DESC> </LMI_PAYMENT_DESC>
    <LMI_CARDNUMBER> </LMI_CARDNUMBER>
    <LMI_EXPIRE_YEAR> </LMI_EXPIRE_YEAR>
    <LMI_EXPIRE_MONTH> </LMI_EXPIRE_MONTH>
    <LMI_CVV> </LMI_CVV>
    <LMI_PAYER_IP> </LMI_PAYER_IP>
    <LMI_MERCHANT_URL> </LMI_MERCHANT_URL>
</Command>
Title XML parameter Required? Description
Merchant ID LMI_MERCHANT_ID Yes The Merchant can get the identifier in the Cabinet.
Payment amount LMI_PAYMENT_AMOUNT Yes The amount of payment. The sum must be greater than zero, the fractional part is separated by a dot.
Internal order number in the Merchant's accounting system LMI_PAYMENT_NO No In this field, the Merchant defines the order number . Although this parameter is optional, it is recommended that you always set it because it is needed for other interfaces to work correctly. It is advisable to use a unique number for each payment. The number can contain letters of the English alphabet, numbers and the hyphen "_". The maximum length is 64 characters.
Payment details LMI_PAYMENT_DESC Yes Description of the goods/services that are paid for. The maximum length is 255 characters. Encoding - UTF8.
Signature of request LMI_HASH Yes The signature of the request is generated by hashing the original text of the XML request with an empty LMI\ _HASH value and the SecretKey using the algorithm specified in the Merchant Cabinet. The received signature is passed in the LMI_HASH tag. The recommended encryption algorithm is SHA256. Sign example
Card number LMI_CARDNUMBER Yes
Card expire year LMI_EXPIRE_YEAR Yes In the format: YY
Card expire month LMI_EXPIRE_MONTH Yes In the format: MM
CVV/CVV2 LMI\ _CVV Yes 3 digits
Customer Email LMI_PAYER_EMAIL No ** Customer Email Addresses
Customer ID on the Seller side LMI_PAYER_ID No May contain letters of the English alphabet, numbers and the hyphen "_". The maximum length is 250 characters.
Saving card details LMI_CREATE_TOKEN No The flag takes the value 0 or 1. If it is 1, then after a successful payment, the card details will be saved and the LMI_PAYMENT_TOKEN parameter will be returned. See [Write-off on a saved card] (../server2server/purchase-by-token.md)
Payment for the saved card token LMI_PAYMENT_TOKEN No The already saved card token is transferred. Payment will be made with confirmation of CVV ​​and 3DSecure
Splitting payment LMI_SPLIT No A payment splitting the amount into several recipients. This parameter specifies a JSON array with payment splitting rules. When using the LMI_SPLIT parameter, one charge from the client and several credits to recipients occur. Example JSON string:
` [{" CompanyId ": 1," Amount ": 20," CompanyName ":" "," Description ":" "," EDRPOU ":" "," IBAN ": ""}, {"CompanyId": 2, "Amount": 12, "CompanyName": "", "Description": "", "EDRPOU": "", "IBAN": ""}] "
Payer IP LMI_PAYER_IP Yes Payer's IP address
Site URL LMI_MERCHANT_URL Yes The domain where the payment was made

XML response format:

<Response>
    <Retval> </Retval>
    <Retdesc> </Retdesc>
    <Retdata>
        <LMI_SYS_PAYMENT_ID> </LMI_SYS_PAYMENT_ID>
        <Is3ds> </Is3ds>
        <action> </action>
        <PaReq> </PaReq>
        <MD> </MD>
        <ErrorMessage> </ErrorMessage>
    </Retdata>

</Response>
Title Field in XML Description
Request execution code Retval 0 - successful command execution; 1 - Incorrect signature \ (HASH ); 2 - incorrect parameters; 3 - A card of this type cannot be processed; 4,5,6,7 - internal error; 8 - in progress
Description of the execution code Retdesc
Internal payment number in the PaySoft system Retdata/LMI_SYS_PAYMENT_ID Number of the accepted payment in the PaySoft system.
Is3ds flag of the card's involvement in 3D-Secure (0 - the card does not require 3DSecure verification; 1 - the card needs 3D-Secure verification ).
action Client redirect URL. Returned only if Retval=1 and Retdata/Is3ds=1
PaReq request parameters for 3D-Secure. Returned only if Retval = 1 and Retdata/Is3ds = 1
MD request parameters for 3D-Secure. Returned only if Retval = 1 and Retdata/Is3ds = 1
ErrorMessage additional error information

If in response to paymentCreate the Retdata/Is3ds = 1 field value was received, this means that the card requires verification using 3D-Secure technology. To carry out such a check, it is necessary to generate and send an html-form using the POST method to the address specified in the Retdata/action field.

Attention! You cannot ignore the fact that the card is involved in 3D-Secure. If Is3ds = 1 was received in response to paymentCreate, then you cannot skip this step (card authorization using 3D-Secure ) and go directly to the paymentConfirm command.

If Is3ds=0, you have make paymentConfirm request to complete payment.

An example HTML form containing all the required fields:

` xml

``

Html form parameters:

  • %action% - value of the Retdata/action field from the response to the paymentCreate request
  • %PaReq% - value of the Retdata/PaReq field from the response to the paymentCreate request
  • %MD% - value of the Retdata/MD field from the response to the paymentCreate request
  • %TERMURL% - URL address of your page, to which the client will return after 3D-Secure verification. May contain GET parameters.

After 3DSecure verification, the client will be redirected to the address specified in TermUrl using a POST request. PaRes and MD will be among the parameters of this request.

results matching ""

    No results matching ""