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

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.

    When creditCheck is Approved

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

    1. 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.
    2. 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.

    1. 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.
    2. To complete the boarding administration, all documentation is uploaded to the Document Repository. Learn more about Uploading Documents on the Boarding page.
    3. 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.
    4. 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.

     

    Back to Top

    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.

     

     

    Back to Top

    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.

    Back to Top

    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:

    Back to Top

    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.

    Back to Top

    Related Content

     

    ❮ Back to Operations, Errors, and Codes