Callbacks in Payment Page
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:
- the status of the payment has been changed. It may be due to, for example, redirecting the customer, displaying them payment instructions, completing 3D-Secure authentication, asking the customer to provide data required for the payment, etc. To learn more about operation statuses at the Rocketpay payment platform, see Payment types, operations and payments.
If you perform payments by using Payment Page, these callbacks are sent to you for informational purposes only. Your system just has to respond with the HTTP
200 OK
status code to them, no other action is required. Also, you can choose not to receive such callbacks. To do so, contact the Rocketpay technical support. - a card token has been generated, revoked or expired. See the example of such a callback in the Callback section.
- the operation has finished processing in the Rocketpay payment platform.
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 payments 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 what URLs 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 request for opening the checkout page 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 the 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
EPayWidget.run( { project_id: 1234, payment_id: 'payment_47', customer_id: 'customer_123', customer_first_name: 'John', customer_last_name: 'Doe', customer_email: 'johndoe@example.com', merchant_callback_url: 'http://example.com/callback/default', merchant_success_callback_url: 'http://example.com/success', merchant_decline_callback_url: 'http://example.com/decline', payment_currency: 'USD', payment_amount: 10000, signature: 'kUi2x9dKHAVNU0FYldJrxh4yo+52Kt8KU+Y19vySO\/RLUkDJrOcZzUCwX6R\/ekpZhkIQg==' } )
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.
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 Supported payment cards. |
10-70 10 |
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 |
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 |