Boarding Process Workflows

The following diagrams show the process, relevant APIs, and systems involved in the boarding workflow.

boarding-process-diagram

Process Flow for Boarding an Application

  1. First, the partner sends a Boarding Request to the Partner eBoarding API (PAPI).
  2. PAPI inspects the application data for required fields and correct formatting.
    1. If the data doesn't pass, an error is sent back to the partner.
    2. The partner makes corrections and resubmits their application.
  3. Once PAPI determines that the data has passed (ie. required fields are present and format is correct), the application is passed to the Global Boarding API (GBAPI).
  4. GBAPI receives the application and transforms data if needed.
    1. If the data doesn't pass, an error is sent back to the partner, who will make corrections and resend the application.
  5. Once GBAPI determines everything is correct, it passes the application to Elavon's Application Entry Portal (AEP).
  6. AEP receives the application and determines if the application is valid.
    1. If yes, an Application ID is generated (AWB for North America or MID for Europe).
    2. If no, AEP will return an error to the partner (via GBAPI and PAPI).
  7. The partner receives the response.
    1. If the response is an error message, then the partner makes application corrections and resubmits their application.
    2. If the response is the AWB (for North America) or MID (for Europe), then the partner is responsible for sending any required supporting documents to PAPI.
  8. PAPI receives supporting documents and sends the data to downstream systems.
  9. At this point, the application is put into the Elavon review process. The application may or may not be auto-approved.
    1. If auto-approved, no additional supporting documentation is required from the partner. An approval status will be returned.
    2. If declined, a declined status will be returned.
    3. If not auto-approved, then the application goes to a manual review process. If the operations or underwriting teams require additional information, a PEND status will be returned with a note of what needs to be corrected. At this point, a partner team will need to contact the customer to collect the missing data and make any necessary changes.

Process Flow for Checking the Status of an Application

After successfully submitting an application, the partner may want to find out the status of their application. Application statuses may be polled or pushed to a partner. Either way, the same data is available. Each partner needs to decide which method works best for them.

polling-application-status-diagram

Polling for Status

  1. First, the partner sends a request to the Partner eBoarding API (PAPI) to request the status of their application.
  2. PAPI forwards the request through Global Boarding API (GBAPI) to Elavon's Application Entry Portal (AEP).
  3. AEP receives the request and returns the application status back via the same path. Status responses can be: COMPLETE, INPROGRESS, DECLINED, WITHDRAWN, ERROR, TIMED_OUT, or PEND.
  4. Depending on the state and condition of the application, the status will also contain ERROR reasons, PEND reasons, underwriter contact information, and if APPROVED, point-of-sale configuration information.

Pushing for Status

If a partner wishes to receive the same information via push messaging, Elavon will work with the partner to collect partner end-point(s) and to choose the authorization method. For more information, see Push Notifications.