Default offer creation
Lets take an example payload to the /offers endpoint:
Request
{
"application": {
"merchant_id": "PO12345",
"intended_use_of_funds": "Purchase Stock",
"currency": "GBP",
},
"consents": {...},
"applicants": [{}],
"company": {...}
}
The above request payload will return a 'default' response from the endpoint. The response will contain a list of products and their respective offers, of which there should be between 1 and 3 due to the default 'apply_offer_presets' being set to true if omitted in the request payload:
Response
{
"products": [
{
"product_id": "aeb18063-fcae-4151-997e-ec965aaf4f60",
"name": "BCA",
"description": "Business cash advance, repay in line with your revenue.",
"decision": "Accepted",
"repayment_mechanism": "Terminal Split",
"limits": {
"minimum": 5000.00,
"maximum": 25000.00
},
"offers": [
{...},
{...},
{...}
]
}
]
}
This response is useful for more concise user experiences where clients simply want to display a small number of options to a Merchant and limit their UI build out.
An example of this UI type
Getting indicative offers
The Liberis Create API can also return offers for merchants that either have less than 4 months of revenue data , or self declared revenue. In this case the application will be subject to more stringent checks, including open banking or bank statements verification prior to funding, and the offer returned from the API is subject to change depending on the result of these checks.
To enable this type of application, you must provide merchant revenue information via the API whilst stating the value is indicative by using the boolean field present on a revenue item.
In this example. a merchant has applied via Liberis Create while stating their own revenue in a UI component similar to the below.
In order to gather quotes for the merchant and progress their application, you should call the /offers endpoint with the following payload:
Request
{
"application": {
"merchant_id": "PO12345",
"intended_use_of_funds": "Purchase Stock",
"currency": "GBP",
},
"consents": {...},
"applicants": [{}],
"company": {
...
"monthly_revenues": [
{
"date": "previous month in YYYY-MM",
"amount": 5000,
"count": 1,
"currency": "GBP",
"indicative": true
}
}
}
We have mapped the amount specified by the merchant to a single monthly volume and set it against the previous months date in YYYY-MM format. As this value is self declared we have marked the revenue item as indicative. Liberis will then mark an application as indicative and will be checked more thoroughly to verify the merchants revenue, however the rest of the application process will continue as our normal application flow.
Offer Expiry
An application and set of offers have a set expiry set at the point of creation. When attempting to create offers, we will check if an application already exists for the merchant_id submitted in the request. If that application / offer set has expired, the request will return a 404 and a new application will need to be submitted. If using our auto decisioning, this means a credit check will be executed on the merchants consumer file for a second time.
This implies partners should ideally keep track of this expiry after an initial set of offers is created rather than relying on the endpoint returning a 404 to control a process.
