Callbacks in Gate

Callback is a system message that the Rocketpay payment platform sends to the merchant's URL to pass some information, for example payment result.

What callbacks in Rocketpay look like

Callbacks are HTTP POST requests sent to the URL that you provide Rocketpay with when integrating.

The callback body contains a JSON string of parameters. You can configure what parameters are to be sent in the request body. To do so, contact the Rocketpay technical support.

Here is an example of a callback body of the typical structure. For demonstration purposes, the contents of the JSON string in the example are split into multiple lines.

Figure: Example of a callback of the typical structure

{
    "project_id": 1234,
    "payment": {
        "id": "payment_47",
        "type": "purchase",
        "status": "success",
        "date": "2022-03-25T11:08:45+0000",
        "method": "mobile",
        "sum": {
            "amount": 10000,
            "currency": "USD"
        },
        "description": ""
    },
    "customer": {
        "id": "customer_123"
    },
    "operation": {
        "id": 28,
        "type": "sale",
        "status": "success",
        "date": "2022-03-25T11:08:45+0000",
        "created_date": "2022-03-25T11:08:05+0000",
        "request_id": "9e32835fb27907e0b08569d7d150e387a16a80e336c5117242b5cf60a4e17839",
        "sum_initial": {
            "amount": 10000,
            "currency": "USD"
        },
        "sum_converted": {
            "amount": 10000,
            "currency": "USD"
        },
        "code": "0",
        "message": "Success",
        "provider": {
            "id": 12345,
            "payment_id": "123abc123-321",
            "auth_code": ""
        }
    },
    "signature": "U7HQO7ToISZhMPKdM4Xr4DSX2UuHp99rHrtaxkUKQtoYzFvoB3cs9CRd4xeYG2Q=="
}

The following is an example of the body of a customized callback.

Figure: Example of a customized callback

{
    "project_id": 1234,
    "payment": {
        "id": "payment_47",
        "type": "purchase",
        "status": "success",
        "date": "2022-03-25T11:08:45+0000",
        "method": "mobile",
        "sum": {
            "amount": 10000,
            "currency": "USD"
        },
        "description": ""
    },
    "customer": {            // object with expanded customer data
        "id": "customer_123",
        "email": "johndoe@example.com",
        "phone": "491234567890",
        "first_name": "John",
        "last_name": "Doe"
    },
    "operation": {
        "id": 28,
        "type": "sale",
        "status": "success",
        "date": "2022-03-25T11:08:45+0000",
        "created_date": "2022-03-25T11:08:05+0000",
        "request_id": "9e32835fb27907e0b08569d7d150e387a16a80e336c5117242b5cf60a4e17839",
        "sum_initial": {
            "amount": 10000,
            "currency": "USD"
        },
        "sum_converted": {
            "amount": 10000,
            "currency": "USD"
        },
        "code": "0",
        "message": "Success",
        "provider": {
            "id": 12345,
            "payment_id": "123abc123-321",
            "auth_code": ""
        }
    },
    "signature": "U7HQO7ToISZhMPKdM4Xr4DSX2UuHp99rHrtaxkUKQtoYzFvoB3cs9CRd4xeYG2Q=="
}

The callbacks from Rocketpay always have a signature. For the information on how to verify the signature in a callback, see Signature generation and verification.

When Rocketpay sends callbacks

The Rocketpay payment platform sends you callbacks in the following cases:

  • your system has to perform certain actions for the payment. For more information about this kind of callbacks, see the information below.
  • a card token has been generated, revoked or expired. For more information about callbacks with token information, see Token-related callback parameters.
  • the operation has finished processing in the Rocketpay payment platform. The callback will have the status of the operation.

When there are some actions to perform the payment required from your system, the Rocketpay payment platform assigns a certain status to the payment and sends you a respective callback. To learn more about operation statuses at the Rocketpay payment platform, see Payment types, operations and payments.

