Payment operation types

This page is the per-action reference for S2S CARD. It covers the payment operations Payin and Payout, and the recurring schedule operations. For a conceptual overview of the protocol see the S2S Card overview; for the redirect flow see Redirect / 3DS handling.

Not-found codes vary per entity

Since 6.7.0 the not-found error code depends on the entity the action targets. Transaction-entity and order-entity operations (GET_TRANS_STATUS, GET_TRANS_STATUS_BY_ORDER, CAPTURE) return 101000; payment-entity operations (VOID, CREDITVOID) and schedule-entity operations return 100000 with their own specific messages. See the troubleshooting page for the per-action map.

Payment operations

SALE/AUTH request

Payment Platform supports two main operation type: Single Message System (SMS) and Dual Message System (DMS).

SMS is represented by SALE transaction. It is used for authorization and capture at a time. This operation is commonly used for immediate payments.

DMS is represented by AUTH and CAPTURE transactions. AUTH is used for authorization only, without capture. This operation used to hold the funds on card account (for example to check card validity).

SALE request is used to make both SALE and AUTH transactions.

If you want to make AUTH transaction, you need to use parameter auth with value Y.

For AUTH transaction it is possible to set the order_amount to 0 (usefull for the card tokenization). The same applies to a SALE or DEBIT sent with recurring_init=Y.

If you want to send a payment for the specific sub-account (channel), you need to use channel_id, that specified in your Payment Platform account settings.

This request is sent by POST in the background (e.g. through PHP CURL).

If the response returns result = REDIRECT, you must redirect the payer to the provided URL. See Redirect / 3DS handling for the full redirect flow.

⚠️ Pay attention

In the case of cascading, the logic for sending callbacks differs.
If cascading is triggered for the order, in general case you will receive only callback for the last payment attempt, where the final status of the order (settled or declined) is determined. In the particular cases, you will receive callback for the first payment attempt with the data for customer’s redirection if it is required by payment provider. Callbacks for intermediate attempts (between the first decline and the last payment attempt) are not sent.

Request parameters

Parameter	Description	Values	Required field
action	Sale	SALE	+
client_key	Unique key (client_key)	UUID format value	+
channel_id	Payment channel (Sub-account)	String up to 16 characters	-
order_id	Transaction ID in the Merchants system	String up to 255 characters	+
order_amount	The amount of the transaction	Format depends on currency. Send Integer type value for currencies with zero-exponent. Example: 1000 Send Float type value for currencies with exponents 2, 3, 4. Format for 2-exponent currencies: XX.XX Example: 100.99 Pay attention that currencies 'UGX', 'JPY', 'KRW', 'CLP' must be send in the format XX.XX, with the zeros after comma. Example: 100.00 Format for 3-exponent currencies: XXX.XXX Example: 100.999. Format for 4-exponent currencies: XXX.XXXX Example: 100.9999 Pay attention: If you send auth=Y or recurring_init=Y, it is possible to set the amount to 0	+
order_currency	Currency	3-letter code	+
order_description	Description of the transaction (product name)	String up to 1024 characters	+
callback_url	URL that Payment Platform sends the callback for this transaction to. Overrides the Notification URL configured in the admin panel, for this request only.	Valid URL, string up to 255 characters	-
req_token	Special attribute pointing for further tokenization	Y or N (default N)	-
card_token	Credit card token value	String 64 characters	-
card_number	Credit Card Number		+ *
card_exp_month	Month of expiry of the credit card	Month in the form XX	+ *
card_exp_year	Year of expiry of the credit card	Year in the form XXXX	+ *
card_cvv2	CVV/CVC2 credit card verification code	3-4 symbols	+ **
digital_wallet	Determines the use of digital wallets Possible values: • googlepay • applepay Make sure that both digital_wallet and payment_token parameters are specified	String	-
payment_token	Digital wallet token value Provide payment token received from Apple Pay or Google Pay. Make sure that both digital_wallet and payment_token parameters are specified. If the card_token is specified, payment_token will be ignored. If the optional payment_token and card data are specified, payment_token will be ignored.	String	-
payer_first_name	Customer's name	String up to 32 characters	+
payer_last_name	Customer's surname	String up to 32 characters	+
payer_middle_name	Customer's middle name	String up to 32 characters	-
payer_birth_date	Customer's birthday	format yyyy-MM-dd, e.g. 1970-02-17	-
payer_address	Customer's address	String up to 255 characters	+ ***
payer_address2	The adjoining road or locality (if required) of the сustomer's address	String up to 255 characters	-
payer_house_number	Customer's house or building number	String up to 9 characters	-
payer_phone_country_code	Country calling code of the payer’s phone number	Digits, up to 10 characters. A hyphen is allowed for composite codes, for example 1-684	-
payer_country	Customer's country	2-letter code	+ ***
payer_state	Customer's state. Collected and validated only when payer_country is CA, US, JP, AU, or IN; ignored for other countries.	String up to 32 characters	-
payer_city	Customer's city	String up to 40 characters	+ ***
payer_district	Customer's district of city	String up to 32 characters	-
payer_zip	ZIP-code of the Customer	String up to 10 characters	+ ***
payer_email	Customer's email	String up to 255 characters	+
payer_phone	Customer's phone	String up to 32 characters	+
payer_ip	IP-address of the Customer Both versions, IPv4 and IPv6, can be used. If you are sending IPv6, make sure the payment provider that processes the payments supports it.	XXX.XXX.XXX.XXX	+
payer_language	Language of the platform-hosted pages shown to the Customer during the payment, such as the interaction template and the Thank You page. The value is case-insensitive and is not validated: a code that is not on the list falls back to English. If the parameter is omitted, the Checkout Default Language from the Protocol Mapping settings is used. If that is not set either, the language is taken from the Customer's browser.	One of: en, sp, ar, az, fr, nb, zh, zh-TW, kk, de, it, hr, cs, hu, pl, pt, ro, ja, nl, bg, ru	-
term_url_3ds	URL to which Customer should be returned after 3D-Secure	String up to 1024 characters	+
term_url_target	Name of, or keyword for a browsing context where Customer should be returned according to HTML specification.	String up to 1024 characters Possible values: _blank, _self, _parent, _top or custom iframe name (default _top). Find the result of applying the values in the HTML standard description (Browsing context names)	-
recurring_init	Initialization of the transaction with possible following recurring	Y or N (default N)	-
schedule_id	Schedule ID for recurring payments	String	-
schedule_start_date	Exact date of the first scheduled payment. Requires schedule_id. When it is sent, delayed_first_payment from the schedule settings is ignored and every following payment is counted from schedule_start_date plus the schedule interval.	Date in the format YYYY-MM-DD	-
payment_schedule_amount	Amount of the payments created later by schedule_id. Use it when the initial recurring amount, a trial period for example, differs from the later charges. Requires schedule_id.	A positive number without leading zeros. The exponent rules are the same as for order_amount	-
auth	Indicates that transaction must be only authenticated, but not captured	Y or N (default N)	-
payer_present	Indicates that the payer initiated the payment: a Customer-Initiated Transaction (CIT) when Y, versus a Merchant-Initiated Transaction (MIT) when N.	Y or N (default Y)	-
mpi_data	3DS authentication results obtained from your own MPI, when you authenticate the payer yourself. Accepted on SALE, including with recurring_init=Y. Not accepted with auth=Y. When it is sent, Payment Platform does not run its own 3DS authentication and no REDIRECT is returned. See Sale / Authorization for the format of each field.	Format: mpi_data[eci]: 05 mpi_data[authentication_value]: AAABCZIhcQAAAABZlyHRAAAAAAA= mpi_data[ds_trans_id]: 6468f138-4287-4df5-a0d4-cbc48b157b49 mpi_data[3ds_version]: 2.2.0 All four are required once the object is sent. Optional: mpi_data[trans_status]: Y mpi_data[xid]: none	-
parameters	Object that contains extra parameters required by the acquirer	Format: parameters[param1]: value1 parameters[param2]: value2 parameters[paramN]: valueN See Appendix C for more details.	-
custom_data	Array with the custom data This block duplicates the arbitrary parameters that were passed in the payment request	Format: custom_data [param1]: value1 custom_data [param2]: value2 custom_data [paramN]: valueN	-
hash	Special signature to validate your request to Payment Platform	See Appendix A, Formula 1 In case of digital wallets - Formula 8	+

*This field becomes optional if card_token or payment_token is specified

** This field becomes optional if card_token or payment_token is specified

*** Required by default. These fields become optional only when they are listed under Optional Request Parameters in the S2S CARD protocol mapping (Configurations → Protocol Mappings → S2S CARD).

If the optional parameter card_token and card data are specified, card_token will be ignored.

If the optional parameters req_token and card_token are specified, req_token will be ignored.

Response parameters

You will get JSON encoded string (see an example on Appendix B) with transaction result. If your account supports 3D-Secure, transaction result will be sent to your Notification URL.

Synchronous mode

Successful sale response

Parameter	Description
action	SALE
result	SUCCESS
status	PENDING / PREPARE / SETTLED; only PENDING when auth = Y
order_id	Transaction ID in the Merchant's system
trans_id	Transaction ID in Payment Platform
trans_date	Transaction date in Payment Platform
descriptor	Descriptor from the bank, the same as cardholder will see in the bank statement
recurring_token	Recurring token (get if account support recurring sales and was initialization transaction for following recurring)
schedule_id	Schedule ID for recurring payments. It is available if schedule is used for recurring sale
schedule_start_date	Date of the first scheduled payment. It is available if schedule_start_date was sent in the initiating request. Format: YYYY-MM-DD HH:MM:SS
payment_schedule_amount	Amount of the payments created later by the schedule. It is available if payment_schedule_amount was sent in the initiating request
card_token	If the parameter req_token was enabled Payment Platform returns the token value
amount	Order amount
currency	Currency
digital_wallet	Wallet provider: googlepay, applepay

Unsuccessful sale response

Parameter	Description
action	SALE
result	DECLINED
status	DECLINED
order_id	Transaction ID in the Merchant's system
trans_id	Transaction ID in Payment Platform
trans_date	Transaction date in Payment Platform
descriptor	Descriptor from the bank, the same as cardholder will see in the bank statement
amount	Order amount
currency	Currency
decline_reason	The reason why the transaction was declined
digital_wallet	Wallet provider: googlepay, applepay

3D-Secure transaction response

