Orders

The payment method.

The transaction identifier string. This will be unique for the merchant in Rebilly. We will attempt to use the OrderID, but if it isn't unique, we will generate a variation.

The payment identifier string. This must be unique (for the merchant) within a 24-hour period.

The casino id maps to a website identifier string in Rebilly.

The gaming server id maps to an organization in Rebilly (read-only).

The player identifier string (maps to a customer in Rebilly). It is composed of two parts concatenated by an underscore. The first part is the registration casino id, and the second part the user id.

The ISO 4217 alpha-3 code. The code is three characters. Currencies must be configured in the gateway account.

The limit amount with no currency sign (55.00). This amount shall be null or 0 or 0.00 or simply not supplied with the request to indicate that there is no purchase limit in place. If there is a purchase limit, this amount should designate the available purchase limit remaining. For example, if the player has set a daily limit of $200, and has already successfully deposited $150 during that day, the limit shall be $50. Rebilly will prevent any purchase adjustment / bump from causing that limit to be breached. How to test limits?

a) Send a limit amount within $10 of the order amount and utilize a special pan that will result in a bump. b) Send an order where the limit amount is below the order amount.

The time when that purchase limit would reset. In case a message needs to be displayed to the the player, this time may be transformed and used by the user interface.

The ISO 4217 alpha-3 code. The code is three characters. Currencies must be configured in the gateway account.

The payment amount with no currency sign (45.00). It is important to check the PurchaseAmount, which may be different from the OrderAmount in case the Player changed the order mid-process, which could be due to an upsell/bump scenarios.

The ISO 4217 alpha-3 code. The code is three characters. Currencies must be configured in the gateway account. This will always match the OrderCurrency.

The amount purchased, in the event of a bump, it will be larger than the OrderAmount with no currency sign (55.00). This amount should be used to credit the player. Please pay careful attention to this field.

The ISO 4217 alpha-3 code. In event of dynamic currency conversion, this will be the currency billed (read-only).

The amount billed. In event of dynamic currency conversion, this will be the amount of the currency billed (read-only).

The billing descriptor that will appear on the cardholders billing statement (read-only).

The DOB is the date of birth of the player in ISO 8601 full-date format (yyyy-mm-dd).

The ipv4 address in dotted decimal format, such as 127.0.0.1.

The Email must match an email regex, and also be at a domain with a valid MX record. Rebilly will not send any emails.

The player's first name.

The player's last name.

The Address refers to the street address, with a max length of 60 characters.

The Address2 refers to the street address, with a max length of 60 characters.

The city.

The Region refers to the state, province, territory, parish, or region.

The Country refers to the ISO 3166-1 alpha-2. Two characters max.

The PostalCode which is also known as the post code or zip code.

The telephone number may be either a landline or mobile.

In the event of an offsite payment due to third party verification, this URL will be called by the system when the payment is no longer offsite. In the event of a timeout, or other exceptional type of transaction, the NotificationURL will be used to update in the event the Result changes from unknown to another value.

In the event of an offsite payment due to third party verification, this URL will be used to redirect the player upon the completion of the interaction.

The player's user-agent header (from the browser request).

The player's designated as represented by the ISO-639-1 alpha-2 code and optional ISO-3166-1 alpha-2 country. For example, en-AU for Australian English.

"Extra data list as a map {"field name": "custom value", ...}". The format must follow the saved format. Recommended fields are BannerTagId, RegistrationDate, DeviceFingerprint and CPF. If a global/master user id is available, that would be appropriate too.

Some status values require special handling.

• waiting-approval: the user should be directed to the approvalUrl (in _links) by either pop or in an iframe which will be specified in the Display attribute value.
• offsite: the user was already redirected to the approvalUrl and we are awaiting notification from the 3rd party gateway.
• timeout (or conn-error): Rebilly will poll the gateway to determine if it was processed. The transaction should be held open until a determination is made. Rebilly will send a notification to the NotificationURL upon resolution of the timeout and conn-error states.
• waiting-gateway: Rebilly will poll final status and will send a notification to NotificationURL upon completed

Payment result (read-only). A result of unknown means the payment should be held open/pending for future changes. That may happen because of a timeout or because interaction is necessary for further processing. If interaction is necessary, there will be a status of waiting-approval, or if the user has already been redirected to the 3rd party for approval, it would be offsite.

The Merchant account used for the payment (read-only).

The Acquirer used for the payment (read-only).

A code that maps to a message. The code is a string number between 0 and 1000. See Rebilly response codes (read-only).

The message mapped from the code (read-only).

A code from the downstream gateway (read-only).

The message mapped from the code from the gateway (read-only).

The message appropriate for presentation to a customer, translated into the language supplied in the request (read-only).

The transaction identifier from the gateway (read-only).

In the event interaction is required to complete the payment, there will be an approvalUrl field in the _links section of the API response. This field will determine if the approvalUrl should be displayed inline, as an iframe, or as a pop in a new window. If the field has an empty string value, then there is not a fixed requirement for the user-experience. If the value is iframe it is recommended it be displayed as an iframe. If the value is pop it is required it to be displayed as a pop in a new window.

Payment created time (read-only)

Payment updated time (read-only)

The links related to resource

The name of the alternative method. The value supplied here will determine where the payment is routed.

The unique financial account id from the payment service.

