> ## Documentation Index
> Fetch the complete documentation index at: https://docs.payhub.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Boarding Status Overview

> Track the progress of a merchant board, whichever processor ran it

Boarding status reports how far a merchant board has got for an application, in the same shape regardless of which processor ran it — so a client can render one progress view for all of them. The step count differs by processor: SAM boards report five steps, TSYS boards three.

Reading the status never starts or retries a board.

| Endpoint | Description |
| - | - |
| [Get boarding status](/api-reference/leads/get-lead-boarding-status) | Retrieve the progress of a merchant board for an application |

## Acting on `status`

The `status` field is what decides whether a retry is safe:

<CardGroup cols={2}>
  <Card title="not_started" icon="circle-dashed">
    The application has never been boarded, and `processor` is null.
  </Card>

  <Card title="failed" icon="circle-x">
    Safe to retry once the underlying problem is fixed.
  </Card>

  <Card title="reconciliation_required" icon="triangle-alert">
    A merchant may already exist at the processor. A human must reconcile before anything else is attempted.
  </Card>
</CardGroup>

<Warning>
  Never retry a board reporting `reconciliation_required`. Unlike `failed`, it means the processor may already hold a merchant for this application, and boarding again risks creating a second one.
</Warning>

## Showing the reason to a user

For a `failed` board, `dataIssues` describes what about the application would currently stop it boarding. It is composed server-side from field names and fixed text, so it is safe to display directly. It is empty for every other state.

The raw processor error is deliberately never returned — it can echo submitted application data.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.