Parameter	Description
action	SALE
result	REDIRECT
status	3DS / REDIRECT
order_id	Transaction ID in the Merchant's system
trans_id	Transaction ID in Payment Platform
trans_date	Transaction date in Payment Platform
descriptor	Descriptor from the bank, the same as cardholder will see in the bank statement
amount	Order amount
currency	Currency
redirect_url	URL to which the Merchant should redirect the Customer
redirect_params	Object of specific 3DS parameters. It is array if redirect_params have no data. The availability of the redirect_params depends on the data transmitted by the acquirer. redirect_params may be missing. It usually happens when redirect_method = GET
redirect_method	The method of transferring parameters (POST / GET)
digital_wallet	Wallet provider: googlepay, applepay

Undefined sale response

Parameter	Description
action	SALE
result	UNDEFINED
status	PENDING / PREPARE; PENDING only when auth = Y
order_id	Transaction ID in the Merchant's system
trans_id	Transaction ID in Payment Platform
trans_date	Transaction date in Payment Platform
descriptor	Descriptor from the bank, the same as cardholder will see in the bank statement
amount	Order amount
currency	Currency
digital_wallet	Wallet provider: googlepay, applepay

Callback parameters

Successful sale response

Parameter	Description
action	SALE
result	SUCCESS
status	PENDING/PREPARE/SETTLED
order_id	Transaction ID in the Merchant's system
trans_id	Transaction ID in Payment Platform
hash	Special signature, used to validate callback, see Appendix A, Formula 2
recurring_token	Recurring token (get if account support recurring sales and was initialization transaction for following recurring)
schedule_id	It is available if schedule is used for recurring sale
schedule_start_date	Date of the first scheduled payment. It is available if schedule_start_date was sent in the initiating request. Format: YYYY-MM-DD HH:MM:SS
payment_schedule_amount	Amount of the payments created later by the schedule. It is available if payment_schedule_amount was sent in the initiating request
first_recurring_date	Date of the first automatic charge by the schedule. It is available if schedule is used for recurring sale. Format: YYYY-MM-DD HH:MM:SS
card_token	If the parameter req_token was enabled Payment Platform returns the token value
connector_name *	Connector's name (Payment Gateway)
rrn *	Retrieval Reference Number value from the acquirer system
approval_code *	Approval code value from the acquirer system
gateway_id *	Gateway ID – transaction identifier provided by payment gateway
extra_gateway_id *	Extra Gateway ID – additional transaction identifier provided by payment gateway
merchant_name *	Merchant Name
mid_name *	MID Name
issuer_country *	Issuer Country
issuer_bank *	Issuer Bank
merchant_key *	Merchant key (CLIENT_KEY) value
extended_data *	Transaction extended data
brand *	Payment method brand used in the transaction
arn *	Acquirer Reference Number value from the acquirer system
card	Card mask. If a digital wallet was used, the value obtained when decrypting the wallet token will be provided in this parameter
card_expiration_date	Card expiration date
trans_date	Transaction date in Payment Platform
descriptor	Descriptor from the bank, the same as cardholder will see in the bank statement
amount	Order amount
currency	Currency
exchange_rate	Rate used to make exchange. It returns if the currency exchange has been applied for the payment.
exchange_rate_base	The rate used in the double conversion to convert the original currency to the base currency. It returns if the currency exchange has been applied for the payment.
exchange_currency	Original currency. It returns if the currency exchange has been applied for the payment.
exchange_amount	Original amount. It returns if the currency exchange has been applied for the payment.
custom_data	Object with the custom data. This block duplicates the arbitrary parameters that were passed in the payment request
digital_wallet	Wallet provider: googlepay, applepay
pan_type	It refers to digital payments, such as Apple Pay and Google Pay, and the card numbers returned as a result of payment token decryption: DPAN (Digital Primary Account Number) and FPAN (Funding Primary Account Number).

* The parameters are included if the appropriate setup is configured in the admin panel (see “Add Extended Data to Callback” block in the Configurations -> Protocol Mappings section).

Unsuccessful sale response

Parameter	Description
action	SALE
result	DECLINED
status	DECLINED
order_id	Transaction ID in the Merchant`s system
trans_id	Transaction ID in Payment Platform
trans_date	Transaction date in Payment Platform
decline_reason	Description of the cancellation of the transaction
custom_data	Object with the custom data. This block duplicates the arbitrary parameters that were passed in the payment request
digital_wallet	Wallet provider: googlepay, applepay
pan_type	It refers to digital payments, such as Apple Pay and Google Pay, and the card numbers returned as a result of payment token decryption: DPAN (Digital Primary Account Number) and FPAN (Funding Primary Account Number).
hash	Special signature, used to validate callback, see Appendix A, Formula 2

3D-Secure transaction response

Parameter	Description
action	SALE
result	REDIRECT
status	3DS/REDIRECT
order_id	Transaction ID in the Merchant`s system
trans_id	Transaction ID in Payment Platform
trans_date	Transaction date in Payment Platform
descriptor	Descriptor from the bank, the same as cardholder will see in the bank statement
amount	Order amount
currency	Currency
redirect_url	URL to which the Merchant should redirect the Customer
redirect_params	Object with the parameters. It is array if redirect_params have no data. The availability of the redirect_params depends on the data transmitted by the acquirer. redirect_params may be missing. It usually happens when redirect_method = GET
redirect_method	The method of transferring parameters (POST or GET)
custom_data	Object with the custom data. This block duplicates the arbitrary parameters that were passed in the payment request
digital_wallet	Wallet provider: googlepay, applepay
pan_type	It refers to digital payments, such as Apple Pay and Google Pay, and the card numbers returned as a result of payment token decryption: DPAN (Digital Primary Account Number) and FPAN (Funding Primary Account Number).
hash	Special signature, used to validate callback, see Appendix A, Formula 2

Undefined sale response