Listed below are some of the actions that may be required from your system to perform a payment:

  • Your system has to send Rocketpay the data required for purchase performing. In this case, Rocketpay will send you a callback where the necessary data is indicated. Learn more about such cases at Submission of additional payment information.

    Figure: Example of a callback fragment where the data required to perform the purchase is indicated

    "clarification_fields": {
                "account": {
                    "type": "object",
                    "description": "Object contains the account details of bank",
                    "properties": {
                        "number": {
                            "type": "string",
                            "maxLength": 100,
                            "minLength": 1,
                            "description": "Customer account number"
                        }
                    },
                    "required": [
                        "number"
                    ],
                    "errors": [
                        {
                            "property": "account.number",
                            "message": "The property number is required",
                            "constraint": "required"
                        }
                    ]
                }
            },
  • Your system has to send Rocketpay the data that your customer received from the payment system when making a payment. It may be, for example, a transaction ID or a payment verification code. In this case, Rocketpay will send you a callback where the data required for the payment to proceed is indicated.

    If the payment system sends the customer some data that you then should pass to the payment platform, it will be mentioned in the section of the payment method the payment was initiated with. See Payment methods for the list of payment methods supported in Rocketpay.

    Figure: Example of a callback fragment where the data required for the payment to proceed is indicated

    {
        "clarification_fields": [
            "approval_code"
        ]
    }
  • Your system has to perform some actions for the customer to complete 3-D Secure authentication. To learn more about this procedure, see the Customer authentication by using the 3‑D Secure 1 and Authentication by using 3‑D Secure 2 sections or reach out to your key account manager at Rocketpay.
  • Your system has to redirect the customer so that they could complete the purchase on the provider's side. In this case, Rocketpay will send you a callback with the data to redirect the customer.

    Figure: Example of a callback fragment with customer redirection data

    "redirect_data": {
        "method": "GET",
        "body": [],
        "encrypted": [],
        "url": "https://example.com/redirect"
    }
  • Your system has to display some information to the customer (for example, payment instructions or a QR code) so that they could make a purchase. In this case, Rocketpay will send you a callback with the data to display to the customer.

    Figure: Example of a callback fragment with the data to display to the customer

    "display_data": [
                {
                    "type": "qr_data",
                    "title": "QR code",
                    "data": "00020101com.359a71a-0cad-4cb2-a9503***63042BBF"
                }
            ],

Callback delivery addresses

Callbacks are sent to the URL that you provide Rocketpay with when integrating. If you have several projects, you can provide Rocketpay with individual URLs for each project.

You can provide Rocketpay with individual URLs to receive callbacks with certain information about the payment, e.g. for the payment platform to send you callbacks for successfully performed payment to one URL and callbacks for the declined ones to the other. You can also use individual URLs to receive callbacks for the payments of a certain type or payments performed with a specific payment method.

You can specify individual URLs for receiving callbacks yourself by using Dashboard. To do so, go to Dashboard, select the Projects section, and then click the Callbacks tab. The tools in Dashboard allow you to specify in what cases and where Rocketpay will send callbacks to. To learn more about specifying URLs in Dashboard, see Working with callback settings.

Please note that your system must accept callbacks only from the IP address you receive from Rocketpay when integrating. To double-check the IP address, contact the Rocketpay technical support.

Callback delivery addresses for a specific payment

You can also specify an individual URL for receiving callbacks for a specific payment. To do so, add the merchant_callback_url parameter to the initial payment request and set its value to the URL that Rocketpay should use to send callbacks to. After that the payment platform will send all the callbacks related to the payment (and only to this payment) to this URL ignoring any callback URLs configured in your project.

Also, you can specify the URLs the payment platform will use to send the final callback to with the information about the payment outcome. To do so, simply add one or both of the following parameters to your request:

  • merchant_success_callback_url—the URL which the payment platform will send the final callback to if the payment is successfully completed
  • merchant_decline_callback_url —the URL which the payment platform will send the final callback to if the payment is declined.

