Elavon downloads and stores cookies on your device when you visit our website. We use these cookies to better understand and improve your browsing experience by identifying most visited pages, personalising content, and measuring site performance.

Essential cookies enable core functionality such as page navigation and access to secure areas. The website cannot function properly without these cookies; they can only be disabled by changing your browser preferences.

Performance cookies help us to improve our website by collecting and reporting information on its usage (for example, which of our pages are most frequently visited).

Cookie Settings

Elavon Financial Services DAC. Registered in Ireland – Number 418442.
Registered Office: Block F1, Cherrywood Business Park, Dublin 18, D18 W2X7, Ireland.
Elavon Financial Services DAC, trading as Elavon Merchant Services, is regulated by the Central Bank of Ireland.
 
Elavon Financial Services DAC. Registered in Ireland with Companies Registration Office. The liability of the member is limited. United Kingdom branch registered in England and Wales under the number BR022122.
Elavon Financial Services DAC, trading as Elavon Merchant Services, is a credit institution authorised and regulated by the Central Bank of Ireland.  Authorised by the Prudential Regulation Authority.  Subject to regulation by the Financial Conduct Authority and limited regulation by the Prudential Regulation Authority.  Details about the extent of our regulation by the Prudential Regulation Authority are available from us on request.

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


::image{id="/content/dam/developer-portal-solutions/en-us/elavon/media/images/products/eboarding/partner_process_flow_1.png"   alt="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.
    - If the data doesn't pass, an error is sent back to the partner.
    - The partner makes corrections and resubmits their application.
3. Once PAPI determines that the data has passed (i.e. 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.
    - 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.
    - If yes, an Application ID is generated (AWB for North America or MID for Europe).
    - If no, AEP will return an error to the partner (via GBAPI and PAPI).
7. The partner receives the response.
    - If the response is an error message, then the partner makes application corrections and resubmits their application.
    - 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.
    - If auto-approved, no additional supporting documentation is required from the partner. An approval status will be returned.
    - If declined, a declined status will be returned.
    - 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.  


::image{id="/content/dam/developer-portal-solutions/en-us/elavon/media/images/products/eboarding/partner_process_flow_2.png"   alt="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).
4. 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.
5. 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 :magic-link[Push Notifications]{id="push-notifications"}.

Boarding Process Workflows

Alliance Offers

Data as a Service

Invitation to Apply

Accounts

Bank Holidays

Card Activation

Card Controls

Commercial Credit Cards

Credit Card Account Details

Credit Card Accounts Overview

Credit Card Alerts

Credit Card Application Status

Credit Card APRs

Credit Card Disputes - Coming Soon

Credit Card Payments

Credit Card Qualified Offers

Credit Card Statements

Credit Card Transactions

Data Sharing for Marketing Purposes

Digital Wallets

Make a Payment - Coming Soon

Rewards Accelerator

Rewards Automatic Redemption

Rewards: Balance Summary

Rewards Redemption - Coming Soon

Rewards Redemption Accounts

Rewards Redemptions

Rewards Transactions Earned and Redeemed

Travel Notifications

User Profile

3DSecure2

Avvance

CheckoutJs

Commerce SDK

Converge

Disputes Management

Dynamic Currency Conversion

eBoarding

Elavon Cloud Payments Interface

Elavon Payment Gateway

Fusebox

Hosted Payment Page

In Person Payments on Opayo

Leads

Lightbox payment modal

Online Payments on Opayo

Opayo

Opayo Direct

Opayo Forms

Opayo Reporting API

Opayo Server

Opayo Shared API

Payment Method Gateway

Payments Core 365

Simplify

viaconex

XML API

Access Online Transactions

Account Transfers

Account Validation

ACH Originations

Bank Information

Card as a Service

Card as a Service API

Check Payables

Core Banking API

Corporate Account Information

Corporate Credit Cards

Corporate Onboarding

Corporate Statements

Custody

Data Toolbox

Data Toolbox - Accounts

Data Toolbox - Documents

Data Toolbox - Transactions

Disbursements via Zelle®

U.S. Bank Flexible Capital Platform

Freight Payment Customer Profiles

Freight Payment Transactions

Instant Payments

Investment Accounting

Money Movement API

PaySmart

Payee Choice

Payee Token+

Personal Loans

Positive Pay

Push to Card

Receivables

Reference API

RTP® - Real-Time Payments

Tokenized Payments

Treasury Builder

U.S. Bank FBO Account

Virtual Account Reporting

Virtual Card Payments

Voyager Accounts

Voyager Cards

Voyager Drivers

Voyager Transactions

Voyager Vehicles

Wire Transfers

eBoarding Partner API Overview

Integration by flow type

Boarding process workflows

Main boarding elements

Passing data to board

Principal applicant

Additional shareholders

Contact information

Financial information

Card pricing

Bank account information

Billing

Fees

Payment processing equipment

Dynamic currency conversion (DCC)

Value added services

Third-party signing

Complementary API calls

API reference

Element code tables

Merchant category codes

Boarding timeouts

Push notifications

Best practices

Release notes

2024

2023

2022

2021

2020