Parameter	Description
action	SALE
result	UNDEFINED
status	3DS / REDIRECT / PENDING / PREPARE
order_id	Transaction ID in the Merchant`s system
trans_id	Transaction ID in Payment Platform
trans_date	Transaction date in Payment Platform
descriptor	Descriptor from the bank, the same as cardholder will see in the bank statement
amount	Order amount
currency	Order currency
custom_data	Object with the custom data. This block duplicates the arbitrary parameters that were passed in the payment request
digital_wallet	Wallet provider: googlepay, applepay
pan_type	It refers to digital payments, such as Apple Pay and Google Pay, and the card numbers returned as a result of payment token decryption: DPAN (Digital Primary Account Number) and FPAN (Funding Primary Account Number).
hash	Special signature, used to validate callback, see Appendix A, Formula 2

CAPTURE request

---

CAPTURE request is used to submit previously authorized transaction (created by SALE request with parameter auth = Y). Hold funds will be transferred to Merchants account.

This request is sent by POST in the background (e.g. through PHP CURL).

Request parameters

Parameter	Description	Values	Required field
action	Capture previously authenticated transaction	CAPTURE	+
client_key	Unique key (client_key)	UUID format value	+
trans_id	Transaction ID in Payment Platform	UUID format value	+
amount	The amount for capture. Only one partial capture is allowed	Format depends on currency. Send Integer type value for currencies with zero-exponent. Example: 1000 Send Float type value for currencies with exponents 2, 3, 4. Format for 2-exponent currencies: XX.XX Example: 100.99 Pay attention that currencies 'UGX', 'JPY', 'KRW', 'CLP' must be send in the format XX.XX, with the zeros after comma. Example: 100.00 Format for 3-exponent currencies: XXX.XXX Example: 100.999. Format for 4-exponent currencies: XXX.XXXX Example: 100.9999	-
hash	Special signature to validate your request to Payment Platform	see Appendix A, Formula 2	+

Response parameters

Synchronous mode

Successful capture response

Parameter	Description
action	CAPTURE
result	SUCCESS
status	SETTLED
amount	Amount of capture
order_id	Transaction ID in the Merchants system
trans_id	Transaction ID in Payment Platform
trans_date	Transaction date in Payment Platform
descriptor	Descriptor from the bank, the same as cardholder will see in the bank statement
currency	Currency

Unsuccessful capture response

Parameter	Description
action	CAPTURE
result	DECLINED
status	PENDING
order_id	Transaction ID in the Merchant's system
trans_id	Transaction ID in Payment Platform
trans_date	Transaction date in Payment Platform
descriptor	Descriptor from the bank, the same as cardholder will see in the bank statement
amount	Amount of capture
currency	Currency
decline_reason	The reason why the capture was declined

Undefined capture response

Parameter	Description
action	CAPTURE
result	UNDEFINED
status	PENDING
order_id	Transaction ID in the Merchant's system
trans_id	Transaction ID in Payment Platform
trans_date	Transaction date in Payment Platform
descriptor	Descriptor from the bank, the same as cardholder will see in the bank statement
amount	Amount of capture
currency	Currency

Callback parameters

Successful capture response

Parameter	Description
action	CAPTURE
result	SUCCESS
status	SETTLED
order_id	Transaction ID in the Merchant's system
trans_id	Transaction ID in Payment Platform
amount	Amount of capture
trans_date	Transaction date in Payment Platform
descriptor	Descriptor from the bank, the same as cardholder will see in the bank statement
currency	Currency
connector_name *	Connector's name (Payment Gateway)
rrn *	Retrieval Reference Number value from the acquirer system
approval_code *	Approval code value from the acquirer system
gateway_id *	Gateway ID – transaction identifier provided by payment gateway
extra_gateway_id *	Extra Gateway ID – additional transaction identifier provided by payment gateway
merchant_name *	Merchant Name
mid_name *	MID Name
issuer_country *	Issuer Country
issuer_bank *	Issuer Bank
merchant_key *	Merchant key (CLIENT_KEY) value
arn *	Acquirer Reference Number value from the acquirer system
hash	Special signature, used to validate callback, see Appendix A, Formula 2

* The parameters are included if the appropriate setup is configured in the admin panel (see “Add Extended Data to Callback” block in the Configurations -> Protocol Mappings section).

Unsuccessful capture response

Parameter	Description
action	CAPTURE
result	DECLINED
status	PENDING
order_id	Transaction ID in the Merchant's system
trans_id	Transaction ID in Payment Platform
decline_reason	The reason why the capture was declined
hash	Special signature, used to validate callback, see Appendix A, Formula 2

Undefined capture response

Parameter	Description
action	CAPTURE
result	UNDEFINED
status	PENDING
order_id	Transaction ID in the Merchant's system
trans_id	Transaction ID in Payment Platform
trans_date	Transaction date in Payment Platform
descriptor	Descriptor from the bank, the same as cardholder will see in the bank statement
amount	Amount of capture
currency	Currency
hash	Special signature, used to validate callback, see Appendix A, Formula 2

CREDITVOID request

---

CREDITVOID request is used to complete both REFUND and REVERSAL transactions.

REVERSAL transaction is used to cancel hold from funds on card account, previously authorized by AUTH transaction.

REVERSAL transaction is used to reverse completed debit transaction.

REFUND transaction is used to return funds to card account, previously submitted by SALE or CAPTURE transactions.

This request is sent by POST in the background (e.g. through PHP CURL).

Request parameters

Parameter	Description	Values	Required field
action	CREDITVOID	CREDITVOID	+
client_key	Unique key (client_key)	UUID format value	+
trans_id	Transaction ID in Payment Platform	UUID format value	+
amount	The amount of full or partial refund. If amount is not specified, full refund will be issued. In case of partial refund this parameter is required. Several partial refunds are allowed	Format depends on currency. Send Integer type value for currencies with zero-exponent. Example: 1000 Send Float type value for currencies with exponents 2, 3, 4. Format for 2-exponent currencies: XX.XX Example: 100.99 Pay attention that currencies 'UGX', 'JPY', 'KRW', 'CLP' must be send in the format XX.XX, with the zeros after comma. Example: 100.00 Format for 3-exponent currencies: XXX.XXX Example: 100.999. Format for 4-exponent currencies: XXX.XXXX Example: 100.9999	-
hash	Special signature to validate your request to Payment Platform	see Appendix A, Formula 2	+

Response parameters

Synchronous mode

Parameter	Description
action	CREDITVOID
result	ACCEPTED
order_id	Transaction ID in the Merchant's system
trans_id	Transaction ID in Payment Platform

Callback parameters

Successful refund/reversal response

Parameter	Description
action	CREDITVOID
result	SUCCESS
status	REFUND/REVERSAL - for full refund SETTLED - for partial refund
order_id	Transaction ID in the Merchant's system
trans_id	Transaction ID in Payment Platform
creditvoid_date	Date of the refund/reversal
amount	Amount of refund
connector_name *	Connector's name (Payment Gateway)
rrn *	Retrieval Reference Number value from the acquirer system
approval_code *	Approval code value from the acquirer system
gateway_id *	Gateway ID – transaction identifier provided by payment gateway
extra_gateway_id *	Extra Gateway ID – additional transaction identifier provided by payment gateway
merchant_name *	Merchant Name
mid_name *	MID Name
issuer_country *	Issuer Country
issuer_bank *	Issuer Bank
merchant_key *	Merchant key (CLIENT_KEY) value
hash	Special signature, used to validate callback, see Appendix A, Formula 2

* The parameters are included if the appropriate setup is configured in the admin panel (see “Add Extended Data to Callback” block in the Configurations -> Protocol Mappings section).

Unsuccessful refund/reversal response

Parameter	Description
action	CREDITVOID
result	DECLINED
order_id	Transaction ID in the Merchant's system
trans_id	Transaction ID in Payment Platform
decline_reason	Description of the cancellation of the transaction
hash	Special signature, used to validate callback, see Appendix A, Formula 2

Undefined refund/reversal response

Parameter	Description
action	CREDITVOID
result	UNDEFINED
status	SETTLED
order_id	Transaction ID in the Merchant's system
trans_id	Transaction ID in Payment Platform
creditvoid_date	Transaction date in Payment Platform
amount	Order amount
hash	Special signature, used to validate callback, see Appendix A, Formula 2

VOID request

---

The VOID request is used to cancel the operation which was performed the same financial day.

The cancellation is possible for the operations:

• SALE
• CAPTURE
• SALE_RECURRING

The VOID request is allowed for the payments in SETTLED status only.

This request is sent by POST in the background (e.g. through PHP CURL).

Request parameters

Parameter	Description	Limitations	Required
action	Action to perform	= VOID	+
client_key	Unique client key	CLIENT_KEY	+
trans_id	Transaction ID in Payment Platform	UUID format value	+
hash	Special signature to validate your request to Payment Platform	See Appendix A, Formula 2.	+

Response parameters

You will get JSON encoded string with transaction result.

Successful void response

Parameter	Description
action	VOID
result	SUCCESS
status	VOID
order_id	Transaction ID in the Client's system
trans_id	Transaction ID in Payment Platform
trans_date	Transaction date in Payment Platform

Unsuccessful void response

Parameter	Description
action	VOID
result	DECLINED
status	SETTLED
order_id	Transaction ID in the Client's system
trans_id	Transaction ID in Payment Platform
trans_date	Transaction date in Payment Platform
decline_reason	The reason why the transaction was declined

Undefined void response

Parameter	Description
action	VOID
result	UNDEFINED
status	PENDING / SETTLED
order_id	Transaction ID in the Client's system
trans_id	Transaction ID in Payment Platform
trans_date	Transaction date in Payment Platform

Callback parameters

Successful void response

Parameter	Description
action	VOID
result	SUCCESS
status	VOID
order_id	Transaction ID in the Client's system
trans_id	Transaction ID in Payment Platform
trans_date	Transaction date in Payment Platform
connector_name *	Connector's name (Payment Gateway)
rrn *	Retrieval Reference Number value from the acquirer system
approval_code *	Approval code value from the acquirer system
gateway_id *	Gateway ID – transaction identifier provided by payment gateway
extra_gateway_id*	Extra Gateway ID – additional transaction identifier provided by payment gateway
merchant_name *	Merchant Name
mid_name *	MID Name
issuer_country *	Issuer Country
issuer_bank *	Issuer Bank
merchant_key *	Merchant key (CLIENT_KEY) value
hash	Special signature, used to validate callback. See Appendix A, Formula 2.

* The parameters are included if the appropriate setup is configured in the admin panel (see “Add Extended Data to Callback” block in the Configurations -> Protocol Mappings section).

Unsuccessful void response

Parameter	Description
action	VOID
result	DECLINED
status	SETTLED
order_id	Transaction ID in the Client's system
trans_id	Transaction ID in Payment Platform
trans_date	Transaction date in Payment Platform
decline_reason	The reason why the transaction was declined
hash	Special signature, used to validate callback. See Appendix A, Formula 2.

Undefined void response

Parameter	Description
action	VOID
result	UNDEFINED
status	PENDING / SETTLED
order_id	Transaction ID in the Client's system
trans_id	Transaction ID in Payment Platform
trans_date	Transaction date in Payment Platform
hash	Special signature, used to validate callback. See Appendix A, Formula 2.

DEBIT request

Use DEBIT action to create debit transaction as a part of transfer flow.

If the response returns result = REDIRECT, you must redirect the payer to the provided URL. See Redirect / 3DS handling for the full redirect flow.

Request Parameters

Parameter	Description	Values	Required
action	Action that you want to perform. Fixed value.	DEBIT	+
client_key	Unique key (CLIENT_KEY)	UUID format value	+
order_id	Transaction ID in the Merchants system	String up to 255 characters	+
order_amount	The amount of the transaction	Numbers in the format XXXX.XX	+
order_currency	Currency	Currency	+
order_description	Description of the transaction (product name)	String up to 1024 characters	+
callback_url	URL that Payment Platform sends the callback for this transaction to. Overrides the Notification URL configured in the admin panel, for this request only.	Valid URL, string up to 255 characters	-
req_token	Special attribute pointing for further tokenization	Y or N (default N)	-
card_token	Credit card token value	String 64 characters	-
recurring_init	Initialization of the transaction with possible following recurring. Once the transaction settles, a recurring_token is returned in the response and the callback.	Y or N (default N)	-
payer_present	Indicates that the payer initiated the payment: a Customer-Initiated Transaction (CIT) when Y, versus a Merchant-Initiated Transaction (MIT) when N.	Y or N (default Y)	-
term_url_3ds	URL to which Customer should be returned after 3D-Secure	String up to 1024 characters	+
card_number	Credit Card Number	Credit Card Number format	+ *
card_exp_month	Month of expiry of the credit card	Month in the form XX	+ *
card_exp_year	Year of expiry of the credit card	Year in the form XXXX	+ *
card_cvv2	CVV/CVC2 credit card verification code	3-4 symbols	+ *
payer_first_name	Customer’s name	String up to 32 characters	-
payer_last_name	Customer’s surname	String up to 32 characters	-
payer_middle_name	Customer’s middle name	String up to 32 characters	-
payer_birth_date	Customer’s birthday	format yyyy-MM-dd, e.g. 1970-02-17	-
payer_address	Customer’s address	String up to 255 characters	-
payer_address2	The adjoining road or locality (if required) of the сustomer’s address	String up to 255 characters	-
payer_country	Customer’s country	2-letter code	-
payer_state	Customer’s state	String up to 32 characters	-
payer_city	Customer’s city	String up to 40 characters	-
payer_zip	ZIP-code of the Customer	String up to 10 characters	-
payer_email	Customer’s email	String up to 255 characters	-
payer_phone	Customer’s phone	String up to 32 characters	-
payer_phone_country_code	Country calling code of the payer’s phone number	Digits, up to 10 characters. A hyphen is allowed for composite codes, for example 1-684	-
payer_ip	IP-address of the Customer Both versions, IPv4 and IPv6, can be used. If you are sending IPv6, make sure the payment provider that processes the payments supports it.	XXX.XXX.XXX.XXX	+
payer_language	Language of the platform-hosted pages shown to the Customer during the payment, such as the interaction template and the Thank You page. The value is case-insensitive and is not validated: a code that is not on the list falls back to English. If the parameter is omitted, the Checkout Default Language from the Protocol Mapping settings is used. If that is not set either, the language is taken from the Customer's browser.	One of: en, sp, ar, az, fr, nb, zh, zh-TW, kk, de, it, hr, cs, hu, pl, pt, ro, ja, nl, bg, ru	-
parameters	Object that contains extra parameters required by the acquirer	Format: parameters[param1]: value1 parameters[param2]: value2 parameters[paramN]: valueN See Appendix C for more details.	-
custom_data	Arbitrary merchant object stored with the transaction and returned in the callback notification.	Object	-
hash	Special signature to validate your request to Payment Platform	See Appendix A, Formula 1	+

*This field becomes optional if card_token or payment_token is specified

If the optional parameter card_token and card data are specified, card_token will be ignored.

If the optional parameters req_token and card_token are specified, req_token will be ignored.

Response Parameters

You will get JSON encoded string with transaction result. If your account supports 3D-Secure, transaction result will be sent to your Notification URL.

Synchronous mode

Successful response

Parameter	Description
action	DEBIT
result	SUCCESS
status	3DS / REDIRECT / SETTLED
order_id	Transaction ID in the Merchant’s system
trans_id	Transaction ID in Payment Platform
trans_date	Transaction date in Payment Platform
descriptor	Descriptor from the bank, the same as payer will see in the bank statement
amount	Order amount
currency	Currency
commission	Commission charged on top of the amount
total_amount	Amount plus commission

Unsuccessful response

Parameter	Description
action	DEBIT
result	DECLINED
status	DECLINED
order_id	Transaction ID in the Merchant’s system
trans_id	Transaction ID in Payment Platform
trans_date	Transaction date in Payment Platform
descriptor	Descriptor from the bank, the same as payer will see in the bank statement
amount	Order amount
currency	Currency
commission	Commission charged on top of the amount
total_amount	Amount plus commission
decline_reason	The reason why the transaction was declined

3D-Secure transaction response

Parameter	Description
action	DEBIT
result	REDIRECT
status	3DS / REDIRECT
order_id	Transaction ID in the Merchant’s system
trans_id	Transaction ID in Payment Platform
trans_date	Transaction date in Payment Platform
descriptor	Descriptor from the bank, the same as payer will see in the bank statement
amount	Order amount
currency	Currency
commission	Commission charged on top of the amount
total_amount	Amount plus commission
redirect_url	URL to which the Merchant should redirect the Customer
redirect_params	Object of specific 3DS parameters. It is array if redirect_params have no data. The availability of the redirect_params depends on the data transmitted by the acquirer. redirect_params may be missing. It usually happens when redirect_method = GET
redirect_method	The method of transferring parameters (POST / GET)

Undefined response

Parameter	Description
action	DEBIT
result	UNDEFINED
status	3DS / REDIRECT / PREPARE
order_id	Transaction ID in the Merchant’s system
trans_id	Transaction ID in Payment Platform
trans_date	Transaction date in Payment Platform
descriptor	Descriptor from the bank, the same as payer will see in the bank statement
amount	Order amount
currency	Currency
commission	Commission charged on top of the amount
total_amount	Amount plus commission

Callback parameters

Successful response

Parameter	Description
action	DEBIT
result	SUCCESS
status	REDIRECT / 3DS / SETTLED
order_id	Transaction ID in the Merchant’s system
trans_id	Transaction ID in Payment Platform
trans_date	Transaction date in Payment Platform
descriptor	Descriptor from the bank, the same as payer will see in the bank statement
amount	Order amount
currency	Currency
commission	Commission charged on top of the amount
total_amount	Amount plus commission
connector_name *	Connector's name (Payment Gateway)
rrn *	Retrieval Reference Number value from the acquirer system
approval_code *	Approval code value from the acquirer system
gateway_id *	Gateway ID – transaction identifier provided by payment gateway
extra_gateway_id *	Extra Gateway ID – additional transaction identifier provided by payment gateway
merchant_name *	Merchant Name
mid_name *	MID Name
issuer_country *	Issuer Country
issuer_bank *	Issuer Bank
merchant_key *	Merchant key (CLIENT_KEY) value
hash	Special signature, used to validate callback, see Appendix A, Formula 2

* The parameters are included if the appropriate setup is configured in the admin panel (see “Add Extended Data to Callback” block in the Configurations -> Protocol Mappings section).

Unsuccessful response

Parameter	Description
action	DEBIT
result	DECLINED
status	DECLINED
order_id	Transaction ID in the Merchant’s system
trans_id	Transaction ID in Payment Platform
trans_date	Transaction date in Payment Platform
descriptor	Descriptor from the bank, the same as payer will see in the bank statement
amount	Order amount
currency	Currency
commission	Commission charged on top of the amount
total_amount	Amount plus commission
decline_reason	Description of the cancellation of the transaction
hash	Special signature, used to validate callback, see Appendix A, Formula 2

3D-Secure transaction response

Parameter	Description
action	DEBIT
result	REDIRECT
status	3DS / REDIRECT
order_id	Transaction ID in the Merchant’s system
trans_id	Transaction ID in Payment Platform
hash	Special signature, used to validate callback, see Appendix A, Formula 2
trans_date	Transaction date in Payment Platform
descriptor	Descriptor from the bank, the same as payer will see in the bank statement
amount	Order amount
currency	Currency
commission	Commission charged on top of the amount
total_amount	Amount plus commission
redirect_url	URL to which the Merchant should redirect the Customer
redirect_params	Object with the parameters. It is array if redirect_params have no data. The availability of the redirect_params depends on the data transmitted by the acquirer. redirect_params may be missing. It usually happens when redirect_method = GET
redirect_method	The method of transferring parameters (POST or GET)

Undefined response

Parameter	Description
action	DEBIT
result	UNDEFINED
status	REDIRECT / 3DS / PREPARE
order_id	Transaction ID in the Merchant’s system
trans_id	Transaction ID in Payment Platform
trans_date	Transaction date in Payment Platform
descriptor	Descriptor from the bank, the same as payer will see in the bank statement
amount	Order amount
currency	Currency
commission	Commission charged on top of the amount
total_amount	Amount plus commission
hash	Special signature, used to validate callback, see Appendix A, Formula 2

CREDIT2CARD request

---

CREDIT2CARD protocol implements money transfers transactions between merchant's account and credit card (Card Credit or Account-to-Card payment) with using specific API.

If you want to send a payment for the specific sub-account (channel), you need to use channel_id that specified in your Payment Platform account settings.

This request is sent by POST in the background (e.g., through PHP CURL).

Request Parameters

Parameter	Description	Values	Required
action	Action type	CREDIT2CARD	+
client_key	Unique client key (CLIENT_KEY)		+
channel_id	Payment channel (Sub-account)	String up to 16 characters	-
order_id	Transaction ID in the Clients system	String up to 255 characters	+
order_amount	The amount of the transaction	Format depends on currency. Send Integer type value for currencies with zero-exponent. Example: 1000 Send Float type value for currencies with exponents 2, 3, 4. Format for 2-exponent currencies: XX.XX Example: 100.99 Pay attention that currencies 'UGX', 'JPY', 'KRW', 'CLP' must be send in the format XX.XX, with the zeros after comma. Example: 100.00 Format for 3-exponent currencies: XXX.XXX Example: 100.999. Format for 4-exponent currencies: XXX.XXXX Example: 100.9999	+
order_currency	Currency	3-letter code	+
order_description	Description of the transaction (product name)	String up to 1024 characters	+
callback_url	URL that Payment Platform sends the callback for this transaction to. Overrides the Notification URL configured in the admin panel, for this request only.	Valid URL, string up to 255 characters	-
return_url	If the optional parameter return_url is not provided in the request, the customer will be redirected to the default 'Thank You' page after the payment process. This page includes an option to send the receipt to the customer's email	Example: https://example.domain.com	-
card_number	Credit Card Number		+
payee_first_name	Payee’s name	String up to 32 characters	-
payee_last_name	Payee’s surname	String up to 32 characters	-
payee_middle_name	Payee’s middle name	String up to 32 characters	-
payee_birth_date	Payee’s birthday	format yyyy-MM-dd, e.g. 1970-02-17	-
payee_address	Payee’s address	String up to 255 characters	-
payee_address2	The adjoining road or locality (if required) of the сustomer’s address	String up to 255 characters	-
payee_country	Payee’s country	2-letter code	-
payee_state	Payee’s state	String up to 32 characters	-
payee_city	Payee’s city	String up to 32 characters	-
payee_zip	ZIP-code of the Payee	String up to 10 characters	-
payee_email	Payee’s email	String up to 255 characters	-
payee_phone	Payee’s phone	String up to 32 characters	-
payer_first_name	Payer’s name	String up to 32 characters	-
payer_last_name	Payer’s surname	String up to 32 characters	-
payer_middle_name	Payer’s middle name	String up to 32 characters	-
payer_birth_date	Payer’s birthday	format yyyy-MM-dd, e.g. 1970-02-17	-
payer_address	Payer’s address	String up to 255 characters	-
payer_address2	The adjoining road or locality (if required) of the payer’s address	String up to 255 characters	-
payer_house_number	Payer’s house or building number	String up to 9 characters	-
payer_country	Payer’s country	2-letter code	-
payer_state	Payer’s state	String up to 32 characters	-
payer_city	Payer’s city	String up to 40 characters	-
payer_district	Payer’s district of city	String up to 32 characters	-
payer_zip	ZIP-code of the Payer	String up to 10 characters	-
payer_email	Payer’s email	String up to 255 characters	-
payer_phone	Payer’s phone	String up to 32 characters	-
payer_phone_country_code	Country calling code of the payer’s phone number	Digits, up to 10 characters. A hyphen is allowed for composite codes, for example 1-684	-
payer_ip	IP-address of the Payer Both versions, IPv4 and IPv6, can be used. If you are sending IPv6, make sure the payment provider that processes the payments supports it.	XXX.XXX.XXX.XXX	-
parameters	Object that contains extra parameters required by the acquirer	Format: parameters[param1]: value1 parameters[param2]: value2 parameters[paramN]: valueN See Appendix C for more details.	-
custom_data	Arbitrary merchant object stored with the transaction and returned in the callback notification.	Object	-
hash	Special signature to validate your request to Payment Platform	see Appendix A, Formula 5	+

Example Request

curl -d "action=CREDIT2CARD&client_key=c2b8fb04-110f-11ea-bcd3-0242c0a85004&
 channel_id=test&order_id=123456789&order_amount=1.03&order_currency=USD&
 order_description=wine&card_number=4917111111111111&
 hash=a1a6de416405ada72bb47a49176471dc"[https://test.apiurl.com](https://test.apiurl.com/) -k

Response Parameters

You will get JSON encoded string with transaction result.

Successful response

Parameter	Description
action	CREDIT2CARD
result	SUCCESS
status	SETTLED
order_id	Transaction ID in the Client's system
trans_id	Transaction ID in Payment Platform
trans_date	Transaction date in Payment Platform
descriptor	This is a string which the owner of the credit card will see in the statement from the bank. In most cases, this is the Customers support web-site.

Response Example (Successful result)

{
 "action": "CREDIT2CARD",
 "result": "SUCCESS",
 "status": "SETTLED",
 "order_id": "1613117050",
 "trans_id": "e5098d62-6d08-11eb-9da3-0242ac120013",
 "trans_date": "2021-02-12 08:04:15"
 }

Unsuccessful response

Parameter	Description
action	CREDIT2CARD
result	DECLINED
status	DECLINED
order_id	Transaction ID in the Client's system
trans_id	Transaction ID in Payment Platform
trans_date	Transaction date in Payment Platform
decline_reason	The reason why the transaction was declined

Response Example (Unsuccessful result)

{
 "action": "CREDIT2CARD",
 "result": "DECLINED",
 "status": "DECLINED",
 "order_id": "1613117050",
 "trans_id": "e5098d62-6d08-11eb-9da3-0242ac120013",
 "trans_date": "2021-02-12 08:04:15",
 "decline_reason": "Declined by processing"
 }

Undefined response

Parameter	Description
action	CREDIT2CARD
result	UNDEFINED
status	PREPARE
order_id	Transaction ID in the Client's system
trans_id	Transaction ID in Payment Platform
trans_date	Transaction date in Payment Platform
descriptor	This is a string which the owner of the credit card will see in the statement from the bank. In most cases, this is the Customers support web-site.

Response Example (Undefined result)

{
 "action": "CREDIT2CARD",
 "result": "UNDEFINED",
 "status": "PREPARE",
 "order_id": "1613117050",
 "trans_id": "e5098d62-6d08-11eb-9da3-0242ac120013",
 "trans_date": "2021-02-12 08:04:15",
 "descriptor": "Some data"
 }

Callback parameters

Successful response

Parameter	Description
action	CREDIT2CARD
result	SUCCESS
status	SETTLED
order_id	Transaction ID in the Client's system
trans_id	Transaction ID in Payment Platform
trans_date	Date of CREDIT2CARD action
connector_name *	Connector's name (Payment Gateway)
rrn *	Retrieval Reference Number value from the acquirer system
approval_code *	Approval code value from the acquirer system
gateway_id *	Gateway ID – transaction identifier provided by payment gateway
extra_gateway_id *	Extra Gateway ID – additional transaction identifier provided by payment gateway
merchant_name *	Merchant Name
mid_name *	MID Name
issuer_country *	Issuer Country
issuer_bank *	Issuer Bank
merchant_key *	Merchant key (CLIENT_KEY) value
hash	Special signature to validate callback. See Appendix A, Formula 6

* The parameters are included if the appropriate setup is configured in the admin panel (see “Add Extended Data to Callback” block in the Configurations -> Protocol Mappings section).

Callback Example (Successful result)

action=CREDIT2CARD&result=SUCCESS&status=SETTLED&order_id=123456789&trans_id=1d152122-6c86-11eb-8a49-0242ac120013&hash=84dc0713fa38f18edb85da7aa94eca2e&trans_date=2021-02-11+16%3A28%3A04

Unsuccessful response

Parameter	Description
action	CREDIT2CARD
result	DECLINED
status	DECLINED
order_id	Transaction ID in the Client's system
trans_id	Transaction ID in Payment Platform
trans_date	Date of CREDIT2CARD action
decline_reason	Reason of transaction decline.It shows for the transactions with the "DECLINED" status
hash	Special signature to validate callback. See Appendix A, Formula 6

Callback Example (Unsuccessful result)

action=CREDIT2CARD&result=DECLINED&status=DECLINED&order_id=123456789&trans_id=1d152122-6c86-11eb-8a49-0242ac120013&decline_reason=reason&hash=84dc0713fa38f18edb85da7aa94eca2e&trans_date=2021-02-11+16%3A28%3A04

Undefined response

Parameter	Description
action	CREDIT2CARD
result	UNDEFINED
status	PREPARE
order_id	Transaction ID in the Client's system
trans_id	Transaction ID in Payment Platform
trans_date	Date of CREDIT2CARD action
hash	Special signature to validate callback. See Appendix A, Formula 6

Callback Example (Undefined result)

action=CREDIT2CARD&result=UNDEFINED&status=PREPARE&order_id=123456789&trans_id=1d152122-6c86-11eb-8a49-0242ac120013&hash=84dc0713fa38f18edb85da7aa94eca2e&trans_date=2021-02-11+16%3A28%3A04

CARD2CARD request

---

Use CARD2CARD action to create transfer transaction.

If the response returns result = REDIRECT, you must redirect the payer to the provided URL. See Redirect / 3DS handling for the full redirect flow.

Request parameters

Parameter	Description	Values	Required field
action	Action that you want to perform. Fixed value.	CARD2CARD	+
client_key	Unique key (CLIENT_KEY)	UUID format value	+
channel_id	Payment channel (Sub-account)	String up to 16 characters	-
order_id	Transaction ID in the Merchants system	String up to 255 characters	+
order_amount	The amount of the transaction	Numbers in the format: XXXX.XX	+
order_currency	Currency	3-letter code	+
order_description	Description of the transaction (product name)	String up to 1024 characters	+
callback_url	URL that Payment Platform sends the callback for this transaction to. Overrides the Notification URL configured in the admin panel, for this request only.	Valid URL, string up to 255 characters	-
payer_card_number	Payer credit Card Number		+
payer_card_exp_month	Month of expiry of the Payer credit card	Month in the form XX	+
payer_card_exp_year	Year of expiry of the Payer credit card	Year in the form XXXX	+
payer_card_cvv2	CVV/CVC2 for Payer credit card verification code	3-4 symbols	+
payer_first_name	Payer’s name	String up to 32 characters	-
payer_last_name	Payer’s surname	String up to 32 characters	-
payer_middle_name	Payer’s middle name	String up to 32 characters	-
payer_birth_date	Payer’s birthday	format yyyy-MM-dd, e.g. 1970-02-17	-
payer_address	Payer’s address	String up to 255 characters	-
payer_address2	The adjoining road or locality (if required) of the Payer’s address	String up to 255 characters	-
payer_country	Payer’s country	2-letter code	-
payer_state	Payer’s state	String up to 32 characters	-
payer_city	Payer’s city	String up to 40 characters	-
payer_zip	ZIP-code of the Customer	String up to 10 characters	-
payer_email	Customer’s email	String up to 255 characters	-
payer_phone	Customer’s phone	String up to 32 characters	-
payer_phone_country_code	Country calling code of the payer’s phone number	Digits, up to 10 characters. A hyphen is allowed for composite codes, for example 1-684	-
payer_ip	IP-address of the Customer Both versions, IPv4 and IPv6, can be used. If you are sending IPv6, make sure the payment provider that processes the payments supports it.	XXX.XXX.XXX.XXX	+
payer_language	Language of the platform-hosted pages shown to the Customer during the payment, such as the interaction template and the Thank You page. The value is case-insensitive and is not validated: a code that is not on the list falls back to English. If the parameter is omitted, the Checkout Default Language from the Protocol Mapping settings is used. If that is not set either, the language is taken from the Customer's browser.	One of: en, sp, ar, az, fr, nb, zh, zh-TW, kk, de, it, hr, cs, hu, pl, pt, ro, ja, nl, bg, ru	-
payee_card_number	Payee's credit card Number		+
payee_first_name	Payee’s name	String up to 32 characters	-
payee_last_name	Payee’s surname	String up to 32 characters	-
payee_middle_name	Payee’s middle name	String up to 32 characters	-
payee_birth_date	Payee’s birthday	format yyyy-MM-dd, e.g. 1970-02-17	-
payee_address	Payee’s address	String up to 255 characters	-
payee_address2	The adjoining road or locality (if required) of the сustomer’s address	String up to 255 characters	-
payee_country	Payee’s country	2-letter code	-
payee_state	Payee’s state	String up to 32 characters	-
payee_city	Payee’s city	String up to 32 characters	-
payee_zip	ZIP-code of the Payee	String up to 10 characters	-
payee_email	Payee’s email	String up to 255 characters	-
payee_phone	Payee’s phone	String up to 32 characters	-
term_url_3ds	URL to which Customer should be returned after 3D-Secure	String up to 1024 characters	+
parameters	Object that contains extra parameters required by the acquirer	Format: parameters[param1]: value1 parameters[param2]: value2 parameters[paramN]: valueN See Appendix C for more details.	-
hash	Special signature to validate your request to Payment Platform	See Appendix A, Formula 1	+

Response parameters

You will get JSON encoded string with transaction result. If your account supports 3D-Secure, transaction result will be sent to your Notification URL.

Synchronous mode

Successful response

Parameter	Description
action	CARD2CARD
result	SUCCESS
status	SETTLED
order_id	Transaction ID in the Merchant’s system
trans_id	Transaction ID in Payment Platform
trans_date	Transaction date in Payment Platform
descriptor	Descriptor from the bank, the same as payer will see in the bank statement
amount	Order amount
currency	Currency

Unsuccessful response

Parameter	Description
action	CARD2CARD
result	DECLINED
status	DECLINED
order_id	Transaction ID in the Merchant’s system
trans_id	Transaction ID in Payment Platform
trans_date	Transaction date in Payment Platform
descriptor	Descriptor from the bank, the same as payer will see in the bank statement
amount	Order amount
currency	Currency
decline_reason	The reason why the transaction was declined

3D-Secure transaction response

Parameter	Description
action	CARD2CARD
amount	Order amount
currency	Currency
descriptor	Descriptor from the bank, the same as payer will see in the bank statement
order_id	Transaction ID in the Merchant’s system
redirect_method	The method of transferring parameters (POST or GET)
redirect_params	Object of specific 3DS parameters. It is array if redirect_params have no data. The availability of the redirect_params depends on the data transmitted by the acquirer. redirect_params may be missing. It usually happens when redirect_method = GET
redirect_url	URL to which the Merchant should redirect the Customer
result	REDIRECT
status	3DS / REDIRECT
trans_date	Transaction date in Payment Platform
trans_id	Transaction ID in Payment Platform

Undefined response

Parameter	Description
action	CARD2CARD
result	UNDEFINED
status	3DS / REDIRECT / PREPARE
order_id	Transaction ID in the Merchant’s system
trans_id	Transaction ID in Payment Platform
trans_date	Transaction date in Payment Platform
descriptor	Descriptor from the bank, the same as payer will see in the bank statement
amount	Order amount
currency	Currency

Callback parameters

Successful response

Parameter	Description
action	CARD2CARD
result	SUCCESS
status	3DS / SETTLED
order_id	Transaction ID in the Merchant’s system
trans_id	Transaction ID in Payment Platform
trans_date	Transaction date in Payment Platform
descriptor	Descriptor from the bank, the same as payer will see in the bank statement
amount	Order amount
currency	Currency
connector_name *	Connector's name (Payment Gateway)
rrn *	Retrieval Reference Number value from the acquirer system
approval_code *	Approval code value from the acquirer system
gateway_id *	Gateway ID – transaction identifier provided by payment gateway
extra_gateway_id *	Extra Gateway ID – additional transaction identifier provided by payment gateway
merchant_name *	Merchant Name
mid_name *	MID Name
issuer_country *	Issuer Country
issuer_bank *	Issuer Bank
merchant_key *	Merchant key (CLIENT_KEY) value
hash	Special signature, used to validate callback, see Appendix A, Formula 2

* The parameters are included if the appropriate setup is configured in the admin panel (see “Add Extended Data to Callback” block in the Configurations -> Protocol Mappings section).

Unsuccessful response

Parameter	Description
action	CARD2CARD
result	DECLINED
status	DECLINED
order_id	Transaction ID in the Merchant’s system
trans_id	Transaction ID in Payment Platform
trans_date	Transaction date in Payment Platform
decline_reason	Description of the cancellation of the transaction
hash	Special signature, used to validate callback, see Appendix A, Formula 2

3D-Secure transaction response

Parameter	Description
action	CARD2CARD
result	REDIRECT
status	3DS / REDIRECT
order_id	Transaction ID in the Merchant’s system
trans_id	Transaction ID in Payment Platform
hash	Special signature, used to validate callback, see Appendix A, Formula 2
trans_date	Transaction date in Payment Platform
descriptor	Descriptor from the bank, the same as payer will see in the bank statement
amount	Order amount
currency	Currency
redirect_url	URL to which the Merchant should redirect the Customer
redirect_params	Object with the parameters. It is array if redirect_params have no data. The availability of the redirect_params depends on the data transmitted by the acquirer. redirect_params may be missing. It usually happens when redirect_method = GET
redirect_method	The method of transferring parameters (POST or GET)

Undefined response

Parameter	Description
action	CARD2CARD
result	UNDEFINED
status	3DS / REDIRECT / PREPARE
order_id	Transaction ID in the Merchant’s system
trans_id	Transaction ID in Payment Platform
hash	Special signature, used to validate callback, see Appendix A, Formula 2
trans_date	Transaction date in Payment Platform
descriptor	Descriptor from the bank, the same as payer will see in the bank statement
amount	Order amount
currency	Currency

GET_TRANS_STATUS request

---

Gets order status from Payment Platform. This request is sent by POST in the background (e.g. through PHP CURL).

⚠️ Pay attention

When using cascading (a functionality that allows attempting to process a payment through multiple MIDs until success is achieved), a unique order_id should be used for each payment, and the final status should primarily rely on the callback.

In the process of cascading within a single payment request with a specific order_id, multiple payments may be initiated. When attempting to check the status by order_id using the GET_TRANS_STATUS_BY_ORDER request, different statuses and trans_ids may be returned in the response, as cascading could still be in progress. Using GET_TRANS_STATUS with trans_id provides the status of only a specific payment within the cascading sequence.

Note: The response logic for a status request depends on the Cascading Context for Get Status setting in Configuration --> Protocol Mappings section. If enabled, the system returns the status of the most recently created payment within the cascade (i.e., the payment with the latest creation date), rather than the payment specified in the request.

To obtain the final status, it is recommended to:

1. In the protocol mapping section, ensure the option ‘Cascading Context for Get Status’ is enabled. When enabled, a GET_TRANS_STATUS request with trans_id will return the status of the last cascaded payment.
   
2. Rely on the callback, as we send callbacks with the final status for the last payment in the cascading process.

Please note, in 3DS and REDIRECT callbacks, you may receive one trans_id, while in the final status callback, you might see a different trans_id, as the trans_id reflects the status at a specific stage within the cascading process.

Request parameters

Parameter	Description	Values	Required field
action	GET_TRANS_STATUS	GET_TRANS_STATUS	+
client_key	Unique key (client_key)	UUID format value	+
trans_id	Transaction ID in Payment Platform	UUID format value	+
hash	Special signature to validate your request to Payment Platform	CREDIT2CARD - see Appendix A, Formula 6 Others - see Appendix A, Formula 2	+

Response parameters

Parameter	Description
action	GET_TRANS_STATUS
result	SUCCESS
status	3DS / REDIRECT / PENDING / PREPARE / DECLINED / SETTLED / REVERSAL / REFUND / VOID /CHARGEBACK
order_id	Transaction ID in the Merchant`s system
trans_id	Transaction ID in Payment Platform
decline_reason	Reason of transaction decline. It shows for the transactions with the DECLINED status
recurring_token	Token for recurring. It shows when the next conditions are met for the SALE transaction: - transaction is successful - SALE request contained recurring_init parameter with the value 'Y'
schedule_id	Schedule ID for recurring payments
schedule_start_date	Date of the first scheduled payment. It is available if schedule_start_date was sent in the initiating request. Format: YYYY-MM-DD HH:MM:SS
payment_schedule_amount	Amount of the payments created later by the schedule. It is available if payment_schedule_amount was sent in the initiating request
next_payment_date_by_schedule	Date and time of the next charge by the schedule. Returned when enabled in Protocol Mappings. Format: YYYY-MM-DD HH:MM:SS
current_payment_sequence_by_schedule	Sequence number of the current payment within the schedule. Returned when enabled in Protocol Mappings
card_token	Credit card token value
card *	Card mask, e.g. 411111****1111. Returned in the get-status response exactly as in the callback.
card_expiration_date *	Card expiration date, e.g. 01/2038.
digital_wallet	Wallet provider: googlepay, applepay
arn *	Acquirer Reference Number value from the acquirer system
merchant_key *	Merchant key (CLIENT_KEY) value
initiator *	Initiator of the payment: Customer or Merchant.
sequence *	Payment type in the token lifecycle: One-off, Initial, or Subsequent.
source *	Source of the card data: Card, Network Token, Card On File, Internal Token, or Recurring Token.
payer fields *	The full payer set is configurable in Protocol Mapping and returned when selected: payer_first_name, payer_last_name, payer_birth_date, payer_address, payer_address2, payer_house_number, payer_phone_country_code, payer_country, payer_state, payer_city, payer_district, payer_zip, payer_email, payer_phone, payer_ip.