These parameters always override the merchant_callback_url parameter and the project settings. For example, if you specify both merchant_callback_url and merchant_success_callback_url parameters, the payment platform will use the URL specified in merchant_success_callback_url and ignore both merchant_callback_url and the default URL specified in your project at the payment platform. The same applies to merchant_decline_callback_url for the final decline callback URL.

Figure: Example of the data from a request with the URLs to send callbacks to for this payment

{
    "general": {
        "project_id": 1234,
        "payment_id": "payment_47",
        "merchant_callback_url": "http://example.com/callback/default",
        "merchant_success_callback_url": "http://example.com/success",
        "merchant_decline_callback_url": "http://example.com/decline",
        "signature": "PJkV8ej\/UG0Di8hTng6JvC7vQsaC6tajQVVfBaNIipTv+AWoXW\/9MTO8yJA=="
    },
    "customer": {
        "id": "customer_123",
        "ip_address": "198.51.100.47",
        "first_name": "John",
        "last_name": "Doe",
        "email": "johndoe@example.com"
    },
    "payment": {
        "amount": 10000,
        "currency": "USD"
    }
}

How to respond to callbacks

Your system must respond to the callback with the HTTP 200 OK status code if it has successfully accepted it. Please note that your system shouldn't have any limitations on the time callbacks are received because callbacks from Rocketpay may be sent with delay.

Warning: In some cases Rocketpay may resend callbacks with payment result for the payments that have already been performed. If your system receives such a callback, it must respond to it with the HTTP 200 OK status code and not provide any services or additional goods to the customer for that payment again.

If your system fails to accept and/or process a callback, it must respond to it with the relevant error message like 400 Bad Request status code (for example, if you were unable to convert a parameter string to an array) or 500 Internal Server Error status code (for example, if the callback was sent to the wrong URL). Even though your system wasn't able to accept and/or process a callback, it must be ready to accept further callbacks for this payment.

If your system hasn't responded with the HTTP 200 OK status code to the callback, Rocketpay will resend callbacks according to the following schedule:

  • 6 attempts at 10-second intervals
  • then 62 attempts within 4 hours with increasing intervals. The interval increases according to the formula: 70 + 10·1,12n-4, where n is the serial number of the attempt
  • after that, the callbacks are sent every 4 hours until the maximum number of attempts is achieved.

In total, Rocketpay sends 120 callbacks within 11 days. The callback delivery schedule may insignificantly change depending on the system load.

You can delay callback delivery for a specific payment. To do so, add the delay parameter in the callback object to your request and set the value of this parameter to the number of seconds the callback is to be delayed for. Callback delivery can be delayed for 600 seconds maximum.

Figure: Example of the data from a callback with the parameter to delay callback delivery

{
    "general": {
        "project_id": 1234,
        "payment_id": "payment_47",
        "signature": "PJkV8ej\/UG0Di8hTng6JvC7vQsaC6tajQVVfBaNIipTv+AWoXW\/9MTO8yJA=="
    },
    "customer": {
        "id": "customer_123",
        "ip_address": "198.51.100.47",
        "first_name": "John",
        "last_name": "Doe",
        "email": "johndoe@example.com"
    },
    "payment": {
        "amount": 10000,
        "currency": "USD"
    },
    "callback": {
            "delay": 30                // delivery time delay in seconds
    }
}

Callback parameters

The parameters that are passed in callbacks may differ depending on the request. Additionally you can extend the list of parameters that are sent in callbacks for your project. To extend the parameter set, contact technical support specialists support@rocketpay.kz

Attention: The callback signature is calculated by using all the parameters the callback contains.

The typical set of parameters in callbacks that the payment platform sends after payment processing is described below.

Table 1. Callback objects and parameters
Parameter Description tree

account
object

The object that contains the details of the customer bank card or other payment account 10

card_holder
string

Card holder name 10-10 10

expiry_month
string

Card expiration month 10-20 10

expiry_year
string

