The Rebilly API is built on HTTP and is RESTful. It has predictable resource URLs and returns HTTP response codes to indicate errors. It also accepts and returns JSON in the HTTP body. Use your favorite HTTP/REST library in your programming language when using this API, or use one of the Rebilly SDKs, which are available in PHP and JavaScript.
Every action in the Rebilly UI is supported by an API which is documented and available for use, so that you may automate any necessary workflows or processes. This API reference documentation contains the most commonly integrated resources.
This topic describes the different forms of authentication that are available in the Rebilly API, and how to use them.
Rebilly offers four forms of authentication: secret key, publishable key, JSON Web Tokens, and public signature key.
To create or manage API keys, select one of the following:
For more information on API keys, see API keys.
Rebilly follows the error response format proposed in RFC 9457, which is also known as Problem Details for HTTP APIs. As with any API responses, your client must be prepared to gracefully handle additional members of the response.
Rebilly provides a JavaScript SDK and a PHP SDK to help interact with the Rebilly API. However, no SDK is required to use the API.
Rebilly also provides FramePay, a client-side iFrame-based solution, to help create payment tokens while minimizing PCI DSS compliance burdens and maximizing your customization ability. FramePay interacts with the payment tokens creation operation.
For installation and usage instructions, see SDKs. All JavaScript SDK code examples are included in the API reference documentation.
For installation and usage instructions, see SDKs. All SDK code examples are included in the API reference documentation. To use them, you must configure the $client as follows:
$client = new Rebilly\Client([
'apiKey' => 'YourApiKeyHere',
'baseUrl' => 'https://api.rebilly.com',
]);The full Rebilly API has over 500 operations. This is likely more than you may need to implement your use cases. If you would like to implement a particular use case, contact Rebilly for guidance and feedback on the best API operations to use for the task.
To integrate Rebilly, and learn about related resources and concepts, see Get started.
Rebilly enforces rate limits on the API to ensure that no single organization consumes too many resources. Rate limits are applied to the organization, and not to the API key. In sandbox environment, rate limits are enforced for non-GET endpoints and are set at 3000 requests per 10 minutes. You can find the exact number of consumed requests in the X-RateLimit-Limit and X-RateLimit-Remaining headers in the response. If the rate limit is exceeded, the API returns a 429 Too Many Requests response and a X-RateLimit-Retry-After header that includes a UTC timestamp of when the rate limit resets.
Use allowlists to exclude specific customer attribute data from risk score checks.
Allowlists are lists of data that are excluded from risk score checks. Allowlists prevent specific data from being added to a blocklist record when a risk score threshold reached.
Use Anti-Money Laundering (AML) operations to screen customers and help prevent your business from becoming directly or indirectly involved in criminal activity.
Use AML operations during customer creation, and some transaction processing, to help determine if a potential customer (lead), or customer, has political or economic sanctions against them.
AML operations search the following for screening purposes: Politically Exposed Persons (PEPs) lists, sanction lists, and adverse media lists.
Use API keys to identify and authenticate applications and users. Always keep your API keys private. When creating API keys, you can restrict them to a given set of permissions. For information on how to create and manage API keys, see API keys.
Use these operations to register applications to the Rebilly Apps Store and manage application instances. An application owner is a person or organization that has submitted an app to the Rebilly App Store. For more information, see Submit an app.
Use these operations to install or uninstall apps from the Rebilly App Store to your Rebilly account, and to manage application instances. An application user is a person or organization that uses an app that is installed from the Rebilly App Store. For more information, see Install or uninstall an app.
Use blocklists to prevent fraud and criminal activity.
Blocklists are lists of customer attribute values that are blocked from buying from you. For example, if a customer attempts to make a purchase from you with a credit card that is in a blocklist, the transaction is blocked and is not processed.
Before a new transaction is processed in Rebilly, blocklists are examined to check for attributes related to the entity. If a match is detected, the operation is aborted. A blocklist that expires after a period of time is called a greylist.
Use broadcast messages to notify customers and leads about upcoming promotions, service updates, and events. Broadcast messages are emails that are sent to a specific group of customers, or all customers. For more information, see Create a broadcast message.
Use coupons to reward customers, generate sales, or to test new pricing strategies. Coupons enable you to apply different types of discounts to invoices, subscriptions, and pricing plans.
Redeemed coupons are attached to a customer's account. Depending on the coupon restrictions, the redeemed coupons are then applied from the customer's account to subsequent invoices or subscriptions. Redeemed coupons can only be applied to invoices of the same currency.
Once a coupon is redeemed it cannot be modified. You may deactivate a coupon or create a new coupon, but you cannot reuse the same coupon code. If you have a use case where you must reuse the same code, contact Rebilly.
Use credit memos to provide a customer with store credit. A common use case for using a credit memo is to provide a customer with store credit, rather than a refund, if the customer pays more than they owe or returns a product. For information on the credit memo resource, see Resources.
Use custom domains to configure and use your own domain for forms and billing portals, instead of the default Rebilly domain: portal.secure-payments.app. For more information, see Configure a custom domain.
Use custom fields to extend a resource scheme to include custom data that is not provided as a common field. Depending on the resource on which the custom field is added, it may be available in the Rebilly UI.
Example: A custom field called preferredCommunicationChannel is added to the customer resource. It has two allowed values, which are 'email' and 'phone'.
{
"customFields": {
"preferredCommunicationChannel": "email"
}
}For detailed information on Rebilly resources, see Resources.
Use these operations to manage customers. A customer is an entity that purchases goods or services from you (a merchant), and is the payee in any transaction that is credited to you. Customers are associated with payment instruments, subscriptions, invoices, and other related resources.
In other systems, customers may be referred to as accounts, clients, members, patrons, or players. For information on the customer resource, see Resources.
Use data export operations to manage the export of resource data, such as: transactions, customers, subscriptions, invoices, invoice item data, or revenue audit. Common data export use cases are: accounting, data analysis, reporting, or importing into other databases.
For detailed information on Rebilly resources, see Resources.
For information on how manage reconciliation, see Transaction reconciliation.
Create and manage deposit requests and manage strategies that determine the deposit amounts to display on the page. Rebilly hosted deposit form provides a secure and compliant way to deposit funds. Deposit forms are customizable, and use fully responsive design, built-in error messaging and validation.
Important: These operations are experimental and may change.
Creates a deposit request. To complete the deposit, the customer is redirected to the deposit link. After the deposit, the customer is redirected to the redirectUrl. Corresponding transaction webhooks are sent to webhooks subscribers.
Deposit request resource.
Website ID of the deposit. This value specifies the website with which the deposit is associated.
ID of a strategy to be applied for this request for amounts and customAmount. If this field is not specified, a randomly selected strategy with a matching filter value is applied for empty amounts and customAmount. If there is no matching strategy, the default strategy with the following parameters is applied for empty amounts and customAmount:
amounts:
calculator: absolute
baseAmount: 10
increments: [10, 20]
adjustBaseToLastDeposit: true
customAmount:
minimum: 1
multipleOf: 1
maximum: 10000For more information, see Create a deposit strategy.
List of available deposit amounts.
If amounts is not specified when a deposit request is created, amounts are determined from the chosen strategy. For more information, see the strategyId property.
Deposit amount limit information. Set optional minimum and maximum deposit amounts. Limits override amounts and customAmount values. If this value is null, deposit amount limits are not set.
Custom amount restrictions. If this value is null, custom amounts are prohibited. If customAmount is not specified when a deposit request is created, amount restrictions are determined from the chosen strategy. For more information, see the strategyId property.
URL to redirect the customer to when a deposit is completed. The default value is the website URL.
Date and time at which the deposit request expires. The default expiration time is one hour after the time the request is created.
ID of a custom property set to apply to the request propertiesSchema.
URL where a server-to-server POST notification is sent. This notification is sent when the transaction result is finalized after a timeout or an offsite interaction.
Do not interpret this notification as a confirmation, complete a GET request to confirm the result of the transaction. To ensure the request is not reattempted, when the result is confirmed, respond with a 2xx HTTP status code.
The following placeholders are available to use in this URI: {id} and {result}. These placeholders are replaced the with the transaction ID and result accordingly.
curl -i -X POST \
https://www.rebilly.com/_mock/catalog/all/deposit-requests \
-H 'Content-Type: application/json' \
-H 'REB-APIKEY: YOUR_API_KEY_HERE' \
-d '{
"websiteId": "web_0YV7DE4Z26DQSA1AC92FBJ7SEG",
"customerId": "cus_0YV7DDSDD1C8DA64KHH2W33CPF",
"strategyId": "dep_str_0YVJ64MAHTDPA97H8S7R5MYR1M",
"currency": "USD",
"amounts": [
0.01
],
"amountLimits": {
"minimum": 0,
"maximum": 0
},
"customAmount": {
"minimum": 0.01,
"multipleOf": 0.01,
"maximum": 0.01
},
"redirectUrl": "http://example.com",
"expirationTime": "2019-08-24T14:15:22Z",
"customPropertySetId": "4f6cf35x-2c4y-483z-a0a9-158621f77a21",
"notificationUrl": "http://example.com"
}'Deposit request created.
Total number of rate limit tokens for this request within a rate limit period. For more information, see Rate limits.
ID of the deposit request.
Website ID of the deposit. This value specifies the website with which the deposit is associated.
List of transaction IDs that are associated with the deposit request. This list includes transactions that are created from the deposit request. There is a maximum of one approved transaction in the list.
Status of the request.
| Enum Value | Description |
|---|---|
| created | Request is created, but it has not been visited by a customer. This is a temporary state. |
| pending | Request has been visited by a customer, but no funds have been deposited yet. This is a temporary state. |
| initiated | A funds deposit transaction has been initiated. This is a temporary state. |
| attempted | A funds deposit transaction was attempted and declined. This is a temporary state. |
| completed | A funds deposit transaction has been approved and completed. This is a permanent state. |
| expired | Request expired without an approved deposit transaction. This is a permanent state. |
List of available deposit amounts.
If amounts is not specified when a deposit is created, amounts are determined from the chosen strategy. For more information, see the strategyId property.
Custom amount restrictions. If this value is null, custom amounts are prohibited. If customAmount is not specified when a deposit request is created, amount restrictions are determined from the chosen strategy. For more information, see the strategyId property.
URL to redirect the customer to when a deposit is completed. The default value is the website URL.
Date and time at which the deposit request expires. The default expiration time is one hour from the time the request is created.
Defines properties the user can complete when they use the hosted deposit form. This field accepts JSON-schema drafts 4, 6, and 7.
Properties that are available for the user to complete when they use the hosted deposit form. Use this object to describe fields that are rendered and completed on the hosted deposit form.
URL where a server-to-server POST notification is sent. This notification is sent when the transaction result is finalized after a timeout or an offsite interaction.
Do not interpret this notification as a confirmation, complete a GET request to confirm the result of the transaction. To ensure the request is not reattempted, when the result is confirmed, respond with a 2xx HTTP status code.
The following placeholders are available to use in this URI: {id} and {result}. These placeholders are replaced the with the transaction ID and result accordingly.
JSON Web Token (JWT) used to complete the deposit request. This value is null if the deposit request is expired or completed.
Custom fields related to the deposit request. Custom field values are copied to created transactions if matching custom fields (name, type) exist.
Date and time which is set automatically when the resource is created.
Date and time which updates automatically when the resource is updated.
{ "id": "dep_req_0YVJ65BSGYC3EAT58SEX8KY6J7", "websiteId": "web_0YV7DE4Z26DQSA1AC92FBJ7SEG", "customerId": "cus_0YV7DDSDD1C8DA64KHH2W33CPF", "transactionIds": [ "string" ], "status": "created", "currency": "USD", "amounts": [ 0.01 ], "customAmount": { "minimum": 0.01, "multipleOf": 0.01, "maximum": 0.01 }, "redirectUrl": "http://example.com", "expirationTime": "2019-08-24T14:15:22Z", "propertiesSchema": { "type": "object", "properties": { … }, "required": [ … ] }, "properties": { "email": "email@example.com", "max": "33" }, "notificationUrl": "http://example.com", "cashierToken": "string", "customFields": { "foo": "bar" }, "createdTime": "2019-08-24T14:15:22Z", "updatedTime": "2019-08-24T14:15:22Z", "_links": [ { … } ], "_embedded": { "customer": {}, "website": {}, "transactions": [] } }
Specifies the starting point within the collection of items to be returned.
Filters the collection items. This field requires a special format. Use , for multiple allowed values. Use ; for multiple fields.
For more information, see Using filter with collections.
Sorts and orders the collection of items. To sort in descending order, prefix with -. Multiple fields can be sorted by separating each with ,.
Expands a request to include embedded objects within the _embedded property of the response. This field accepts a comma-separated list of objects.
For more information, see Expand to include embedded objects.
curl -i -X GET \
'https://www.rebilly.com/_mock/catalog/all/deposit-requests?expand=string&filter=string&limit=1000&offset=1000&sort=string' \
-H 'REB-APIKEY: YOUR_API_KEY_HERE'List of deposit requests retrieved.
ID of the deposit request.
Website ID of the deposit. This value specifies the website with which the deposit is associated.
List of transaction IDs that are associated with the deposit request. This list includes transactions that are created from the deposit request. There is a maximum of one approved transaction in the list.
Status of the request.
| Enum Value | Description |
|---|---|
| created | Request is created, but it has not been visited by a customer. This is a temporary state. |
| pending | Request has been visited by a customer, but no funds have been deposited yet. This is a temporary state. |
| initiated | A funds deposit transaction has been initiated. This is a temporary state. |
| attempted | A funds deposit transaction was attempted and declined. This is a temporary state. |
| completed | A funds deposit transaction has been approved and completed. This is a permanent state. |
| expired | Request expired without an approved deposit transaction. This is a permanent state. |
List of available deposit amounts.
If amounts is not specified when a deposit is created, amounts are determined from the chosen strategy. For more information, see the strategyId property.
Custom amount restrictions. If this value is null, custom amounts are prohibited. If customAmount is not specified when a deposit request is created, amount restrictions are determined from the chosen strategy. For more information, see the strategyId property.
URL to redirect the customer to when a deposit is completed. The default value is the website URL.
Date and time at which the deposit request expires. The default expiration time is one hour from the time the request is created.
Defines properties the user can complete when they use the hosted deposit form. This field accepts JSON-schema drafts 4, 6, and 7.
Properties that are available for the user to complete when they use the hosted deposit form. Use this object to describe fields that are rendered and completed on the hosted deposit form.
URL where a server-to-server POST notification is sent. This notification is sent when the transaction result is finalized after a timeout or an offsite interaction.
Do not interpret this notification as a confirmation, complete a GET request to confirm the result of the transaction. To ensure the request is not reattempted, when the result is confirmed, respond with a 2xx HTTP status code.
The following placeholders are available to use in this URI: {id} and {result}. These placeholders are replaced the with the transaction ID and result accordingly.
JSON Web Token (JWT) used to complete the deposit request. This value is null if the deposit request is expired or completed.
Custom fields related to the deposit request. Custom field values are copied to created transactions if matching custom fields (name, type) exist.
Date and time which is set automatically when the resource is created.
Date and time which updates automatically when the resource is updated.
[ { "id": "dep_req_0YVJ65BSGYC3EAT58SEX8KY6J7", "websiteId": "web_0YV7DE4Z26DQSA1AC92FBJ7SEG", "customerId": "cus_0YV7DDSDD1C8DA64KHH2W33CPF", "transactionIds": [ … ], "status": "created", "currency": "USD", "amounts": [ … ], "customAmount": { … }, "redirectUrl": "http://example.com", "expirationTime": "2019-08-24T14:15:22Z", "propertiesSchema": { … }, "properties": { … }, "notificationUrl": "http://example.com", "cashierToken": "string", "customFields": { … }, "createdTime": "2019-08-24T14:15:22Z", "updatedTime": "2019-08-24T14:15:22Z", "_links": [ … ], "_embedded": { … } } ]
Expands a request to include embedded objects within the _embedded property of the response. This field accepts a comma-separated list of objects.
For more information, see Expand to include embedded objects.
curl -i -X GET \
'https://www.rebilly.com/_mock/catalog/all/deposit-requests/{id}?expand=string' \
-H 'REB-APIKEY: YOUR_API_KEY_HERE'Deposit request retrieved.
ID of the deposit request.
Website ID of the deposit. This value specifies the website with which the deposit is associated.
List of transaction IDs that are associated with the deposit request. This list includes transactions that are created from the deposit request. There is a maximum of one approved transaction in the list.
Status of the request.
| Enum Value | Description |
|---|---|
| created | Request is created, but it has not been visited by a customer. This is a temporary state. |
| pending | Request has been visited by a customer, but no funds have been deposited yet. This is a temporary state. |
| initiated | A funds deposit transaction has been initiated. This is a temporary state. |
| attempted | A funds deposit transaction was attempted and declined. This is a temporary state. |
| completed | A funds deposit transaction has been approved and completed. This is a permanent state. |
| expired | Request expired without an approved deposit transaction. This is a permanent state. |
List of available deposit amounts.
If amounts is not specified when a deposit is created, amounts are determined from the chosen strategy. For more information, see the strategyId property.
Custom amount restrictions. If this value is null, custom amounts are prohibited. If customAmount is not specified when a deposit request is created, amount restrictions are determined from the chosen strategy. For more information, see the strategyId property.
URL to redirect the customer to when a deposit is completed. The default value is the website URL.
Date and time at which the deposit request expires. The default expiration time is one hour from the time the request is created.
Defines properties the user can complete when they use the hosted deposit form. This field accepts JSON-schema drafts 4, 6, and 7.
Properties that are available for the user to complete when they use the hosted deposit form. Use this object to describe fields that are rendered and completed on the hosted deposit form.
URL where a server-to-server POST notification is sent. This notification is sent when the transaction result is finalized after a timeout or an offsite interaction.
Do not interpret this notification as a confirmation, complete a GET request to confirm the result of the transaction. To ensure the request is not reattempted, when the result is confirmed, respond with a 2xx HTTP status code.
The following placeholders are available to use in this URI: {id} and {result}. These placeholders are replaced the with the transaction ID and result accordingly.
JSON Web Token (JWT) used to complete the deposit request. This value is null if the deposit request is expired or completed.
Custom fields related to the deposit request. Custom field values are copied to created transactions if matching custom fields (name, type) exist.
Date and time which is set automatically when the resource is created.
Date and time which updates automatically when the resource is updated.
{ "id": "dep_req_0YVJ65BSGYC3EAT58SEX8KY6J7", "websiteId": "web_0YV7DE4Z26DQSA1AC92FBJ7SEG", "customerId": "cus_0YV7DDSDD1C8DA64KHH2W33CPF", "transactionIds": [ "string" ], "status": "created", "currency": "USD", "amounts": [ 0.01 ], "customAmount": { "minimum": 0.01, "multipleOf": 0.01, "maximum": 0.01 }, "redirectUrl": "http://example.com", "expirationTime": "2019-08-24T14:15:22Z", "propertiesSchema": { "type": "object", "properties": { … }, "required": [ … ] }, "properties": { "email": "email@example.com", "max": "33" }, "notificationUrl": "http://example.com", "cashierToken": "string", "customFields": { "foo": "bar" }, "createdTime": "2019-08-24T14:15:22Z", "updatedTime": "2019-08-24T14:15:22Z", "_links": [ { … } ], "_embedded": { "customer": {}, "website": {}, "transactions": [] } }
Deposit strategy resource.
Filter that uses deposit request properties to determine if a deposit strategy is applicable for the request. If this field is empty, the strategy is applicable for any request.
Deposit strategy amounts configuration.
Deposit amounts calculator. This field specifies if amounts are calculated using an absolute or percentage calculation.
Amounts are specified in baseAmount, and increments are specified in increments.
Example: baseAmount: 10 and increments: [20, 50, 100].
absolute: the amounts displayed to the customer are [10, 30, 60, 110].percent: the amounts displayed to the customer are [10, 12, 15, 20].List of incremental amounts that are displayed to customer.
For more information, see the calculator property.
Specifies if the base amount must be adjusted based on the last deposit. If this value is true, the baseAmount is changed to the last successful deposit amount made using Create a deposit request.
If the customer has no successful deposits, baseAmount is not adjusted.
Custom amount restrictions. If this value is null, custom amounts are prohibited. If customAmount is not specified when a deposit request is created, amount restrictions are determined from the chosen strategy. For more information, see the strategyId property.
Multiple by which the custom amount increases.
For example, if minimum is equal to 5.30, and multipleOf is 0.50, the valid custom amount is 5.30, 5.80, 6.30, 6.80 and so on until the maximum value is reached.
A valid custom amount must be equal to minimum + X * multipleOf, where X is any non negative integer.
curl -i -X POST \
https://www.rebilly.com/_mock/catalog/all/deposit-strategies \
-H 'Content-Type: application/json' \
-H 'REB-APIKEY: YOUR_API_KEY_HERE' \
-d '{
"name": "string",
"filter": "depositRequest.currency:USD",
"amounts": {
"calculator": "absolute",
"baseAmount": 0.01,
"increments": [
0.01
],
"adjustBaseToLastDeposit": false
},
"customAmount": {
"minimum": 0.01,
"multipleOf": 0.01,
"maximum": 0.01
}
}'Deposit strategy created.
Total number of rate limit tokens for this request within a rate limit period. For more information, see Rate limits.
ID of the deposit strategy.
Filter that uses deposit request properties to determine if a deposit strategy is applicable for the request. If this field is empty, the strategy is applicable for any request.
Deposit strategy amounts configuration.
Deposit amounts calculator. This field specifies if amounts are calculated using an absolute or percentage calculation.
Amounts are specified in baseAmount, and increments are specified in increments.
Example: baseAmount: 10 and increments: [20, 50, 100].
absolute: the amounts displayed to the customer are [10, 30, 60, 110].percent: the amounts displayed to the customer are [10, 12, 15, 20].List of incremental amounts that are displayed to customer.
For more information, see the calculator property.
Specifies if the base amount must be adjusted based on the last deposit. If this value is true, the baseAmount is changed to the last successful deposit amount made using Create a deposit request.
If the customer has no successful deposits, baseAmount is not adjusted.
Custom amount restrictions. If this value is null, custom amounts are prohibited. If customAmount is not specified when a deposit request is created, amount restrictions are determined from the chosen strategy. For more information, see the strategyId property.
Multiple by which the custom amount increases.
For example, if minimum is equal to 5.30, and multipleOf is 0.50, the valid custom amount is 5.30, 5.80, 6.30, 6.80 and so on until the maximum value is reached.
A valid custom amount must be equal to minimum + X * multipleOf, where X is any non negative integer.
Date and time which is set automatically when the resource is created.
Date and time which updates automatically when the resource is updated.
{ "id": "dep_str_0YVJ64MAHTDPA97H8S7R5MYR1M", "name": "string", "filter": "depositRequest.currency:USD", "amounts": { "calculator": "absolute", "baseAmount": 0.01, "increments": [ … ], "adjustBaseToLastDeposit": false }, "customAmount": { "minimum": 0.01, "multipleOf": 0.01, "maximum": 0.01 }, "createdTime": "2019-08-24T14:15:22Z", "updatedTime": "2019-08-24T14:15:22Z", "_links": [ { … } ] }
Specifies the starting point within the collection of items to be returned.
Filters the collection items. This field requires a special format. Use , for multiple allowed values. Use ; for multiple fields.
For more information, see Using filter with collections.
curl -i -X GET \
'https://www.rebilly.com/_mock/catalog/all/deposit-strategies?filter=string&limit=1000&offset=1000&sort=string' \
-H 'REB-APIKEY: YOUR_API_KEY_HERE'List of deposit strategies retrieved.
ID of the deposit strategy.
Filter that uses deposit request properties to determine if a deposit strategy is applicable for the request. If this field is empty, the strategy is applicable for any request.
Deposit strategy amounts configuration.
Deposit amounts calculator. This field specifies if amounts are calculated using an absolute or percentage calculation.
Amounts are specified in baseAmount, and increments are specified in increments.
Example: baseAmount: 10 and increments: [20, 50, 100].
absolute: the amounts displayed to the customer are [10, 30, 60, 110].percent: the amounts displayed to the customer are [10, 12, 15, 20].List of incremental amounts that are displayed to customer.
For more information, see the calculator property.
Specifies if the base amount must be adjusted based on the last deposit. If this value is true, the baseAmount is changed to the last successful deposit amount made using Create a deposit request.
If the customer has no successful deposits, baseAmount is not adjusted.
Custom amount restrictions. If this value is null, custom amounts are prohibited. If customAmount is not specified when a deposit request is created, amount restrictions are determined from the chosen strategy. For more information, see the strategyId property.
Multiple by which the custom amount increases.
For example, if minimum is equal to 5.30, and multipleOf is 0.50, the valid custom amount is 5.30, 5.80, 6.30, 6.80 and so on until the maximum value is reached.
A valid custom amount must be equal to minimum + X * multipleOf, where X is any non negative integer.
Date and time which is set automatically when the resource is created.
Date and time which updates automatically when the resource is updated.
[ { "id": "dep_str_0YVJ64MAHTDPA97H8S7R5MYR1M", "name": "string", "filter": "depositRequest.currency:USD", "amounts": { … }, "customAmount": { … }, "createdTime": "2019-08-24T14:15:22Z", "updatedTime": "2019-08-24T14:15:22Z", "_links": [ … ] } ]
curl -i -X GET \
'https://www.rebilly.com/_mock/catalog/all/deposit-strategies/{id}' \
-H 'REB-APIKEY: YOUR_API_KEY_HERE'Deposit strategy retrieved.
ID of the deposit strategy.
Filter that uses deposit request properties to determine if a deposit strategy is applicable for the request. If this field is empty, the strategy is applicable for any request.
Deposit strategy amounts configuration.
Deposit amounts calculator. This field specifies if amounts are calculated using an absolute or percentage calculation.
Amounts are specified in baseAmount, and increments are specified in increments.
Example: baseAmount: 10 and increments: [20, 50, 100].
absolute: the amounts displayed to the customer are [10, 30, 60, 110].percent: the amounts displayed to the customer are [10, 12, 15, 20].List of incremental amounts that are displayed to customer.
For more information, see the calculator property.
Specifies if the base amount must be adjusted based on the last deposit. If this value is true, the baseAmount is changed to the last successful deposit amount made using Create a deposit request.
If the customer has no successful deposits, baseAmount is not adjusted.
Custom amount restrictions. If this value is null, custom amounts are prohibited. If customAmount is not specified when a deposit request is created, amount restrictions are determined from the chosen strategy. For more information, see the strategyId property.
Multiple by which the custom amount increases.
For example, if minimum is equal to 5.30, and multipleOf is 0.50, the valid custom amount is 5.30, 5.80, 6.30, 6.80 and so on until the maximum value is reached.
A valid custom amount must be equal to minimum + X * multipleOf, where X is any non negative integer.
Date and time which is set automatically when the resource is created.
Date and time which updates automatically when the resource is updated.
{ "id": "dep_str_0YVJ64MAHTDPA97H8S7R5MYR1M", "name": "string", "filter": "depositRequest.currency:USD", "amounts": { "calculator": "absolute", "baseAmount": 0.01, "increments": [ … ], "adjustBaseToLastDeposit": false }, "customAmount": { "minimum": 0.01, "multipleOf": 0.01, "maximum": 0.01 }, "createdTime": "2019-08-24T14:15:22Z", "updatedTime": "2019-08-24T14:15:22Z", "_links": [ { … } ] }
Deposit strategy resource.
Filter that uses deposit request properties to determine if a deposit strategy is applicable for the request. If this field is empty, the strategy is applicable for any request.
Deposit strategy amounts configuration.
Deposit amounts calculator. This field specifies if amounts are calculated using an absolute or percentage calculation.
Amounts are specified in baseAmount, and increments are specified in increments.
Example: baseAmount: 10 and increments: [20, 50, 100].
absolute: the amounts displayed to the customer are [10, 30, 60, 110].percent: the amounts displayed to the customer are [10, 12, 15, 20].List of incremental amounts that are displayed to customer.
For more information, see the calculator property.
Specifies if the base amount must be adjusted based on the last deposit. If this value is true, the baseAmount is changed to the last successful deposit amount made using Create a deposit request.
If the customer has no successful deposits, baseAmount is not adjusted.
Custom amount restrictions. If this value is null, custom amounts are prohibited. If customAmount is not specified when a deposit request is created, amount restrictions are determined from the chosen strategy. For more information, see the strategyId property.
Multiple by which the custom amount increases.
For example, if minimum is equal to 5.30, and multipleOf is 0.50, the valid custom amount is 5.30, 5.80, 6.30, 6.80 and so on until the maximum value is reached.
A valid custom amount must be equal to minimum + X * multipleOf, where X is any non negative integer.
curl -i -X PUT \
'https://www.rebilly.com/_mock/catalog/all/deposit-strategies/{id}' \
-H 'Content-Type: application/json' \
-H 'REB-APIKEY: YOUR_API_KEY_HERE' \
-d '{
"name": "string",
"filter": "depositRequest.currency:USD",
"amounts": {
"calculator": "absolute",
"baseAmount": 0.01,
"increments": [
0.01
],
"adjustBaseToLastDeposit": false
},
"customAmount": {
"minimum": 0.01,
"multipleOf": 0.01,
"maximum": 0.01
}
}'Deposit strategy updated.
ID of the deposit strategy.
Filter that uses deposit request properties to determine if a deposit strategy is applicable for the request. If this field is empty, the strategy is applicable for any request.
Deposit strategy amounts configuration.
Deposit amounts calculator. This field specifies if amounts are calculated using an absolute or percentage calculation.
Amounts are specified in baseAmount, and increments are specified in increments.
Example: baseAmount: 10 and increments: [20, 50, 100].
absolute: the amounts displayed to the customer are [10, 30, 60, 110].percent: the amounts displayed to the customer are [10, 12, 15, 20].List of incremental amounts that are displayed to customer.
For more information, see the calculator property.
Specifies if the base amount must be adjusted based on the last deposit. If this value is true, the baseAmount is changed to the last successful deposit amount made using Create a deposit request.
If the customer has no successful deposits, baseAmount is not adjusted.
Custom amount restrictions. If this value is null, custom amounts are prohibited. If customAmount is not specified when a deposit request is created, amount restrictions are determined from the chosen strategy. For more information, see the strategyId property.
Multiple by which the custom amount increases.
For example, if minimum is equal to 5.30, and multipleOf is 0.50, the valid custom amount is 5.30, 5.80, 6.30, 6.80 and so on until the maximum value is reached.
A valid custom amount must be equal to minimum + X * multipleOf, where X is any non negative integer.
Date and time which is set automatically when the resource is created.
Date and time which updates automatically when the resource is updated.
{ "id": "dep_str_0YVJ64MAHTDPA97H8S7R5MYR1M", "name": "string", "filter": "depositRequest.currency:USD", "amounts": { "calculator": "absolute", "baseAmount": 0.01, "increments": [ … ], "adjustBaseToLastDeposit": false }, "customAmount": { "minimum": 0.01, "multipleOf": 0.01, "maximum": 0.01 }, "createdTime": "2019-08-24T14:15:22Z", "updatedTime": "2019-08-24T14:15:22Z", "_links": [ { … } ] }
curl -i -X DELETE \
'https://www.rebilly.com/_mock/catalog/all/deposit-strategies/{id}' \
-H 'REB-APIKEY: YOUR_API_KEY_HERE'Deposit strategy deleted.
Total number of rate limit tokens for this request within a rate limit period. For more information, see Rate limits.
{ "status": 401, "type": "http://example.com", "title": "string", "detail": "string", "instance": "string" }
Custom deposit property set resource.
Defines properties the user can complete when they use the hosted deposit form. This field accepts JSON-schema drafts 4, 6, and 7. Accepted properties types are: string, number, integer, array, and enum. For more information, see Configure custom hosted deposit properties.
curl -i -X POST \
https://www.rebilly.com/_mock/catalog/all/deposit-custom-property-sets \
-H 'Content-Type: application/json' \
-H 'REB-APIKEY: YOUR_API_KEY_HERE' \
-d '{
"name": "string",
"properties": {
"type": "object",
"properties": {
"email": {
"type": "string"
},
"max": {
"type": "integer",
"minimum": 0,
"exclusiveMaximum": 100
}
},
"required": [
"email"
]
}
}'Custom deposit property set created.
Total number of rate limit tokens for this request within a rate limit period. For more information, see Rate limits.
ID of the deposit property set.
Defines properties the user can complete when they use the hosted deposit form. This field accepts JSON-schema drafts 4, 6, and 7. Accepted properties types are: string, number, integer, array, and enum. For more information, see Configure custom hosted deposit properties.
Date and time which is set automatically when the resource is created.
Date and time which updates automatically when the resource is updated.
{ "id": "dep_prop_0YVJ640MB4CXVB8KXBRW3B79R9", "name": "string", "properties": { "type": "object", "properties": { … }, "required": [ … ] }, "createdTime": "2019-08-24T14:15:22Z", "updatedTime": "2019-08-24T14:15:22Z", "_links": [ { … } ] }
Specifies the starting point within the collection of items to be returned.
Filters the collection items. This field requires a special format. Use , for multiple allowed values. Use ; for multiple fields.
For more information, see Using filter with collections.
curl -i -X GET \
'https://www.rebilly.com/_mock/catalog/all/deposit-custom-property-sets?filter=string&limit=1000&offset=1000&sort=string' \
-H 'REB-APIKEY: YOUR_API_KEY_HERE'List of custom deposit property sets retrieved.
ID of the deposit property set.
Defines properties the user can complete when they use the hosted deposit form. This field accepts JSON-schema drafts 4, 6, and 7. Accepted properties types are: string, number, integer, array, and enum. For more information, see Configure custom hosted deposit properties.
Date and time which is set automatically when the resource is created.
Date and time which updates automatically when the resource is updated.
[ { "id": "dep_prop_0YVJ640MB4CXVB8KXBRW3B79R9", "name": "string", "properties": { … }, "createdTime": "2019-08-24T14:15:22Z", "updatedTime": "2019-08-24T14:15:22Z", "_links": [ … ] } ]
curl -i -X GET \
'https://www.rebilly.com/_mock/catalog/all/deposit-custom-property-sets/{id}' \
-H 'REB-APIKEY: YOUR_API_KEY_HERE'Custom deposit property set retrieved.
ID of the deposit property set.
Defines properties the user can complete when they use the hosted deposit form. This field accepts JSON-schema drafts 4, 6, and 7. Accepted properties types are: string, number, integer, array, and enum. For more information, see Configure custom hosted deposit properties.
Date and time which is set automatically when the resource is created.
Date and time which updates automatically when the resource is updated.
{ "id": "dep_prop_0YVJ640MB4CXVB8KXBRW3B79R9", "name": "string", "properties": { "type": "object", "properties": { … }, "required": [ … ] }, "createdTime": "2019-08-24T14:15:22Z", "updatedTime": "2019-08-24T14:15:22Z", "_links": [ { … } ] }
Custom deposit property set resource.
Defines properties the user can complete when they use the hosted deposit form. This field accepts JSON-schema drafts 4, 6, and 7. Accepted properties types are: string, number, integer, array, and enum. For more information, see Configure custom hosted deposit properties.
curl -i -X PUT \
'https://www.rebilly.com/_mock/catalog/all/deposit-custom-property-sets/{id}' \
-H 'Content-Type: application/json' \
-H 'REB-APIKEY: YOUR_API_KEY_HERE' \
-d '{
"name": "string",
"properties": {
"type": "object",
"properties": {
"email": {
"type": "string"
},
"max": {
"type": "integer",
"minimum": 0,
"exclusiveMaximum": 100
}
},
"required": [
"email"
]
}
}'Custom deposit property updated.
Total number of rate limit tokens for this request within a rate limit period. For more information, see Rate limits.
ID of the deposit property set.
Defines properties the user can complete when they use the hosted deposit form. This field accepts JSON-schema drafts 4, 6, and 7. Accepted properties types are: string, number, integer, array, and enum. For more information, see Configure custom hosted deposit properties.
Date and time which is set automatically when the resource is created.
Date and time which updates automatically when the resource is updated.
{ "id": "dep_prop_0YVJ640MB4CXVB8KXBRW3B79R9", "name": "string", "properties": { "type": "object", "properties": { … }, "required": [ … ] }, "createdTime": "2019-08-24T14:15:22Z", "updatedTime": "2019-08-24T14:15:22Z", "_links": [ { … } ] }
curl -i -X DELETE \
'https://www.rebilly.com/_mock/catalog/all/deposit-custom-property-sets/{id}' \
-H 'REB-APIKEY: YOUR_API_KEY_HERE'Custom deposit property set deleted.
Total number of rate limit tokens for this request within a rate limit period. For more information, see Rate limits.
{ "status": 401, "type": "http://example.com", "title": "string", "detail": "string", "instance": "string" }
Use these operations to manage disputes. A dispute occurs when a customer contests a charge to their account. The dispute and related information is made available to the merchant by the bank or credit card company. The merchant then has the option to represent the charge and win the case. This process is called dispute resolution. If the merchant is unable to represent the charge, the card issuer typically reverses the sale and adds fees on top of the charge. This process is called a chargeback.
Use email notifications to keep customers informed on events, and to inform them of events that may require action on their end. Email notifications are targeted email messages that can be plain text or HTML.
Email notifications can also be used to notify teammates about new customers, blocklist matches, risk score changes, and more. For more information, see Email notifications.
Use the file entity to store files and related metadata. Files can be sorted by size, MIME-type, user-defined tags, and description.
The following methods are available to upload files: multipart/form-data encoded form, RAW POST — by sending the file contents as the POST body, and fetching from URL — by providing the file URL using the 'url' parameter.
Use the attachments entity to link a file to one or multiple objects, such as: customer, dispute, transaction, order, plan, product, invoice, or timeline comment. Attachments enable you to quickly find and use files related to specific entities.
Use these operations to manage payment gateway accounts. A payment gateway is a service which enables merchants to receive payments from their customers to their merchant account. A merchant account is a bank account that enables businesses to receive payments. Use payment gateway accounts to connect payment requests to third party networks and platforms.
Use histograms operations to generate transaction histogram reports with cohorts and periods. For information on the invoice resource, see Resources.
Use these operations to manage third-party apps that are integrated to your Rebilly account. For more information on third-party apps, and how to integrate them, see App store.
Use Know Your Customer (KYC) documents to verify your customers identity. The KYC document operations generate a signed link to the Rebilly KYC document gatherer.
Document types:
identity-proof: Validates a customer's identity.address-proof: Validates a customer's address.purchase-proof: Validates a customer's purchase.funds-proof: Validates that a customer has funds.credit-file-proof: Verifies that there is an existing credit file with two sources that match the customer's name, DOB, and address.Rebilly parses and analyzes the documents and accepts or rejects them according to a configurable scoring algorithm. When all document types in a KYC request are accepted, the status is fulfilled, and the KYC request fulfilled webhook is sent.
Use lists to create and maintain sets of values that may be referenced in rule conditions. Commonly used lists contain values related to conditions that target specific properties such as: customers, transactions, or BINs.
You may grant list edit permissions to members of your team without enabling them to edit rules. This may be useful if your workflow involves frequent updates to value sets that are used in rule or bind conditions. List order may not be maintained and duplicates may be removed.
For more information, see Value lists.
Use these operations to manage customer orders. An order is a customer's request to purchase items. It can contain subscription and one-time sale items. When an order contains one or more subscription items, it is a subscription order.
An order generates an invoice. A subscription order generates an invoice for each service period. For more information, see Orders.
Use these operations to manage your organizations in Rebilly. An organization is an entity that represents you, or your company, as a merchant. You can have multiple organizations. For more information, see My organizations and websites.
Note: No data, including organizations, is shared between the live and sandbox environments.
Use these operations to manage payment instruments. Payment instrument is a term which describes any means of making a digital payment, such as: credit cards, debit cards, direct debits, payment service providers, and digital wallets.
For more information on payment instruments, see Payment instruments.
Use payment tokens to reduce the scope of PCI DSS compliance.
A payment token can be made using a different authentication scheme (public key authentication), which enables you to create a payment token directly from the browser. This bypasses the need to send sensitive cardholder info to your servers. We recommend using this with the FramePay library, which helps you integrate a form into this API resource and create payment tokens.
Use pricing plans to describe how the customer must pay for products.
Rebilly provides the following plan types:
For information on the plans resource, see Plans.
For information on plan pricing, see Pricing formulas.
Use quote operations to create and manage quotations. Quotations describe the cost of goods or services to potential customers before they commit to a purchase. A quote contains an initial invoice preview that can be accepted to become an order.
A quote can contain subscription and one-time sale items. When a quote contains one or more subscription items, it is a subscription order quote.
Use these operations to manage user roles within your team or organization. Roles are an implementation of the general hierarchical (Role Based Access Control) RBAC. A senior role inherits all of its juniors' Access Control Lists (ACLs) and its own ACL. Junior roles are not influenced by the senior role.
Use rules to automate. In the Rebilly rules engine, an action is an operation that executes when an event occurs. Action and event conditions are defined in rules. Rulesets are collections of rules that are associated with an event. The order in which the rules are placed within a ruleset specifies the execution order.
For a list of events and related actions, see Events.
Use these operations to manage UI segments. A segment is a filtered view of a data set that can be shared with other users. For example, you may create a transactions segment that displays specific columns that are filtered and sorted based on certain criteria, and share it with others in your organization.
Use these operations to manage Storefront accounts. A Storefront account is an account that the customer is subscribed to in order to use the Rebilly product.
Storefront operations interact directly with the customer, and provide the customer with access to their own data.
To use Storefront operations, the customer must be issued a JWT with limited permissions. For more information, see Create a session with username and password and Exchange an authentication token.
Storefront operations are intended to be used directly from an untrusted browser.
Use these operations to access Storefront billing portals.
Storefront operations interact directly with the customer, and provide the customer with access to their own data.
To use Storefront operations, the customer must be issued a JWT with limited permissions. For more information, see Create a session with username and password and Exchange an authentication token. Storefront operations are intended to be used directly from an untrusted browser.
Use these operations to access Storefront checkout forms.
Storefront operations interact directly with the customer, and provide the customer with access to their own data.
To use Storefront operations, the customer must be issued a JWT with limited permissions. For more information, see Create a session with username and password and Exchange an authentication token. Storefront operations are intended to be used directly from an untrusted browser.
Use these operations to access Storefront custom fields.
Storefront operations interact directly with the customer, and provide the customer with access to their own data.
To use Storefront operations, the customer must be issued a JWT with limited permissions. For more information, see Create a session with username and password and Exchange an authentication token. Storefront operations are intended to be used directly from an untrusted browser.
Use these operations to access Storefront deposits.
Storefront operations interact directly with the customer, and provide the customer with access to their own data.
To use Storefront operations, the customer must be issued a JWT with limited permissions. For more information, see Create a session with username and password and Exchange an authentication token. Storefront operations are intended to be used directly from an untrusted browser.
Use these operations to access Storefront invoices.
Storefront operations interact directly with the customer, and provide the customer with access to their own data.
To use Storefront operations, the customer must be issued a JWT with limited permissions. For more information, see Create a session with username and password and Exchange an authentication token. Storefront operations are intended to be used directly from an untrusted browser.
Use these operations to access Storefront KYC documents.
Storefront operations interact directly with the customer, and provide the customer with access to their own data.
To use Storefront operations, the customer must be issued a JWT with limited permissions. For more information, see Create a session with username and password and Exchange an authentication token. Storefront operations are intended to be used directly from an untrusted browser.
Use these operations to access Storefront orders.
Storefront operations interact directly with the customer, and provide the customer with access to their own data.
To use Storefront operations, the customer must be issued a JWT with limited permissions. For more information, see Create a session with username and password and Exchange an authentication token. Storefront operations are intended to be used directly from an untrusted browser.
Use these operations to access Storefront payment instruments.
Storefront operations interact directly with the customer, and provide the customer with access to their own data.
To use Storefront operations, the customer must be issued a JWT with limited permissions. For more information, see Create a session with username and password and Exchange an authentication token. Storefront operations are intended to be used directly from an untrusted browser.
Use these operations to access Storefront plans.
Storefront operations interact directly with the customer, and provide the customer with access to their own data.
To use Storefront operations, the customer must be issued a JWT with limited permissions. For more information, see Create a session with username and password and Exchange an authentication token. Storefront operations are intended to be used directly from an untrusted browser.
Use these operations to access Storefront products.
Storefront operations interact directly with the customer, and provide the customer with access to their own data.
To use Storefront operations, the customer must be issued a JWT with limited permissions. For more information, see Create a session with username and password and Exchange an authentication token. Storefront operations are intended to be used directly from an untrusted browser.
Use these operations to manage Storefront purchases. Purchases are transactions that have been executed related to the purchase of goods or services.
Storefront operations interact directly with the customer, and provide the customer with access to their own data.
To use Storefront operations, the customer must be issued a JWT with limited permissions. For more information, see Create a session with username and password and Exchange an authentication token. Storefront operations are intended to be used directly from an untrusted browser.
Use these operations to access Storefront quotes.
Storefront operations interact directly with the customer, and provide the customer with access to their own data.
To use Storefront operations, the customer must be issued a JWT with limited permissions. For more information, see Create a session with username and password and Exchange an authentication token. Storefront operations are intended to be used directly from an untrusted browser.
Use these operations to access Storefront transactions.
Storefront operations interact directly with the customer, and provide the customer with access to their own data.
To use Storefront operations, the customer must be issued a JWT with limited permissions. For more information, see Create a session with username and password and Exchange an authentication token. Storefront operations are intended to be used directly from an untrusted browser.
Use these operations to access Storefront websites.
Storefront operations interact directly with the customer, and provide the customer with access to their own data.
To use Storefront operations, the customer must be issued a JWT with limited permissions. For more information, see Create a session with username and password and Exchange an authentication token. Storefront operations are intended to be used directly from an untrusted browser.
Use these operations to manage the product usage of a subscription item for metered billing purposes.
Use metered billing when product quantity is unknown to the customer at the moment of creating a subscription. Metered billing is based on reported usage records. Every reported usage updates the quantity of an upcoming invoice item for a specified subscription and a plan. To create a metered billing plan, see Plans.
Use these operations to manage webhooks. Webhooks notify your systems in real-time when certain events occur. For example, when a new transaction occurs or a new subscription is created. Webhooks enable you to collect information about events. Rebilly can send this information by HTTP POST request to a defined URL of your choice.
Use these operations to manage websites. A website is where your organization obtains a customer. It is also the processor account and billing descriptor used for payment transactions. You can create multiple websites.
Websites are related to each invoice and each payment gateway account. This enables you to associate gateway accounts with multiple websites, or make them exclusive to particular websites. For more information, see My organizations and websites.