* The parameters are included if the appropriate setup is configured in the admin panel (see “Add Data to” block in the Configurations -> Protocol Mappings section). The set of parameters returned in the get-status response is configurable via Protocol Mapping. The initiator / sequence / source Card-On-File attributes are populated automatically for MIDs with card_on_file_support enabled. initiator mirrors the payer_present value (Customer for CIT, Merchant for MIT); sequence reflects the token lifecycle (Initial on the transaction that creates the token, Subsequent on payments that reuse it, One-off when no token is involved); source reports where the card data came from.

Response Example

{
    "action": "GET_TRANS_STATUS",
    "result": "SUCCESS",
    "status": "SETTLED",
    "order_id": "1646655381neural",
    "trans_id": "66624eba-9e10-11ec-aa41-0242ac130002",
    "digital_wallet": "googlepay"
}

GET_TRANS_DETAILS request

---

Gets all history of transactions by the order. This request is sent by POST in the background (e.g. through PHP CURL).

⚠️ Pay attention

For additional information on working with cascading, please refer to the GET_TRANS_STATUS request section

Request parameters

Parameter	Description	Values	Required field
action	GET_TRANS_DETAILS	GET_TRANS_DETAILS	+
client_key	Unique key (client_key)	UUID format value	+
trans_id	Transaction ID in Payment Platform	UUID format value	+
hash	Special signature to validate your request to Payment Platform	CREDIT2CARD - see Appendix A, Formula 6 Others - see Appendix A, Formula 2	+