Card expiration year 10-30 10

id
integer

ID of saved card in Gate 10-40 10

number
string

Masked bank card or other account number.

Example: 424242***4242

10-50 10

token
string

Token of the customer bank card. The token is generated automatically when a successful payment is performed provided the corresponding option was enabled when integrating with Rocketpay. 10-60 10

type
string

Type of the customer bank card or the mobile operator which is used to perform a payment. For possible values for bank cards, see Overview.

10-70 10

acs
object

The object that contains the result of the customer authentication by using 3‑D Secure. This object is available in callback, if the payment was made with the card that supports 3‑D Secure. 20

acs_url
string

URL of the issuing bank ACS page. 20-10 20

md
string

Merchant technical data in the payment system. 20-20 20

pa_req
string

The authentication request that need to be sent to the issuing bank. The parameter contains encoded information about the card holder, the merchant, and the payment. 20-30 20

avs_data
object

The object that contains the results of the AVS matching (Address Verification Service). For more information, see Checking with Address Verification Service 30

avs_post_code
string

Postcode of the customer address. 30-10 30

avs_street_address
string

Customer address 30-20 30

avs_result
string

Result of the Address Verification Service (AVS) matching. For more information, see Checking with Address Verification Service 40

bank
object

The object that contains the data about a card issuer bank. 50

name
string

The name of the card issuer bank. 50-10 50

customer
object

The object that contains information about the customer who initiated the payment. 70

billing
object

The object that contains information about the billing address of the customer. 70-10 70

address
string

Street address of the customer billing address. 70-10-10 70-10

city
string

City of the customer billing address. 70-10-20 70-10

country
string

Country of the customer billing address, in ISO 3166-1 alpha-2 format.

Example: UK

70-10-30 70-10

postal
string

Postcode of the customer billing address. 70-10-40 70-10

region
string

Region of the customer billing address. 70-10-50 70-10

city
string

Customer city 70-20 70

country
string

Country of the customer 70-30 70

day_of_birth
string

Birth date of the customer in the DD-MM-YYYY format. 70-40 70

first_name
string

Customer first name 70-50 70

id
string

Unique ID of the customer in your project. 70-60 70

ip_address
string

Customer IP address as specified in the initial request. 70-70 70

last_name
string

Customer last name 70-80 70

middle_name
string

Customer middle name 70-90 70

phone
string

Customer phone number. From 4 to 24 digits 70-100 70

decision
string

A string that contains the Risk Control System decision related to the payment. 80

decision_message
array

The array of strings with the messages from the Risk Control System related to the decision regarding the payment.

Example: reject.message("RCS reject. Amount less than allowed").

90

display_data
object

The object that contains the data from the payment provider that are required to display QR code with payment details to the customer. 100

errors
array

Array of error messages encountered during the payment processing. 110

ErrorItem
object

The object that contains information about a single error. 110-10 110

code
integer

Error code 110-10-10 110-10

description
string

The description of the error cause. 110-10-10 110-10

field
string

This parameter contains the name of the parameter in which the error occurred, if it was possible to locate the failed parameter. 110-10-20 110-10

message
string

Message that explains the cause of the error. 110-10-30 110-10

interface_type
object

Object that contains the information about the source the payment request originates from. 120

id
integer

Parameter that specifies the interface the payment request originates from. Possible values:

  • 1—the request issued by using API Gate
  • 2–4— the request is issued by Rocketpay
  • 5—the request is issued by using Dashboard
  • 6—the request is issued by Payment Page in modal window
  • 7—the request is issued by Payment Page in iframe
120-10 120

user
string

Parameter that specifies the Dashboard user that initiated the payment request.

Example: johndoe@example.com

120-20 120

operation
object

The object that contains information about the operation that triggered the callback 130

code
string

Unified payment provider response code. For the list of the codes, see Operation statuses and response codes 130-10 130

created_date
string

Date and time the operation was created.

Example: 2017-07-27T15:19:13+0000

