Boarding

When document signing is completed in the Managed Flow, construct the boarding POST including the document packet ID.

On this page:

Document Upload

Contractual documents are automatically uploaded to the document repository when:

  • Your implementation requires it, and
  • The boarding parameters include the document packet ID.

When required, supporting documents are uploaded separately using the uploadDocuments POST.

Top Level Boarding Parameters

The following table lists a selection of the top-level parameters that comprise the boarding POST. Boarding and creditCheck operations use many of the same parameters. Only new parameters are listed in the table.

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.

Boarding data

Element

Description

DynamicCurrencyConversion

Dynamic Currency Conversion (DCC) is optional for boarding as a business may not engage in DCC.

BillingStatement

How the business prefers to receive billing information.

FundingStatement

Optionally, how the business prefers to receive funding information.

ElectronicStatement

How the business would prefer to receive electronic statements.

valueAddedInfo

Optionally, the value-added services applied to the application.

EquipmentInfo

Optional equipment managed by Elavon.

fees

The amount, quantity, frequency, and type of fees. Each section creates a separate fee product.

SiteSurvey

An assessment of business resources and capacity.

contact

This uses the same elements as the Credit Check Flow's contactInfo, passing all the information needed to connect with the merchant personally including:

  • Address
  • Phone number
  • Email address

This information may be different from their residence, business, or legal information.

Credit Check

When boarding an application, the credit system performs a Credit Check.

Our Credit Check service validates your merchant customer's status against Elavon's Credit Policy in only a few moments. Data parsed includes their business, personal, and banking information. The result affects the application’s approval.

If more information is required to approve the creditCheck, then the customer is prompted to provide it.

Request a Boarding Application Status

You can use the API to check on the boarding status. The boardstatus POST is detailed in the Boarding Status section of the API Reference. The required parameters are listed in the following table.

Boarding Status Request parameters

Element

Description

boardingId

In the EU, this is the Merchant ID returned within a successful boarding response.

clientId

The Elavon-provided client identifier of the individual being status checked. It should match value present on boarding request.

uniqueId

An alphanumeric value that identifies the status request. It must be wholly original and never repeated for subsequent applications. An example is the Partner's name followed by a millisecond timestamp: 'AcmeCorp1572566399123'.

country

The country in which the client operates using ISO 3166-1 alpha-3. It should match value present on boarding request.

salesRepCode

Identifying the sales representative boarding the customer. It should match value present on boarding request.

 

When there are no errors, the response contains the applicationID and the boarding status. 

boardingStatus Values

Status

Description

COMPLETE

The application is complete, opened, and free to transact.

INPROGRESS

(EU) The application is in progress. Try again later.

PEND

(NA) Pending. The application is in progress. Try again later.

DECLINED

The application is declined.

WITHDRAWN

The application has been closed and is stopped from transacting.

TIMED_OUT

(EU implementations only). Typical of connection issues. Refer to the Boarding Timeouts section.

ERROR

Typical of connection issues. Refer to the Error Messages section for common errors, and then try again.

UNKNOWN

Status is unknown at this time.

 

Boarding Timeouts

A timeout or delay in returning a MID may occur when:

  • The application is a duplicate and, or the uniqueId is not unique.
  • New eBoarding software is being deployed.
  • There is a temporary system malfunction.

Depending on your implementation, the API will resubmit timed-out applications automatically. In others, when a MID is not returned within 180 seconds, resubmit applications using the same uniqueId and as follows for an EU or NA implementation. 

For help, reference error logs and, or consult with your Solutions Engineering Team.

For EU implementations

  1. First retry after 180 seconds.
  2. Then retry every 15 minutes for 4 hours.
  3. Then retry every 60 minutes for 72 hours.

For NA implementations

  1. First retry after 90 seconds.
  2. Then retry every 15 minutes for 4 hours.
  3. Then retry every 60 minutes for 72 hours

Avoiding Duplicate Applications or uniqueId

You must ensure each application uniqueId is unique and never repeated. We recommend using the partner's name followed by a millisecond timestamp.

Example. AcmeCorp1572566399123

Edits and Errors

You must update the uniqueId for each boarding attempt when:

  • Editing a submitted application, or
  • An error is reported.

In this example, the second attempt adds a hyphen and figure one to the end of the uniqueId.

Example. AcmeCorp1572566399123-1

Related Content

 

❮ Back to Document Signing Next: Push Notifications ❯