Response parameters

Parameter	Description
action	GET_TRANS_DETAILS
result	SUCCESS
status	3DS / REDIRECT / PENDING / PREPARE / DECLINED / SETTLED / REVERSAL / REFUND / VOID / CHARGEBACK
order_id	Transaction ID in the Merchant`s system
trans_id	Transaction ID in Payment Platform
name	Payer name
mail	Payer mail
ip	Payer IP
amount	Order amount
currency	Currency
card	Card in the format XXXXXX****XXXX. If a digital wallet was used, the value obtained when decrypting the wallet token will be provided in this parameter
decline_reason	Reason of transaction decline.It shows for the transactions with the DECLINED status
recurring_token	Token for recurring. It shows when the next conditions are met for the SALE transaction: - transaction is successful - SALE request contained recurring_init parameter with the value 'Y' - SALE request contained card data which was used for the first time
schedule_id	Schedule ID for recurring payments
schedule_start_date	Date of the first scheduled payment. It is available if schedule_start_date was sent in the initiating request. Format: YYYY-MM-DD HH:MM:SS
payment_schedule_amount	Amount of the payments created later by the schedule. It is available if payment_schedule_amount was sent in the initiating request
next_payment_date_by_schedule	Date and time of the next charge by the schedule. Returned when enabled in Protocol Mappings. Format: YYYY-MM-DD HH:MM:SS
current_payment_sequence_by_schedule	Sequence number of the current payment within the schedule. Returned when enabled in Protocol Mappings
card_token	Credit card token value
card_expiration_date *	Card expiration date, e.g. 01/2038.
transactions	Array of transactions with the parameters: - date - type (sale, 3ds, auth, capture, credit, chargeback, reversal, refund) - status (success, waiting, fail) - amount
digital_wallet	Wallet provider: googlepay, applepay
pan_type	It refers to digital payments, such as Apple Pay and Google Pay, and the card numbers returned as a result of payment token decryption: DPAN (Digital Primary Account Number) and FPAN (Funding Primary Account Number).
arn *	Acquirer Reference Number value from the acquirer system
payer fields *	The full payer set is configurable in Protocol Mapping and returned when selected: payer_first_name, payer_last_name, payer_birth_date, payer_address, payer_address2, payer_house_number, payer_phone_country_code, payer_country, payer_state, payer_city, payer_district, payer_zip, payer_email, payer_phone, payer_ip.
merchant_key *	Merchant key (CLIENT_KEY) value
initiator *	Initiator of the payment: Customer or Merchant.
sequence *	Payment type in the token lifecycle: One-off, Initial, or Subsequent.
source *	Source of the card data: Card, Network Token, Card On File, Internal Token, or Recurring Token.

* The parameters are included if the appropriate setup is configured in the admin panel (see “Add Data to” block in the Configurations -> Protocol Mappings section). The set of parameters returned in the get-status response is configurable via Protocol Mapping. The initiator / sequence / source Card-On-File attributes are populated automatically for MIDs with card_on_file_support enabled. initiator mirrors the payer_present value (Customer for CIT, Merchant for MIT); sequence reflects the token lifecycle (Initial on the transaction that creates the token, Subsequent on payments that reuse it, One-off when no token is involved); source reports where the card data came from.

Response Example

{
    "action": "GET_TRANS_DETAILS",
    "result": "SUCCESS",
    "status": "SETTLED",
    "order_id": "1646655381neural",
    "trans_id": "66624eba-9e10-11ec-aa41-0242ac130002",
    "name": "John Rikher",
    "mail": "[email protected]",
    "ip": "192.169.217.106",
    "amount": "0.02",
    "currency": "USD",
    "digital_wallet": "googlepay",
    "card": "522864******0691",
    "pan_type": "dpan",
    "transactions": [
        {
            "type": "3DS",
            "status": "success",
            "date": "2022-03-07 12:16:23",
            "amount": "0.02"
        },
        {
            "type": "SALE",
            "status": "success",
            "date": "2022-03-07 12:16:31",
            "amount": "0.02"
        }
    ]
}

GET_TRANS_STATUS_BY_ORDER request

---

Gets the status of the most recent transaction in the order's transaction subsequence from Payment Platform. This request is sent by POST in the background (e.g. through PHP CURL).

It is recommended to pass an unique order_id in the payment request. That way, it will be easier to uniquely identify the payment by order_id. This is especially important if cascading is configured. In this case, several intermediate transactions could be created within one payment.

⚠️ Pay attention

For additional information on working with cascading, please refer to the GET_TRANS_STATUS request section

Request parameters

Parameter	Description	Values	Required field
action	GET_TRANS_STATUS_BY_ORDER	GET_TRANS_STATUS_BY_ORDER	+
client_key	Unique key (client_key)	UUID format value	+
order_id	Transaction ID in the Merchants system	String up to 255 characters	+
hash	Special signature to validate your request to Payment Platform	see Appendix A, Formula 7 On a transaction with no payer email, for example a CREDIT2CARD payout, omit the reversed email term	+

Response parameters

Parameter	Description
action	GET_TRANS_STATUS_BY_ORDER
result	SUCCESS
status	3DS / REDIRECT / PENDING / PREPARE / DECLINED / SETTLED / REVERSAL / REFUND / VOID / CHARGEBACK
order_id	Transaction ID in the Merchant`s system
trans_id	Transaction ID in Payment Platform
decline_reason	Reason of transaction decline. It shows for the transactions with the DECLINED status
recurring_token	Token for recurring. It shows when the next conditions are met for the SALE transaction: - transaction is successful - SALE request contained recurring_init parameter with the value 'Y'
schedule_id	Schedule ID for recurring payments
schedule_start_date	Date of the first scheduled payment. It is available if schedule_start_date was sent in the initiating request. Format: YYYY-MM-DD HH:MM:SS
payment_schedule_amount	Amount of the payments created later by the schedule. It is available if payment_schedule_amount was sent in the initiating request
next_payment_date_by_schedule	Date and time of the next charge by the schedule. Returned when enabled in Protocol Mappings. Format: YYYY-MM-DD HH:MM:SS
current_payment_sequence_by_schedule	Sequence number of the current payment within the schedule. Returned when enabled in Protocol Mappings
card_token	Credit card token value
digital_wallet	Wallet provider: googlepay, applepay
card *	Card mask, e.g. 411111****1111.
card_expiration_date *	Card expiration date, e.g. 01/2038.
arn *	Acquirer Reference Number value from the acquirer system.
initiator *	Card-On-File initiator: Customer or Merchant.
sequence *	Card-On-File sequence: One-off, Initial, or Subsequent.
source *	Card-On-File source: Card, Network Token, Card On File, Internal Token, or Recurring Token.
payer fields *	The full payer set is configurable in Protocol Mapping and returned when selected: payer_first_name, payer_last_name, payer_birth_date, payer_address, payer_address2, payer_house_number, payer_phone_country_code, payer_country, payer_state, payer_city, payer_district, payer_zip, payer_email, payer_phone, payer_ip.