130-20 130

date
string

Date and time the payment status was last updated 130-30 130

eci
string

The flag that shows the result of the 3‑D Secure customer authentication. For more information, see Electronic Commerce Indicator (ECI) codes 130-40 130

id
integer

Unique ID of the operation. 130-50 130

message
string

Unified message from the payment provider. For more information about the response codes, see Operation statuses and response codes. 130-60 130

provider
object

The object that contains external provider information about the result of the operation. 130-70 130

auth_code
string

Authorization code received from an external provider. 130-70-10 130-70

date
string

The date and time the payment provider finished processing the payment. 130-70-20 130-70

endpoint_id
string (integer)

CRC32 ID of the external provider gate.

In some cases, because of payment system or provider requirements, the type of this parameter may be integer.

130-70-30 130-70

id
integer

The payment provider that has been used to process the operation. 130-70-40 130-70

payment_id
string

Unique ID of the payment in the provider system. 130-70-50 130-70

request_id
string

Unique ID of the last request related to the operation 130-80 130

status
string

Operation status. For more information about operation statuses, see Operation statuses and response codes 130-90 130

sum_converted
object

The object that contains the currency of the payment provider account and the initial amount denominated in this currency. 130-100 130

amount
integer

The amount in minor units of the payment provider currency 130-100-10 130-100

currency
string

The currency of the payment provider account in ISO 4217 alpha-3 format.

Example: EUR

130-100-20 130-100

sum_initial
object

The object that contains the amount and currency of the operation as specified in the initial request. 130-110 130

amount
integer

The operation amount as specified in the initial request in minor units of the currency. 130-110-10 130-110

currency
string

Payment currency in ISO 4217 alpha-3 format as specified in the initial request.

Example: USD

130-110-20 130-110

type
string

The operation type 130-120 130

payment
object

The object that contains the payment data 140

cascading_with_redirect
boolean

The flag shows whether you need to redirect the customer to a different ACS URL to retry the 3D-Secure authentication when an external provider declines the operation, and to display a page with an error message and the Try Again button.

  • true—retry the 3D-Secure authentication;
  • false—no need to retry the 3D-Secure authentication.
140-10 140

date
string

Date and time of the last payment status update

Example: 2017-07-27T15:19:13+0000

140-20 140

description
string

The description of the payment as specified in the initial request 140-30 140

id
string

Unique ID of the payment in your web service 140-40 140

is_new_attempts_available
boolean

The flag that shows if the customer can retry the payment.

  • true—customer can retry the payment
  • false—customer cannot retry the payment
This parameter is issued, if the "Try Again" functionality is enabled in Payment Page
140-50 140

method
                                string
                                

Payment method

Example: card

140-60 140

merchant_refund_id
string

Unique identifier of a refund in the merchant system

Example: refund_1

140-61 140

operation_fee
object

The object that contains the information about per- operation fee charged by Rocketpay 140-70 140

amount
string

Amount of per-operation fee specified in minor units of the fee currency 140-70-10 140-70

currency
string

Currency of the operation fee, in ISO 4217 alpha-3 format.

Example: EUR

140-70-20 140-70

sum_with_surcharge
string

Total amount of the operation surcharge and operation amount specified in minor currency units 140-70-30 140-70

surcharge_amount
string

Amount of the operation surcharge specified in minor currency units 140-70-40 140-70

surcharge_currency
string

Currency of the operation surcharge, in ISO 4217 alpha-3 format.

Example: EUR

140-70-50 140-70

region
string

The region of the country where the card operation is processed. 140-80 140

status
string

Payment status.

Example: success

140-90 140

sum
object

The object that contains the information about payment amount, including refunds, and the currency as specified in the initial request 140-100 140

amount
integer

Payment amount including refunds, in minor currency units 140-100-10 140-100

currency
string

Payment currency in ISO 4217 alpha-3 format as specified in the initial request.

Example: USD

140-100-20 140-100

timeout_attempts
string

