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.
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
The typical set of parameters in callbacks that the payment platform sends after payment processing is described below.
Parameter | Description | tree |
---|---|---|
account |
The object that contains the details of the customer bank card or other payment account | 10 |
card_holder |
Card holder name | 10-10 10 |
expiry_month |
Card expiration month | 10-20 10 |
expiry_year |
Card expiration year | 10-30 10 |
id |
ID of saved card in Gate | 10-40 10 |
number |
Masked bank card or other account number. Example: |
10-50 10 |
token |
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 |
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 |
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 |
URL of the issuing bank ACS page. | 20-10 20 |
md |
Merchant technical data in the payment system. | 20-20 20 |
pa_req |
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 |
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 |
Postcode of the customer address. | 30-10 30 |
avs_street_address |
Customer address | 30-20 30 |
avs_result |
Result of the Address Verification Service (AVS) matching. For more information, see Checking with Address Verification Service | 40 |
bank |
The object that contains the data about a card issuer bank. | 50 |
name |
The name of the card issuer bank. | 50-10 50 |
customer |
The object that contains information about the customer who initiated the payment. | 70 |
billing |
The object that contains information about the billing address of the customer. | 70-10 70 |
address |
Street address of the customer billing address. | 70-10-10 70-10 |
city |
City of the customer billing address. | 70-10-20 70-10 |
country |
Country of the customer billing address, in ISO 3166-1 alpha-2 format. Example: |
70-10-30 70-10 |
postal |
Postcode of the customer billing address. | 70-10-40 70-10 |
region |
Region of the customer billing address. | 70-10-50 70-10 |
city |
Customer city | 70-20 70 |
country |
Country of the customer | 70-30 70 |
day_of_birth |
Birth date of the customer in the DD-MM-YYYY format. | 70-40 70 |
first_name |
Customer first name | 70-50 70 |
id |
Unique ID of the customer in your project. | 70-60 70 |
ip_address |
Customer IP address as specified in the initial request. | 70-70 70 |
last_name |
Customer last name | 70-80 70 |
middle_name |
Customer middle name | 70-90 70 |
phone |
Customer phone number. From 4 to 24 digits | 70-100 70 |
decision |
A string that contains the Risk Control System decision related to the payment. | 80 |
decision_message |
The array of strings with the messages from the Risk Control System related to the decision regarding the payment. Example: |
90 |
display_data |
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 of error messages encountered during the payment processing. | 110 |
ErrorItem |
The object that contains information about a single error. | 110-10 110 |
code |
Error code | 110-10-10 110-10 |
description |
The description of the error cause. | 110-10-10 110-10 |
field |
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 |
Message that explains the cause of the error. | 110-10-30 110-10 |
interface_type |
Object that contains the information about the source the payment request originates from. | 120 |
id |
Parameter that specifies the interface the payment request originates from. Possible values:
|
120-10 120 |
user |
Parameter that specifies the Dashboard user that initiated the payment request. Example: |
120-20 120 |
operation |
The object that contains information about the operation that triggered the callback | 130 |
code |
Unified payment provider response code. For the list of the codes, see Operation statuses and response codes | 130-10 130 |
created_date |
Date and time the operation was created. Example: |
130-20 130 |
date |
Date and time the payment status was last updated | 130-30 130 |
eci |
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 |
Unique ID of the operation. | 130-50 130 |
message |
Unified message from the payment provider. For more information about the response codes, see Operation statuses and response codes. | 130-60 130 |
provider |
The object that contains external provider information about the result of the operation. | 130-70 130 |
auth_code |
Authorization code received from an external provider. | 130-70-10 130-70 |
date |
The date and time the payment provider finished processing the payment. | 130-70-20 130-70 |
endpoint_id |
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 |
The payment provider that has been used to process the operation. | 130-70-40 130-70 |
payment_id |
Unique ID of the payment in the provider system. | 130-70-50 130-70 |
request_id |
Unique ID of the last request related to the operation | 130-80 130 |
status |
Operation status. For more information about operation statuses, see Operation statuses and response codes | 130-90 130 |
sum_converted |
The object that contains the currency of the payment provider account and the initial amount denominated in this currency. | 130-100 130 |
amount |
The amount in minor units of the payment provider currency | 130-100-10 130-100 |
currency |
The currency of the payment provider account in ISO 4217 alpha-3 format. Example: |
130-100-20 130-100 |
sum_initial |
The object that contains the amount and currency of the operation as specified in the initial request. | 130-110 130 |
amount |
The operation amount as specified in the initial request in minor units of the currency. | 130-110-10 130-110 |
currency |
Payment currency in ISO 4217 alpha-3 format as specified in the initial request. Example: |
130-110-20 130-110 |
type |
The operation type | 130-120 130 |
payment |
The object that contains the payment data | 140 |
cascading_with_redirect |
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.
|
140-10 140 |
date |
Date and time of the last payment status update Example: |
140-20 140 |
description |
The description of the payment as specified in the initial request | 140-30 140 |
id |
Unique ID of the payment in your web service | 140-40 140 |
is_new_attempts_available |
The flag that shows if the customer can retry the payment.
|
140-50 140 |
method |
Payment method Example: |
140-60 140 |
merchant_refund_id |
Unique identifier of a refund in the merchant system Example: |
140-61 140 |
operation_fee |
The object that contains the information about per- operation fee charged by Rocketpay | 140-70 140 |
amount |
Amount of per-operation fee specified in minor units of the fee currency | 140-70-10 140-70 |
currency |
Currency of the operation fee, in ISO 4217 alpha-3 format. Example: |
140-70-20 140-70 |
sum_with_surcharge |
Total amount of the operation surcharge and operation amount specified in minor currency units | 140-70-30 140-70 |
surcharge_amount |
Amount of the operation surcharge specified in minor currency units | 140-70-40 140-70 |
surcharge_currency |
Currency of the operation surcharge, in ISO 4217 alpha-3 format. Example: |
140-70-50 140-70 |
region |
The region of the country where the card operation is processed. | 140-80 140 |
status |
Payment status. Example: |
140-90 140 |
sum |
The object that contains the information about payment amount, including refunds, and the currency as specified in the initial request | 140-100 140 |
amount |
Payment amount including refunds, in minor currency units | 140-100-10 140-100 |
currency |
Payment currency in ISO 4217 alpha-3 format as specified in the initial request. Example: |
140-100-20 140-100 |
timeout_attempts |
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 |
Payment type. Example: |
140-120 140 |
project_id |
The unique ID of your project | 150 |
provider_extra_fields |
The object that contains the data from the payment provider that are required to complete the payment or to compile reports. | 160 |
recurring |
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 |
COF purchase currency ISO 4217 alpha-3. Example: |
170-10 170 |
id |
COF payment ID. | 170-20 170 |
register_payment_id |
COF payment ID on merchant side | 170-30 170 |
status |
COF purchase status. Possible values:
|
170-40 170 |
type |
COF purchase type. Possible values:
|
170-50 170 |
valid_thru |
Expiration date of the COF purchase ID | 170-60 170 |
redirect_data |
The object that contains the data for redirecting customer to provider to complete the current payment. | 180 |
body |
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 ( If this parameter does contains any data, it is added to the callback as a JSON object ( |
180-10 180 |
method |
Request submission method: POST or GET . |
180-20 180 |
url |
The redirection URL. | 180-30 180 |
signature |
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.
Parameter | Description | tree |
---|---|---|
project_id |
The unique identifier of your project. Example: |
10 |
customer |
The object with the customer data. |
20 |
id |
The unique identifier of the customer in your project. Example: |
20-120 |
request |
The object with the request data. | 30 |
id |
Unique identifier of the request. Example: |
30-130 |
action |
Type of the request. The following options are available:
Example: |
30-230 |
status |
The request status. Possible values:
Example: |
30-330 |
errors |
Array of error messages. | 30-430 |
ErrorItem |
The object with information about a single error. | 30-4-130-4 |
code |
Error code. Example: |
30-4-1-130-4-1 |
message |
A message that explains the error cause. Example: |
30-4-1-230-4-1 |
field |
The parameter in which the error occurred if it was defined | 30-4-1-330-4-1 |
token |
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 |
The date and time the token was generated. Example: |
50 |
token_status |
Token status. Example: |
60 |
signature |
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" }
Related links
- Operation statuses and response codes—comprehensive information about operation statuses and response codes including the response codes in callbacks from the payment platform.
- Signature generation and verification—detailed information on how to sign requests and verify callback signatures.