* Included when configured in the admin panel (Add Data to block in Configurations → Protocol Mappings). The set of parameters returned in the get-status response is configurable via Protocol Mapping.

Response Example

{
    "action": "GET_TRANS_STATUS_BY_ORDER",
    "result": "SUCCESS",
    "status": "SETTLED",
    "order_id": "1646655381neural",
    "trans_id": "66624eba-9e10-11ec-aa41-0242ac130002",
    "digital_wallet": "googlepay"
}

RECURRING_SALE request

---

Recurring payments are commonly used to create new transactions based on already stored cardholder information from previous operations.

RECURRING_SALE request has same logic as SALE request, the only difference is that you need to provide primary transaction id, and this request will create a secondary transaction with previously used cardholder data from primary transaction.

This request is sent by POST in the background (e.g. through PHP CURL).

Request parameters

Parameter	Description	Values	Required field
action	Recurring sale	RECURRING_SALE	+
client_key	Unique key (CLIENT_KEY)	UUID format value	+
order_id	Transaction ID in the Merchant's system	String up to 255 characters	+
order_amount	The amount of the transaction	Format depends on currency. Send Integer type value for currencies with zero-exponent. Example: 1000 Send Float type value for currencies with exponents 2, 3, 4. Format for 2-exponent currencies: XX.XX Example: 100.99 Pay attention that currencies 'UGX', 'JPY', 'KRW', 'CLP' must be send in the format XX.XX, with the zeros after comma. Example: 100.00 Format for 3-exponent currencies: XXX.XXX Example: 100.999. Format for 4-exponent currencies: XXX.XXXX Example: 100.9999	+
order_description	Transaction description (product name)	String up to 1024 characters	+
callback_url	URL that Payment Platform sends the callback for this transaction to. Overrides the Notification URL configured in the admin panel, for this request only.	Valid URL, string up to 255 characters	-
recurring_first_trans_id	Transaction ID of the primary transaction in Payment Platform	UUID format value	+
recurring_token	Value obtained during the primary transaction	UUID format value	+
schedule_id	Schedule ID for recurring payments	String	-
auth	Indicates that transaction must be only authenticated, but not captured	Y or N (default N)	-
custom_data	Array with the custom data This block duplicates the arbitrary parameters (overrides custom_data from initial SALE request) that were passed in the payment request	Format: custom_data [param1]: value1 custom_data [param2]: value2 custom_data [paramN]: valueN	-
hash	Special signature to validate your request to Payment Platform	see Appendix A, Formula 1	+

