Credit Checks Using a Stateless Flow

When implementing our recommended Guided or Managed (Stateful) flows, the eBoarding API manages the Credit Check process for you. When managing a legacy implementation or in exceptional circumstances an Unassisted (Stateless) implementation, you must construct the Credit Check.

On this page:

About the Stateless Credit Check
Construct and POST the Application
The creditCheck Parameters
Encoded Values
Automation
Credit Check Responses

About the Stateless Credit Check

The stateless Credit Check flow starts when you construct and POST the application. Whether approved immediately or referred for further scrutiny, the Credit Check returns a creditCheck Token. All data including the token must remain unchanged between the Credit and Boarding systems.

The API Reference | Credit Check section lists endpoints, example requests, and responses. Some creditCheck operations are labelled as specific to the European (EU) or North American (NA) markets

Important. When more than one Path Parameter versionNumber is available, always use the latest version. For example, when versions 1 to 4 are available, use v4.

Construct and POST the Application

Construct and POST the application through creditCheck. We take pride in validating the Credit Check and returning a decision in the shortest time possible.

Stateless Flow Credit Check diagram

When creditCheck is Approved

When the creditCheck is approved (returned as, ‘APPROVAL_STAGING’), a secure creditCheck token is issued ready for boarding.

Stateless Flow Credit Check Approved diagram

Construct a Boarding POST to include the creditCheck Token
- The boarding operation transfers all the information required to board your merchant customer together with the creditCheck Token.
- On receipt, and as the creditCheck was approved, the Boarding Platform automatically creates a record.
Upload all supporting documentation to the document repository
- To complete the boarding administration, all documentation is uploaded to the Document Repository.
- When confirmed uploaded, go to Step 5.

Boarding data requirements are detailed in the Boarding section. The exact composition will depend on your unique implementation.

When creditCheck is Referred

When the creditCheck decision is referred (returned as a, ‘CONDITIONAL_APPROVAL’), a secure creditCheck token is issued ready for boarding although boarding will not complete before the creditCheck decision is approved.

Stateless Flow Credit Check Referred diagram

Construct a Boarding POST to include the creditCheck Token. The boarding operation transfers all the information required to board your merchant customer together with the creditCheck Token. Boarding data requirements are detailed on the Boarding page. The exact composition will depend on your unique implementation.
To complete the boarding administration, all documentation is uploaded to the Document Repository. Learn more about Uploading Documents on the Boarding page.
When the creditCheck decision is approved, the Credit System record is updated manually by Elavon Staff and the Boarding System record is updated automatically. Go to Step 5.
If more information is required to approve the creditCheck, then the customer is prompted to provide it.

If the creditCheck is DECLINED or WITHDRAWN

If the referred creditCheck decision is DECLINED or WITHDRAWN, then you and your customer will be informed.

creditCheck Parameters

The stateless Credit Check and Boarding operations share some parameters. Top-level parameters required completed for the creditCheck are outlined and linked to in the following table. The table is a guide. Always refer to the API Reference.

creditCheck parameters

Element	Description
principal	The principal object list includes details of the individual responsible for card processing services on behalf of the merchant’s business.
BusinessInfo	The BusinessInfo object streamline and inform the application approval and compliance process. It includes key information including: Legality Function Products Ownership Longevity
FinancialInfo	FinancialInfo object include financial information related to the merchant’s business, how payments are processed, and what affects the process.
additionalShareholders	When the principal is not the sole owner of the company, information is required for each shareholder with a 25% or greater interest in the business. The parameters are a clone of principal and wrap each shareholder instance. Refer to the additionalShareholders model in the API Reference.
CardPricing	A chargeCard record must be created for each card type your merchant customer plans to accept.
bankAccounts	DEPOSIT is the only valid bank account type in the EU region. All related business bank account information is required for boarding.

Encoded Values

Find the required encoded values listed on the General Element Codes page. These include codes for:

Countries and States
Languages
Types of ownership.

You can also lookup Merchant Category Codes.

Automation

The eBoarding API includes calls to automate data validation. The following links are to the POST and GET calls in the API Reference | Credit Check section:

Credit Check Responses

A successful Credit Check returns the creditCheck Token required for boarding.

Usage	Decision	Meaning
Decision Type	APPROVAL_STAGING	APPROVED. Proceed the application to Boarding with the creditCheck token.
	CONDITIONAL_APPROVAL	The creditCheck has been referred for additional checking. Proceed the application to Boarding with the creditCheck token. Boarding will not complete before the creditCheck decision is approved.
	DECLINE	DECLINED. The application cannot proceed further.
Internal Use	RMU Staging	For internal use when defining a type of CONDITIONAL_APPROVAL.
	SMU Staging	For internal use when defining a type of CONDITIONAL_APPROVAL.

Tip. When testing in the Demo environment, you can use one of the Credit Check response codes as the principle's middle name to return that response. Leaving the middle name field blank returns the successful APPROVAL_STAGING response.