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).

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`, 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	+
`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	String; length depends on the country	-
`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 256 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	+
`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	-
`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)	-
`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 payment_token is specified

*** Optional by default. These fields are required only when the Protocol Mapping for S2S CARD is set to Required (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
`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
`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).

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
`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).

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
`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).

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
`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).

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
`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	String up to 255 characters	+
`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, Void signature.

* 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, Void signature.

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, Void signature.

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	+
`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 32 characters	-
`payer_zip`	ZIP-code of the Customer	String up to 10 characters	-
`payer_email`	Customer’s email	String up to 256 characters	-
`payer_phone`	Customer’s phone	String up to 32 characters	-
`payer_ip`	IP-address of the Customer	XXX.XXX.XXX.XXX	+
`parameters`	Object that contains extra parameters required by the acquirer	Format: `parameters: {"param1": "value1", "param2": "value2", "param3": "value3"}`. 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 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

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
`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
`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

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
`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
`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
`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
`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	+
`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 256 characters	-
`payee_phone`	Payee’s phone	String up to 32 characters	-
`parameters`	Object that contains extra parameters required by the acquirer	Format: `parameters: {"param1": "value1", "param2": "value2", "param3": "value3"}`. 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	+
`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 32 characters	-
`payer_zip`	ZIP-code of the Customer	String up to 10 characters	-
`payer_email`	Customer’s email	String up to 256 characters	-
`payer_phone`	Customer’s phone	String up to 32 characters	-
`payer_ip`	IP-address of the Customer	XXX.XXX.XXX.XXX	+
`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 256 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", "param2": "value2", "param3": "value3"}` 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:

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.
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
`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
`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`.

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	UUID format value	+
`hash`	Special signature to validate your request to Payment Platform	CREDIT2CARD - see Appendix A, Formula 6 Others - see Appendix A, Formula 7	+

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
`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	+
`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	+
`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	+
`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, 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 1	+

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	+
`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	+
`delays`	Number of skipped intervals of the scheduled before payment cycle starts	Number	-
`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

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 GET 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`	Number of skipped intervals of the scheduled before payment cycle starts
`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.
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.

Payment operations​

SALE/AUTH request​

Request parameters​

Response parameters​

Synchronous mode​

Successful sale response​

Unsuccessful sale response​

3D-Secure transaction response​

Undefined sale response​

Callback parameters​

Successful sale response​

Unsuccessful sale response​

3D-Secure transaction response​

Undefined sale response​

CAPTURE request​

Request parameters​

Response parameters​

Synchronous mode​

Successful capture response​

Unsuccessful capture response​

Undefined capture response​

Callback parameters​

Successful capture response​

Unsuccessful capture response​

Undefined capture response​

CREDITVOID request​

Request parameters​

Response parameters​

Synchronous mode​

Callback parameters​

Successful refund/reversal response​

Unsuccessful refund/reversal response​

Undefined refund/reversal response​

VOID request​

Request parameters​

Response parameters​

Successful void response​

Unsuccessful void response​

Undefined void response​

Callback parameters​

Successful void response​

Unsuccessful void response​

Undefined void response​

DEBIT request​

Request Parameters​

Response Parameters​

Synchronous mode​

Successful response​

Unsuccessful response​

3D-Secure transaction response​

Undefined response​

Callback parameters​

CREDIT2CARD request​

Request Parameters​

Response Parameters​

Callback parameters​

CARD2CARD request​

Request parameters​

Response parameters​

Synchronous mode​

Successful response​

Unsuccessful response​

3D-Secure transaction response​

Undefined response​

Callback parameters​

GET_TRANS_STATUS request​

Request parameters​

Response parameters​

GET_TRANS_DETAILS request​

Request parameters​

Response parameters​

GET_TRANS_STATUS_BY_ORDER request​

Request parameters​

Response parameters​

RECURRING_SALE request​

Request parameters​

Response parameters​

RECURRING_DEBIT request​

Request parameters​

Response parameters​

Payment operations

SALE/AUTH request

Request parameters

Response parameters

Synchronous mode

Successful sale response

Unsuccessful sale response

3D-Secure transaction response

Undefined sale response

Callback parameters

Successful sale response

Unsuccessful sale response

3D-Secure transaction response

Undefined sale response

CAPTURE request

Request parameters

Response parameters

Synchronous mode

Successful capture response

Unsuccessful capture response

Undefined capture response

Callback parameters

Successful capture response

Unsuccessful capture response

Undefined capture response

CREDITVOID request

Request parameters

Response parameters

Synchronous mode

Callback parameters

Successful refund/reversal response

Unsuccessful refund/reversal response

Undefined refund/reversal response

VOID request

Request parameters

Response parameters

Successful void response

Unsuccessful void response

Undefined void response

Callback parameters

Successful void response

Unsuccessful void response

Undefined void response

DEBIT request

Request Parameters

Response Parameters

Synchronous mode

Successful response

Unsuccessful response

3D-Secure transaction response

Undefined response

Callback parameters

CREDIT2CARD request

Request Parameters

Response Parameters

Callback parameters

CARD2CARD request

Request parameters

Response parameters

Synchronous mode

Successful response

Unsuccessful response

3D-Secure transaction response

Undefined response

Callback parameters

GET_TRANS_STATUS request

Request parameters

Response parameters

GET_TRANS_DETAILS request

Request parameters

Response parameters

GET_TRANS_STATUS_BY_ORDER request

Request parameters

Response parameters

RECURRING_SALE request

Request parameters

Response parameters

RECURRING_DEBIT request

Request parameters

Response parameters