Lender Integrations - Consumer Loans

General

Welcome to the Axo Group lender Integration documentation. This documentation applies to Consumer Loan lender Integrations done to the following Axo Group brands:

The documentation is general for all countries, but certain parts can vary a bit per country.

Environments

Currently, we offer two distinct environments: test and production. The domains designated for communication within these environments are outlined in the table below:

Any requests initiated by us to lenders will originate from the following IP addresses:

Collaboration

The typical communication channels that are used during integration setup are Slack, Teams or Mail. Ideally, we opt for Slack or Teams due to their collaborative nature, offering a well-organized record of decisions made, which remains accessible to all stakeholders engaged in the integration process.

Testing

We have the same technical setup for our testing environment as we have in the production environment. This enables us to test the complete integration from start to end. For testing we use predefined test cases but can also adapt those depending on the lender’s requirements for different cases. We do systematic testing to the integration, including the data field mapping and application flow. Parts of the testing process requires collaboration with the lender to ensure proper integration, such as correct data flow.

Integration

Custom

Our "custom" integrations are individually tailored, involving callbacks that are specifically developed for each lender. The details of these integrations differ and are mutually agreed upon.

The callback URI remains consistent across all custom integrations. The following table displays the URIs that lenders are required to use when sending us custom callbacks. The route parameter "ID" is generated by us and remains constant for lenders in both the test and production environments.

In cases where lenders send callbacks to their predefined routes, such as applications/12/reject, the complete route for the callback in the testing environment would be: https://integration.axo-test.io/lenders/{ID}/callbacks/applications/12/reject.

Authentication and payload are customized to suit each integration's unique requirements. Therefore, callbacks can accommodate various authentication methods and payload formats, which must be implemented for each integration. If a lender lacks a specific preference for the authentication method, we recommend securing our endpoints with tokens issued by our Identity Provider (IDP).

To access the Identity Provider (IDP), please contact the designated individual responsible for the integration. They will provide you with a persistent token. For detailed instructions on obtaining a token, please refer to the provided default callback recipe.

Aggregators

The term "Aggregators" is an in-house term referring to APIs that function as abstractions. These APIs unify various components and perform multiple operations. They operate independently of databases and internal states. Instead, they forward requests to services or APIs. Typically, these aggregators are protected by our proprietary authentication mechanisms, necessitating a token provided by our Identity Provider (IDP).

the only aggregator of significance for lenders is the loan request aggregator, which is accessible in the API reference section. By comparing the aggregator with a custom integration, the aggregator has predefined methods with specific payload and authentication mechanism.

• Loan Request / Application
  • approved-by-bank - updates the loan application status to "approved by bank." This endpoint is applicable once a loan application has been issued from us to the lender.
  • not-approved-by-bank - changes the loan application status to "not approved by the bank." An input parameter reason is required, providing an predefined enum for the application's rejection. This endpoint is applicable once a loan application has been issued from us to the lender.
  • cancel-by-bank - sets the loan application status to cancel. This endpoint is applicable once a loan application has been issued from us to the lender.
  • disbursed-by-bank - Updates the loan application status to disbursed. Should be used after the loan application has been disbursed.

Mapping

For defining the data field mapping required for integration the lenders are required to provide documentation that includes the following details:

• Data structures
• Data fields
• Field name
• Data type
• Description
• Enums
• Mandatory or optional
• Example

Additionally, we highly if lender can provide us with any API specifications or schemas if available. Based on the documentation shared by the lender, we typically map our data fields to match the lender’s, depends on the requirement for the integration.