Use Case 3: Recurring payments
Problem
Automate the collection of monthly recurring premium
Insurers need to automatically collect monthly premiums from their customers across any payment method. This enables them to take the responsibility off customers and to avoid the administrative efforts of issuing invoices and tracking down late/non-payments. However, in order to do so, they require the flexibility to connect to multiple payment providers and methods. Single integrations to PSPs are complex, expensive, time-consuming and resource-draining, making it difficult for insurers to innovate.
Solution
The Imburse platform acts as your single access point to the payments ecosystem. Imburse does all the payment integration heavy-lifting, so you can access all relevant payment providers and methods to process recurring payments. Our platform is easily integrated with core insurance IT systems to seamlessly interoperate with existing billing processes. By integrating with Imburse your organization can automate the day-to-day operations of processing recurring payments.
Prerequisites
- Tenant Portal Access
- Valid API Keys
- Marketplace APP Installed and configured with relevant credentials
- Payout Scheme Created and configured
- Financial Instrument created
Supported Apps
- Citi
- BottomLine
- GoCardless
- Stripe
- BrainTree
- Checkout.com
- GlobalPayment
- SaferPay
- Westpac
Description
Step 1: Authenticate
The first step to using Imburse API is to authenticate yourself by generating an Access Token.
To learn more on how to authenticate, see Authentication.Step 2: Create Order and Instruction
API: Try it out in our API sandbox!POST:v1/order-management
- After successfully generating your Access Token, the remaining Imburse APIs are now available for use.
- To perfom a recurring Card Payments, the next step is to create an order and instruction/s, setting the payment intention and related information such as the amount and the SchemeID (which is fetched from the Tenant Portal, after creating the Scheme).
- When creating the instruction a Financial Instrument Id
financialInstrumentId
, created previously needs to be used in order to create a recurring payment. This Financial Instrument Id could be related to a Card or a Direct Debit Mandate.
Request example:
{
"orderRef": "order_Payout_01",
"instructions": [
{
"instructionRef": "PAYMENT-01",
"customerRef": "customer_01",
"direction": "DEBIT",
"financialInstrumentId": "9cb4aab7-5cbe-012c-c345-00c118e66696",
"amount": "10.00",
"currency": "GBP",
"country": "UK",
"schemeId": "62518C8474D3C5472DDCAF51C2136412",
"settledByDate": "2025-09-01",
"metadata": {
}
}
]
}
The following table lists all properties along with their type and description:
Property | Type | Required | Description |
---|---|---|---|
orderRef | string | Yes | A unique reference for an Order. Usually correlates to your customers order reference in you own internal systems.The orderRef property is set by Imburse client. |
instructionRef | string | Yes | A unique reference for an Instruction. For example, a month number.The instructionRef property is set by Imburse client. |
customerRef | string | Yes | A reference for your customer. If you are setting customerDefaults on the order then this will need to match a customerRef from the customerDefaults. The customerRef property is set by Imburse client. |
direction | string | Yes | The direction the instruction is for. Available values are CREDIT and DEBIT . Use DEBIT for Collections. |
schemeId | string | Yes | The schemeId this order should use to filter available payment options. |
settledByDate | date | No | The date in which a payment is to be settled by, or if automated, will be taken on. Date format is YYYY-MM-DD . After this date Imburse would send you missed payment webhook notifications. |