Imburse Portals are the user-friendly interfaces that you can use to interact with our functionalities. Currently, there are two Portals you can interact with - Account and Tenant.
Once you sign up with Imburse Platform, you will obtain an Imburse Account. The Account represents your organization and lets you manage license and billing with Imburse. It also lets you manage multiple Users and Tenants.
If an Account represents your organization then Tenants represent its business units. Account Portal doesn't let you access our core functionalities, Tenants do. A Tenant serves three main purposes:
- Configure and Manage Marketplace Apps, Schemes, and Reports
- Execute instructions
- Logically isolate data and processing from other tenants as tenants don't share information with each other
Once you have signed up with us, we provide two environments - Sandbox and Production - to you. See below for more information on each of them.
|Environment||Used for||REST API||Account Portal||Tenant Portal|
|Sandbox||Integrating and experimenting with Imburse||https://sandbox-api.imbursepayments.com||https://sandbox-account.imbursepayments.com||https://sandbox-portal.imbursepayments.com|
|Production||Real-time commercial operations||https://api.imbursepayments.com||https://account.imbursepayments.com||https://portal.imbursepayments.com|
App Type, Direction, Payment Methods, Transaction Type, and Networks.Apps.Financial Instrument for a payment method. Visa, Mastercard, American Express, and Discover are examples of Networks.
A Payment Service Provider (PSP) is a third-party company that grants you access to the payment method.
Apps refer to applications that Imburse uses to connect to PSPs and their services. Apps are easy to install and configure. Once you have configured them, Imburse can connect and push your payment requests through them.Reward Apps let you pay your customer in Gift cards, Travel Miles or Vouchers.
Rewards are an alternative form of payout solution that allow your customers to receive payments in the form of gift cards, travel miles, or vouchers .
Reward Groups let you group multiple Rewards together.
Schemes define a set of rules for the Imburse client to collect payments, issue payouts, and track financial instruments (e.g., movements on bank accounts). Think of them as workflows. They:
- define the payment methods to present to a customer
- define the partner/PSP through which to route a specific transaction
- define the possible rewards a customer may claim
- map an incoming transaction event to the appropriate outgoing notifications
You can create two types of Schemes in Imburse - Collect for collection and Payout for payment. Each of these types lets you set up at least one instance of Rules and Apps.
Imburse client lets you maintain multiple versions of a Scheme using Drafts. Drafts are copies of changes made to a Scheme's setup that you have saved. Define new setup for an active Scheme and save it as a Draft so that you can publish (or activate) that Draft later.
Rules explicitly control a Scheme. It defines the Apps to use for a set of currencies, countries, and collection/payout amount. Whenever there is an attempt to make a collection or payout, Imburse will match the Payout/Collect attributes (currencies, countries, and amount) against each Rules within the active Schemes and present the Apps associated with the matching Rules.
In the context of a Scheme, Rules will contain the Apps. You must assign at least an App to any Rule you create.
Collect Scheme lets you define the Rules for using Apps that Imburse client will present to your customers to collect payments from them.
Payout Scheme lets you define the Rules for using Apps that Imburse client will use to issue a payout to your customers.
right to be forgottenand deletes the encryption keys that protect the sensitive data, whenever the conditions specified by GDPR applies.
It is a unique customer reference code that should be mapped to a customer identifier on your side. It represents your customer on Imburse.
Financial Instruments represents a payment method owned by a customer. Examples of Financial Instrument would be a Credit Card number, Bank Account Number, mobile phone number, Direct Debit Mandate, or an Authorized Reward amount.
There are different ways to create these Financial Instruments, according to the type of operation and payment options desired to provide to the customer. If you use Imburse White Label Integration and incorporate our Checkout Component, the Financial Instrument for Card Payments is automatically generated within our systems.
Orders and Instructions represent an intention to Debit or Credit an amount. They hold all the necessary details that Imburse requires to process a collection or payout on your behalf.Debit or a Credit.
The Imburse platform supports two types of Transaction - Merchant initiated and Customer initiated. A Merchant initiated transaction is triggered by you whereas a Customer initiated transaction is triggered by your customer.
A transaction that deducts an amount of money from a customer's account.
A transaction that adds an amount of money to a customer's account.
Instruction refers to the details that defines the amount to process, the Financial Instrument to use and the nature of transaction (Debit or Credit). The Apps will use these details to process the transaction. |
An Order is a logical group of multiple instructions. Examples of a Order could be a policy, or a subscription.
Checkout component is a part of the Imburse's Whitelabel solution that features a UI where your customers will enter their card or bank details to make a payment or recieve a Rewards payout.
An encrypted string representing your intention for payment. This string holds the information of payment such as payment amount and currency of payment.
A set of properties used to style the Checkout component.
Imburse's unique offering, where a secure link is generated for you in return of your payment intention. If your customers click on this link, they will be directed to a page where they can enter their Financial Instrument details.
Chargeback is a state when your funds are forcibly reversed to your customer by an issuing bank because your customer claimed that a transaction shouldn't have occured in the first place. It is also known as claim, payment dispute, reversal, indemnity, or indemnity claim.
A chargeback is initiated by a customer's request to the bank and can occur for one of the following reasons:
- Fraud - Purchases that have been made without the customer's knowledge or consent
- Quality - Purchases that were paid for but haven't been received
- Clerical - Purchases that the customer has been billed for more than once, purchases that have been billed incorrectly, or refunds that haven't been issued
- Technical - Purchases that the customer doesn't have enough funds to cover, or bank errors
Refund refers to the action of returning the amount debited from a customer's account. It can occur for multiple reasons like inability to fulfil the order placed by a customer, change of customer's mind or incorrect billing.
Authentication is a mandatory security measure enforced by Imburse to prevent uuauthorized entities from making calls to Imburse API.Imburse APIs use Bearer tokens encoded as JSON Web Tokens (JWT) to autheticate API calls. To generate a Bearer token, you will have to call our
hmacendpoint using your Account ID, Tenant ID and a secret code.
API Key refers to the set of Public and Private Keys that Imburse APIs use to authorize the API requests you make. You will find two API Keys when you work with the Imburse Platform.
Account API Key is used to manage your account, its tenants, including Tenant API Keys through Imburse APIs.
Tenant API Key defines the role of a Tenant API user. Each user Role can have a different degree of control over the Tenant and its Marketplace, Schemes and Services.A Tenant Administrator (indicated as
tenant-admin), for instance, has a complete control of the tenant and can create other Tenant API Keys. Whereas, a user with
tenant-managementrole can only view the information of the Tenant. See the table below, for a list of available roles along with the functions they have access to.
|Function||Role Key for read-only access||Role Key for read-write access|
|All aspects of Tenant, including Users and Tenant API Keys|
HMAC is a secured and secret Authentication code used commonly with financial APIs. Imburse uses HMAC to generate Bearer tokens.
Before you make the call to Imburse APIs, you will have to create a unique HMAC using your Tenant API Keys (Public and Private). This HMAC is then shared with Imburse as a part of the API request. Upon receving your HMAC, we will generate our own HMAC and compare it with the HMAC you sent to us. If they match, we will know that the request is coming from the right person i.e., you.
See our dedicated GitHub page on HMAC to learn more about the technical aspects of HMAC, including the formula used to generate it.
Bearer token (also known as Access Token) is a cryptic string that Imburse uses to authorize your API requests.HMACs are extremely secure but are computationally expensive and slow. For that reason, we only use HMAC initially to generate and send secure Bearer token as a response to the
hmacendpoint call. Once you have received the Bearer token, you will have to use for API authentication for every subsequent calls that you make to Imburse APIs.
Webhooks, also known as Web Callbacks or an HTTP push API, is a way for an application to provide other applications with near real-time information.
Imburse uses Webhooks to provide you with near real-time notifications to your internal systems, such as when a payment is updated and settled, a mandate is registered, or a chargeback occurs.