The payment method.

The transaction identifier string. This will be unique for the merchant in Rebilly. We will attempt to use the OrderID, but if it isn't unique, we will generate a variation.

The payment identifier string. This must be unique (for the merchant) within a 24-hour period.

The casino id maps to a website identifier string in Rebilly.

The gaming server id maps to an organization in Rebilly (read-only).

The player identifier string (maps to a customer in Rebilly). It is composed of two parts concatenated by an underscore. The first part is the registration casino id, and the second part the user id.

The ISO 4217 alpha-3 code. The code is three characters. Currencies must be configured in the gateway account.

The limit amount with no currency sign (55.00). This amount shall be null or 0 or 0.00 or simply not supplied with the request to indicate that there is no purchase limit in place. If there is a purchase limit, this amount should designate the available purchase limit remaining. For example, if the player has set a daily limit of $200, and has already successfully deposited $150 during that day, the limit shall be $50. Rebilly will prevent any purchase adjustment / bump from causing that limit to be breached. How to test limits?

a) Send a limit amount within $10 of the order amount and utilize a special pan that will result in a bump. b) Send an order where the limit amount is below the order amount.

The time when that purchase limit would reset. In case a message needs to be displayed to the the player, this time may be transformed and used by the user interface.

The ISO 4217 alpha-3 code. The code is three characters. Currencies must be configured in the gateway account.

The payment amount with no currency sign (45.00). It is important to check the PurchaseAmount, which may be different from the OrderAmount in case the Player changed the order mid-process, which could be due to an upsell/bump scenarios.

The ISO 4217 alpha-3 code. The code is three characters. Currencies must be configured in the gateway account. This will always match the OrderCurrency.

The amount purchased, in the event of a bump, it will be larger than the OrderAmount with no currency sign (55.00). This amount should be used to credit the player. Please pay careful attention to this field.

The ISO 4217 alpha-3 code. In event of dynamic currency conversion, this will be the currency billed (read-only).

The amount billed. In event of dynamic currency conversion, this will be the amount of the currency billed (read-only).

The billing descriptor that will appear on the cardholders billing statement (read-only).

The DOB is the date of birth of the player in ISO 8601 full-date format (yyyy-mm-dd).

The ipv4 address in dotted decimal format, such as 127.0.0.1.

The Email must match an email regex, and also be at a domain with a valid MX record. Rebilly will not send any emails.

The player's first name.

The player's last name.

The Address refers to the street address, with a max length of 60 characters.

The Address2 refers to the street address, with a max length of 60 characters.

The city.

The Region refers to the state, province, territory, parish, or region.

The Country refers to the ISO 3166-1 alpha-2. Two characters max.

The PostalCode which is also known as the post code or zip code.

The telephone number may be either a landline or mobile.

In the event of an offsite payment due to third party verification, this URL will be called by the system when the payment is no longer offsite. In the event of a timeout, or other exceptional type of transaction, the NotificationURL will be used to update in the event the Result changes from unknown to another value.

In the event of an offsite payment due to third party verification, this URL will be used to redirect the player upon the completion of the interaction.

The player's user-agent header (from the browser request).

The player's designated as represented by the ISO-639-1 alpha-2 code and optional ISO-3166-1 alpha-2 country. For example, en-AU for Australian English.

"Extra data list as a map {"field name": "custom value", ...}". The format must follow the saved format. Recommended fields are BannerTagId, RegistrationDate, DeviceFingerprint and CPF. If a global/master user id is available, that would be appropriate too.

Some status values require special handling.

• waiting-approval: the user should be directed to the approvalUrl (in _links) by either pop or in an iframe which will be specified in the Display attribute value.
• offsite: the user was already redirected to the approvalUrl and we are awaiting notification from the 3rd party gateway.
• timeout (or conn-error): Rebilly will poll the gateway to determine if it was processed. The transaction should be held open until a determination is made. Rebilly will send a notification to the NotificationURL upon resolution of the timeout and conn-error states.
• waiting-gateway: Rebilly will poll final status and will send a notification to NotificationURL upon completed

Payment result (read-only). A result of unknown means the payment should be held open/pending for future changes. That may happen because of a timeout or because interaction is necessary for further processing. If interaction is necessary, there will be a status of waiting-approval, or if the user has already been redirected to the 3rd party for approval, it would be offsite.

The Merchant account used for the payment (read-only).

The Acquirer used for the payment (read-only).

A code that maps to a message. The code is a string number between 0 and 1000. See Rebilly response codes (read-only).

The message mapped from the code (read-only).

A code from the downstream gateway (read-only).

The message mapped from the code from the gateway (read-only).

The message appropriate for presentation to a customer, translated into the language supplied in the request (read-only).

The transaction identifier from the gateway (read-only).

In the event interaction is required to complete the payment, there will be an approvalUrl field in the _links section of the API response. This field will determine if the approvalUrl should be displayed inline, as an iframe, or as a pop in a new window. If the field has an empty string value, then there is not a fixed requirement for the user-experience. If the value is iframe it is recommended it be displayed as an iframe. If the value is pop it is required it to be displayed as a pop in a new window.

Payment created time (read-only)

Payment updated time (read-only)

The links related to resource

The name of the alternative method. The value supplied here will determine where the payment is routed.

The unique financial account id from the payment service.