Response parameters

Response from Payment Platform is the same as by SALE command, except for the value of the difference parameter
action = RECURRING_SALE. You will receive a JSON encoded string with the result of the transaction.

RECURRING_DEBIT request

---

RECURRING_DEBIT creates a secondary debit using the token from a primary DEBIT transaction that was initialized with recurring_init = Y. It mirrors RECURRING_SALE, but for the debit flow.

To initialize the chain, send a DEBIT request with recurring_init = Y. On a successful settlement, the response and callback return a recurring_token. Use that token, together with the primary transaction ID, in the RECURRING_DEBIT request.

This request is sent by POST in the background (e.g. through PHP CURL).

Request parameters

Parameter	Description	Values	Required field
action	Recurring debit	RECURRING_DEBIT	+
client_key	Unique key (CLIENT_KEY)	UUID format value	+
order_id	Transaction ID in the Merchant's system	String up to 255 characters	+
order_amount	The amount of the transaction	Format depends on currency. See the SALE request for the per-currency format rules.	+
order_description	Description of the transaction (product name)	String up to 1024 characters	+
callback_url	URL that Payment Platform sends the callback for this transaction to. Overrides the Notification URL configured in the admin panel, for this request only.	Valid URL, string up to 255 characters	-
recurring_first_trans_id	Transaction ID of the primary DEBIT transaction in Payment Platform	UUID format value	+
recurring_token	Value obtained from the primary DEBIT transaction	UUID format value	+
schedule_id	Schedule ID for recurring payments. Schedules are not separated by operation type and apply to DEBIT as well as SALE.	UUID format value	-
custom_data	Arbitrary merchant object stored with the transaction and returned in the callback notification.	Object	-
hash	Special signature to validate your request to Payment Platform	see Appendix A, Formula 1	+

Response parameters

Response from Payment Platform is the same as by SALE command, except for the value of the parameter action = RECURRING_DEBIT. You will receive a JSON encoded string with the result of the transaction.

Schedules apply to debits

Schedules (CREATE_SCHEDULE, UPDATE_SCHEDULE, PAUSE_SCHEDULE, RUN_SCHEDULE, DELETE_SCHEDULE, SCHEDULE_INFO, DESCHEDULE) now apply to DEBIT as well as SALE. Schedules are not separated by operation type; a schedule_id can drive recurring debits the same way it drives recurring sales.

RETRY request

---

RETRY request is used to retry funds charging for secondary recurring payments in case of soft decline.

This action creates RETRY transaction and can causes payment final status changing.

This request is sent by POST in the background (e.g. through PHP CURL).

Request parameters

Parameter	Description	Values	Required field
action	RETRY	RETRY	+
client_key	Unique key (client_key)	UUID format value	+
trans_id	Transaction ID of the softly declined recurring transaction which will be retried.	UUID format value	+
hash	Special signature to validate your request to Payment Platform	see Appendix A, Formula 2	+

Response parameters

Synchronous mode

Parameter	Description
action	RETRY
result	ACCEPTED
order_id	Transaction ID in the Merchant's system
trans_id	Transaction ID in Payment Platform

Callback parameters

Successful response

Parameter	Description
action	RETRY
result	SUCCESS
status	SETTLED
order_id	Transaction ID in the Merchant's system
trans_id	Transaction ID in Payment Platform
amount	Amount
currency	Currency
hash	Special signature, used to validate callback, see Appendix A, Formula 2

Unsuccessful response

Parameter	Description
action	RETRY
result	DECLINED
status	DECLINED
order_id	Transaction ID in the Merchant's system
trans_id	Transaction ID in Payment Platform
amount	Amount
currency	Currency
decline_reason	Description of the cancellation of the transaction
hash	Special signature, used to validate callback, see Appendix A, Formula 2

CHARGEBACK notification parameters

---

CHARGEBACK transactions are used to dispute already settled payment.

When processing these transactions Payment Platform sends notification to Merchant`s Notification URL.

Parameter	Description
action	CHARGEBACK
result	SUCCESS
status	CHARGEBACK
order_id	Transaction ID in the Merchant`s system
trans_id	Transaction ID in Payment Platform
amount	The amount of the chargeback
chargeback_date	System date of the chargeback
bank_date	Bank date of the chargeback
reason_code	Reason code of the chargeback
connector_name *	Connector's name (Payment Gateway)
rrn *	Retrieval Reference Number value from the acquirer system
approval_code *	Approval code value from the acquirer system
gateway_id *	Gateway ID – transaction identifier provided by payment gateway
extra_gateway_id *	Extra Gateway ID – additional transaction identifier provided by payment gateway
merchant_name *	Merchant Name
mid_name *	MID Name
issuer_country *	Issuer Country
issuer_bank *	Issuer Bank
merchant_key *	Merchant key (CLIENT_KEY) value
hash	Special signature to validate callback, see Appendix A, Formula 2

