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.
Surname	LMI_PAYER_SURNAME	No***	Surname
Firstname	LMI_PAYER_FIRSTNAME	No***	Firstname
Patronymic	LMI_PAYER_PATRONYMIC	No***	Patronymic
Date of birth	LMI_PAYER_BIRTHDAY	No***	Date of birth
tax id	LMI_PAYER_TAX_ID	No***	tax id
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.

Create payment

Interface for creating a transaction

results matching ""

No results matching ""