Lender Integrations - Credit Cards

General

This documentation applies to Credit Card Integrations with 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: staging and production. The domains designated for communication within these environments are outlined in the table below:

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

Remember to whitelist these IPs if your system utilises this security feature.

Integration

We have two options for providing support for push style callbacks. The first is to send requests to our Core APIs which is a generic API that allows you to map your data to our data. The second it to send requests to our Lender Specific APIs where we map out data to your data.

Core APIs

The only API of significance for you as a lender is the Loan Request Aggregator. To access this API, you need a bearer token. Information on how to obtains this token can be found in the authentication guide.

The following endpoints is the only endpoints you as a lender will be granted access to. They all serve the singular purpose of updating the application and assigning it a certain status.

• approved-by-bank - Used to approve the application, and set the terms you're willing to provide. This endpoint is flexible regarding the information given in the payload. Fields we are interested in for credit cards is the following:
  • Amount - Also known as the credit limit, must be included.
  • EffectiveRate - We can also set this to a static value for all credit cards from you.
  • SigningLink - We can optionally receive this when the customer accepts the credit card.
• not-approved-by-bank - Used to reject the application. This can be used both when initially rejecting an application, or when rejecting an initially approved application at a later time.
• cancel-by-bank - Used to cancel the application. Note the semantic difference between rejecting and cancelling.
• disbursed-by-bank - Used to set the status of the application to disbursed.

Lender Specific APIs

These APIs are individually tailored to support your generic callback setup. The specification of this API is mainly decided by you, the lender. Providing us documentation, OpenAPI specifications and example payloads will help us greatly when implementing this API.

URL

The route parameter "ID" is generated by us and remains constant for lenders in both the test and production environments. We will provide this ID at your request. Feel free to append paths to the end of the base URL if your integration requires it. Eg. <https://integration.axo-test.io/lenders/{ID}/callbacks/approve>

Authentication

Authentication and payload are customised to suit each integration's unique requirements. Therefore, callbacks can accommodate various authentication methods and payload formats. If you do not have a specific preference for the authentication method, we recommend using bearer tokens provided by us. Information on how to obtain this token can be found in the authentication guide.

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

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-organised 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 of 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.