* The parameters are included if the appropriate setup is configured in the admin panel (see “Add Extended Data to Callback” block in the Configurations -> Protocol Mappings section).

Recurring schedule operations

---

Protocol implements schedules for recurring payments with specific API interaction using. Schedules allow you to charge a customer on a recurring basis.

To work with the schedules you must send the server to server HTTPS request to Payment Platform URL (PAYMENT_URL) with the fields listed in "Recurring schedule actions" section. In the response Payment Platform will return the JSON (http://json.org/) encoded string.

CREATE_SCHEDULE request

To create a new schedule you need to send the request with the parameters listed below. This request is sent by POST in the background (e.g., through PHP CURL).

Request parameters

Parameter	Description	Values	Required field
action	Action to create a new schedule - fixed value	CREATE_SCHEDULE	+
client_key	Unique key (CLIENT_KEY)	UUID format value	+
name	Name of schedule	String up to 100 characters	+
interval_length	Interval length - how often the payments occurs. Cannot be set "0". For example, to set a schedule for payments every 15 days, you need to set: interval_length = 15, interval_unit = day	Number from 1 to 99	+
interval_unit	Interval unit	Possible values are "day" and "month"	+
day_of_month	Day of month when payment has to occur. Available only if interval_unit = month. Possible values: from 1 to 31. If day_of_month = 29, 30, or 31 and there are no days 29, 30, or 31 in the month, then the last day of the month is used. If day_of_month is not defined, then payment occurs on the day the initiating payment is created	Number from 1 to 31	-
payments_count	Payments count in schedule	Number from 1 to 99	+
delays	Deprecated. Do not use delays in your requests as it will result in an error. Use delayed_first_payment instead	Number	-
delayed_first_payment	Defines whether and how the first scheduled payment is delayed, for example for a trial period. Every following payment is counted from the first one. none - no delay, the payment cycle starts according to the schedule interval. delay_delay_by_interval - delay by a custom interval length and unit, independent of the schedule interval. day_of_week - delay until the next specified day of the week. day_of_month - delay until the specified day of the current or next month.	none, delay_delay_by_interval, day_of_week, day_of_month (default none)	-
first_payment_interval_length	Length of the delay interval before the first scheduled payment. Required if delayed_first_payment = delay_delay_by_interval	Number from 1 to 99	-
first_payment_interval_unit	Unit of the delay interval before the first scheduled payment. Required if delayed_first_payment = delay_delay_by_interval	Possible values are "day" and "month"	-
first_payment_day_of_week	Day of the week on which the first scheduled payment occurs. The platform picks the next occurrence of that day after the initiating payment: if the initiating payment falls on that weekday, the first scheduled payment moves to the following week. Required if delayed_first_payment = day_of_week	Number from 1 to 7, where 1 is Monday and 7 is Sunday	-
first_payment_day_of_month	Day of the month on which the first scheduled payment occurs. If the month has no such day, the last day of the month is used. Required if delayed_first_payment = day_of_month	Number from 1 to 31	-
hash	Special signature to validate your request to Payment Platform	see Appendix A, Formula 3	+

Response parameters

You will get JSON encoded string with the request result

Parameter	Description
action	CREATE_SCHEDULE
result	SUCCESS
schedule_id	Schedule ID in Payment Platform

UPDATE_SCHEDULE request

To update an existing schedule you need to send the request with the parameters listed below. Only the parameters sent in the request are updated, so you can omit the ones you do not want to change. This request is sent by POST in the background (e.g., through PHP CURL).

Request parameters

Parameter	Description	Values	Required field
action	Action to update an existing schedule - fixed value	UPDATE_SCHEDULE	+
client_key	Unique key (CLIENT_KEY)	UUID format value	+
schedule_id	Schedule ID in Payment Platform	UUID format value	+
name	Name of schedule	String up to 100 characters	-
interval_length	Interval length - how often the payments occurs. Cannot be set "0". For example, to set a schedule for payments every 15 days, you need to set: interval_length = 15, interval_unit = day	Number from 1 to 99	-
interval_unit	Interval unit	Possible values are "day" and "month"	-
day_of_month	Day of month when payment has to occur. Available only if interval_unit = month. Possible values: from 1 to 31. If day_of_month = 29, 30, or 31 and there are no days 29, 30, or 31 in the month, then the last day of the month is used. If day_of_month is not defined, then payment occurs on the day the initiating payment is created	Number from 1 to 31	-
payments_count	Payments count in schedule	Number from 1 to 99	-
delays	Deprecated. Do not use delays in your requests as it will result in an error. Use delayed_first_payment instead	Number	-
delayed_first_payment	Defines whether and how the first scheduled payment is delayed, for example for a trial period. Every following payment is counted from the first one. none - no delay, the payment cycle starts according to the schedule interval. delay_delay_by_interval - delay by a custom interval length and unit, independent of the schedule interval. day_of_week - delay until the next specified day of the week. day_of_month - delay until the specified day of the current or next month.	none, delay_delay_by_interval, day_of_week, day_of_month (default none)	-
first_payment_interval_length	Length of the delay interval before the first scheduled payment. Required if delayed_first_payment = delay_delay_by_interval	Number from 1 to 99	-
first_payment_interval_unit	Unit of the delay interval before the first scheduled payment. Required if delayed_first_payment = delay_delay_by_interval	Possible values are "day" and "month"	-
first_payment_day_of_week	Day of the week on which the first scheduled payment occurs. The platform picks the next occurrence of that day after the initiating payment: if the initiating payment falls on that weekday, the first scheduled payment moves to the following week. Required if delayed_first_payment = day_of_week	Number from 1 to 7, where 1 is Monday and 7 is Sunday	-
first_payment_day_of_month	Day of the month on which the first scheduled payment occurs. If the month has no such day, the last day of the month is used. Required if delayed_first_payment = day_of_month	Number from 1 to 31	-
hash	Special signature to validate your request to Payment Platform	see Appendix A, Formula 4	+

Response parameters

You will get JSON encoded string with the request result

Parameter	Description
action	UPDATE_SCHEDULE
result	SUCCESS

PAUSE_SCHEDULE request

Suspends the schedule and assigns value "Y" for "paused" parameter. This request is sent by POST in the background (e.g., through PHP CURL).

Request parameters

Parameter	Description	Values	Required field
action	Action to pause a schedule - fixed value.	PAUSE_SCHEDULE	+
client_key	Unique key (CLIENT_KEY)	UUID format value	+
schedule_id	Schedule ID in Payment Platform	UUID format value	+
hash	Special signature to validate your request to Payment Platform	see Appendix A, Formula 4	+

Response parameters

Parameter	Description
action	PAUSE_SCHEDULE
result	SUCCESS

RUN_SCHEDULE request

Releases the paused schedule and assigns value "N" for "paused" parameter. This request is sent by POST in the background (e.g., through PHP CURL).

Request parameters

Parameter	Description	Values	Required field
action	Action to run a schedule - fixed value	RUN_SCHEDULE	+
client_key	Unique key (CLIENT_KEY)	UUID format value	+
schedule_id	Schedule ID in Payment Platform	UUID format value	+
hash	Special signature to validate your request to Payment Platform	see Appendix A, Formula 4	+

Response parameters

Parameter	Description
action	RUN_SCHEDULE
result	SUCCESS

DELETE_SCHEDULE request

To delete an existing schedule you need to send the request with the parameters listed below. This request is sent by POST in the background (e.g., through PHP CURL).

Request parameters

Parameter	Description	Values	Required field
action	Action to delete a schedule - fixed value	DELETE_SCHEDULE	+
client_key	Unique key (CLIENT_KEY)	UUID format value	+
schedule_id	Schedule ID in Payment Platform	UUID format value	+
hash	Special signature to validate your request to Payment Platform	see Appendix A, Formula 4	+

Response parameters

Parameter	Description
action	DELETE_SCHEDULE
result	SUCCESS

SCHEDULE_INFO request

Gets information about an existing schedule. This request is sent by POST in the background (e.g., through PHP CURL).

Request parameters

Parameter	Description	Values	Required field
action	Action to get a schedule info - fixed value	SCHEDULE_INFO	+
client_key	Unique key (CLIENT_KEY)	UUID format value	+
schedule_id	Schedule ID in Payment Platform	UUID format value	+
hash	Special signature to validate your request to Payment Platform	see Appendix A, Formula 4	+

Response parameters

Parameter	Description
action	SCHEDULE_INFO
name	Name of schedule
interval_length	Interval length - how often the payments occurs
interval_unit	Interval unit
day_of_month	Day of month when payment has to occur. Available only if interval_unit = month
payments_count	Payments count in schedule
delays	Deprecated. Always returned as null for schedules created after the parameter was retired
delayed_first_payment	Whether and how the first scheduled payment is delayed: none, delay_by_interval, day_of_week or day_of_month
first_payment_interval_length	Length of the delay interval before the first scheduled payment. Set when delayed_first_payment = delay_by_interval
first_payment_interval_unit	Unit of the delay interval before the first scheduled payment. Set when delayed_first_payment = delay_by_interval
first_payment_day_of_week	Day of the week of the first scheduled payment. Set when delayed_first_payment = day_of_week
first_payment_day_of_month	Day of the month of the first scheduled payment. Set when delayed_first_payment = day_of_month
paused	Shows if schedule is in pause (Y or N)

DESCHEDULE request

To deschedule recurring and stop the payments by the schedule.

Parameter	Description	Values	Required field
action	Action to perform	DESCHEDULE	+
client_key	Unique key (CLIENT_KEY)	UUID format value	+
recurring_token	Value obtained during the primary transaction	UUID format value	+
schedule_id	Schedule ID in Payment Platform	UUID format value	+
hash	Special signature to validate your request to Payment Platform	see Appendix A, Formula 4	+

What's next

• Appendix A: the per-action hash recipe table referenced from every action above.
• Hash signature: the same recipes mapped per protocol and per action, plus Checkout and S2S APM for comparison.
• Appendix B: extended request and response parameter definitions.
• Appendix C: test card data and edge cases.
• Redirect / 3DS handling: the redirect flow for payments that require payer interaction.
• Redirect / 3DS handling: the parameters delivered to your notification URL, including 3DS authentication attributes.
• Errors and testing: the most common error codes and the sandbox test cards.
• API error reference: every error code with cause and recommended fix.
• Troubleshooting: symptom-cause-fix breakdowns for the most common integration failures.