The time when the customer can retry the payment after an initial decline. This parameter is issued, if the "Try Again" functionality is enabled in Payment Page 140-110 140

type
string

Payment type.

Example: purchase

140-120 140

project_id
integer

The unique ID of your project 150

provider_extra_fields
object

The object that contains the data from the payment provider that are required to complete the payment or to compile reports. 160

recurring
object

The object that contains COF purchase registration data. The data are submitted, if the initial request for payment includes the recurring_register=1 line and the payment is successful. 170

currency
string

COF purchase currency ISO 4217 alpha-3.

Example: USD

170-10 170

id
integer

COF payment ID. 170-20 170

register_payment_id
string

COF payment ID on merchant side 170-30 170

status
string

COF purchase status. Possible values:
  • active—COF purchase is active.
  • canceled—COF purchase is canceled.
170-40 170

type
string

COF purchase type. Possible values:
  • R—COF purchase
  • U—autopayment
  • C payment
170-50 170

valid_thru
string

Expiration date of the COF purchase ID 170-60 170

redirect_data
object

The object that contains the data for redirecting customer to provider to complete the current payment. 180

body
object

The set of parameters with the data for redirection.

If this parameter contains no data, it is added to the callback as an empty array ("body": []).

If this parameter does contains any data, it is added to the callback as a JSON object ("body": {...}).

180-10 180

method
string

Request submission method: POST or GET. 180-20 180

url
string

The redirection URL. 180-30 180

signature
string

Callback signature. For more information, see Signature generation and verification 190

Token-related callback parameters

Once you submit a token generation or a token revoke request to the /v2/customer/card/tokenize endpoint, the payment platform returns a callback with the request execution result. The following table lists the parameters included in the callback.

For more general information about callbacks, see What callbacks in Rocketpay look like.

Table 2. Callback objects and parameters related to creating or revoking a token
Parameter Description tree

project_id
string

The unique identifier of your project.

Example: 123.

10

customer
object

The object with the customer data.

20

id
string

The unique identifier of the customer in your project.

Example: customer_123

20-120

request
object

The object with the request data. 30

id
integer

Unique identifier of the request.

Example: 3718000054

30-130

action
string

Type of the request. The following options are available:

  • tokenize—token creation request
  • token_revoke—token revoke request
  • parameter is missing—token is expired and deactivated. The platform initiates a callback with missing action automatically, immediately after the token expires. Such callback is not issued in response to a request.

Example: tokenize

30-230

status
string

The request status. Possible values:

  • success—request successfully completed
  • error—error(s) encountered when processing request. The error details are passed in the errors array.

Example: success

30-330

errors
array

Array of error messages. 30-430

ErrorItem
object

The object with information about a single error. 30-4-130-4

code
string

Error code.

Example: 10309

30-4-1-130-4-1

message
string

A message that explains the error cause.

Example: Attempt to make a COF purchase without registered recurrent payments.

30-4-1-230-4-1

field
string

The parameter in which the error occurred if it was defined 30-4-1-330-4-1

token
string

Token of the customer bank card. The token is generated automatically when a successful payment is performed if the appropriate option is enabled. 40

token_created_at
string

The date and time the token was generated.

Example: 2017-07-21T03:31:24+0000

50

token_status
string

Token status.

Example: active

60

signature
string

Callback signature 70

Figure: Example of the data from a callback with the token and some related information

{
"project_id": 12,
"customer": {
    "id": "cust_123"
    },
"request": {
    "id": "3c7f53fdbb5b8c96f9707457d75f",
    "action": "tokenize",
    "status": "success"
    },
"token": "2f0e75befacca30623354f9ffb0f44a80bee52982c39727b85039ef6f64309a1",
"token_created_at": "2017-11-28 13:30:57",
"token_status": "active",
"signature": "\/gmTHcy5wvrFD4ISuWEiV8+nOa3aqnLnyJ\/AupOYkl9S5eLJZ"
}