Skip to main content
POST
Funds hold (two-stage payments)

Authorizations

sign
string
requestBody
required

Every API request must be signed so that we can identify your account.

The signature is transferred in the request body through the sign parameter, for example:

All further request examples do not include the "sign" parameter, nevertheless your real requests must include it in the request body where required.

Signature line is generated according to the following algorithm: all request parameters involved in signature generation are ordered in the alphabetical order of keys, the values are concatenated with a colon (":") and the account secret key is added at the end (without the: sign), a sha256 hash is generated from the resulting line and its hex representation is passed in the sign request parameter.

Example of signature generation for a method invoice/create:

  1. Determining the list of parameters. It looks as follows for the method in consideration:

Fields involved in request signature generation:

  • shop_id
  • shop_order_id
  • amount
  • currency
  • payway
  1. Let's sort keys in alphabetical sequence:

"amount", "currency", "payway", "shop_id", "shop_order_id"

  1. The line for generating the SHA256 hash will be as follows:

"6320.91:840:card_invoice_usd:1520:5b0efa8a-153b-4421-abac-2aba4d772a86account-secret-key"

Where account-secret-key is the secret identification key for your account. You can request a key from the support service.

  1. Let's get a hash expression of the generated line using Python code:
You can check whether you have generated the signature correctly using the service https://www.xorbin.com/tools/sha256-hash-calculator.

Body

application/json
shop_id
integer
required

Unique shop identifier in the M4 system.

Example:

1520

shop_order_id
string
required

Order ID in your system. Must be unique for each new invoice.

Maximum string length: 255
Example:

"5b0efa8a-153b-4421-abac-2aba4d772a86"

amount
string
required

Amount received or withdrawn.

Example:

"6320.91"

currency
number
required

Numeric currency identifier in accordance with ISO 4217.

Example:

840

payway
string
required

Payment way for payment. Invoice currency depends on the specified payment way.

There are two ways to get a list of all payment directions available to the shop:

  • Execute API request "Receiving payment methods for input" shop_input_config/shop.
  • Request register from the support service.
Maximum string length: 150
Pattern: ^[A-Za-z_,\[\]]+$
Example:

"card_payway_usd"

client_ip
string<IPv4>
required

Payer IP address

Example:

"192.168.1.1"

description
string

Optional payment description.

Maximum string length: 255
Example:

"Payment for shop_id=1520"

failed_url
string<uri>

URL where the payer will be redirected after unsuccessful invoice payment.

Example:

"https://your-domain.com/status/failed/"

success_url
string<uri>

URL where the payer will be redirected after successful invoice payment.

Example:

"https://your-domain.com/status/success/"

callback_url
string<uri>

URL where the notification about successful payment will be sent.

Example:

"https://your-domain.com/status/callback/"

callback_rejected_url
string<uri>

URL where the notification about unsuccessful payment will be sent.

Example:

"https://your-domain.com/status/rejected/"

expires_at
string<date-time>

Invoice expiration date in ISO 8601 format. If invoice is not paid until this date, subsequent invoice payment will not be possible.

Example:

"2026-06-01T00:00:00Z"

card
object

Bank card details should be sent when:

  • You have a PCI DSS certificate
  • You do not need a page on the M4 side to get card details from the buyer

In case the payment way to the cards is used and the card data is not transmitted, the response to the request will contain a link to redirect the buyer to enter the card details. Also, method, url and data will be filled in if the user needs to be redirected to pass the 3DSecure check.

issue_payment_token
boolean

This parameter is used to generate a payment token. More details invoice/recurrent

Example:

false

client_info
object

Payer browser information.

See Payer Browser Authentication for 3D Secure for the details of the data gathering.

Response

200 - application/json
result
boolean
required

Boolean value, in case of successful response it will be true, in case of error – false

Example:

true

message
string
required

A textual description of the error, in case of success - simply Ok

Example:

"Ok"

error_code
number
required

If this value is greater than 0, then the request ended with an error. Description of error codes

Example:

0

data
Invoice payment form · object
required