> This is Payabli documentation. For a complete page index, fetch https://docs.payabli.com/llms.txt — append .md to any page URL for lightweight markdown. For section-level indexes, query parameters, and other AI-optimized access methods, see https://docs.payabli.com/ai-agents.md

# Multi-product boarding

> Add new services to an existing paypoint by linking a new boarding application

<AudienceInfo audiences={['developers']} />

Multi-product boarding lets you add new services to an existing paypoint by creating a boarding application that's linked to that paypoint. The new application copies eligible data from the paypoint, runs the new services through underwriting if needed, and merges approved data back to the paypoint without disrupting active services.

## When to use this flow

There are several situations where multi-product boarding can help you:

* **Progressive service adoption**: A merchant starts with Pay Out and later adds Pay In as their business grows.
* **Service expansion**: A merchant with basic payment processing wants to add additional payment methods.
* **Re-underwriting**: Update merchant information and trigger underwriting for new services while keeping the existing paypoint.
* **Pricing changes**: Have the merchant agree to new pricing, then apply the configuration changes to the existing paypoint.

## Supported services

You can use multi-product boarding to add the following services to an existing paypoint:

* **Pay In**: Card and wallets, ACH
* **Pay Out**: ACH, virtual cards, Check, Real Time Payments (RTP), Wire, ghost cards, and managed payables

The template you use must include only services the merchant doesn't already have on the paypoint. Templates that overlap with active services aren't supported and cause the application to fail.

## How data mapping works

When you create an application linked to an existing paypoint, the system copies eligible field values from the paypoint to the new application based on 1:1 field matching:

* **Business information**: Legal name, DBA, business type, registration details
* **Contact information**: Primary contact name, email, phone number
* **Banking details**: Bank account information, where applicable
* **Address data**: Physical and mailing addresses

The merchant only needs to provide fields that are specific to the new service. By default, the application is pre-populated with existing paypoint data and the merchant can update fields before submitting. If you don't want merchants to refresh or modify their KYC or KYB information, ask the Payabli team to restrict that capability when they configure the template.

## Parent-child relationship

The application keeps two reference fields that link it to the parent paypoint:

| Field        | Description                                             |
| ------------ | ------------------------------------------------------- |
| `paypointId` | References the existing paypoint                        |
| `entryId`    | References the original entry that created the paypoint |

This relationship makes sure that adding services doesn't create a duplicate paypoint for your merchant. New application data merges back to the existing paypoint after approval, and you can query all applications associated with a specific paypoint.

After the new application passes underwriting, Payabli merges approved data into the existing paypoint and activates the new services. Existing active services are preserved. Only the new services being added are targeted during boarding. For asynchronous processors, service activation completes after the processor confirms boarding, and the application status updates when the confirmation arrives.

## Boarding flow

<Steps>
  <Step title="Set up a template">
    Work with the Payabli team to set up a boarding template that includes only the services you want to add to the paypoint, plus an underwriting flow if needed.
  </Step>

  <Step title="Create the linked application">
    Call `POST /api/Boarding/applications` with the existing `paypointId` and the `templateId`.
  </Step>

  <Step title="Auto-populate data">
    Payabli copies eligible paypoint data into the new application.
  </Step>

  <Step title="Merchant fills remaining details">
    The merchant completes any fields that are specific to the new service.
  </Step>

  <Step title="Submit for underwriting">
    The application goes through underwriting if the template requires it.
  </Step>

  <Step title="Merge and activate">
    After approval, Payabli merges new data into the existing paypoint and activates the new services without disrupting the services that are already active.
  </Step>
</Steps>

## Configuring templates

Multi-product boarding templates aren't a self-service process. The Payabli team sets up templates for you based on the services you want to add. Reach out to the Payabli team to get started.

Each template covers one service combination, with separate templates for each set of new services being added. This keeps underwriting flows clean and prevents the system from trying to activate services the merchant already has.

For example, you might have:

* **Pay Out template**: Pay Out Bank enabled, with underwriting bypass for bulk conversions.
* **Pay In template**: Pay In services enabled, with automatic underwriting and policy credentials.

The Payabli team can bypass underwriting for a service by configuring the template with an underwriting bypass. This is useful for scenarios like Pay Out bulk conversions. For services that require underwriting, the template runs the full automated underwriting flow.

## Create an application from an existing paypoint

Use the [Create multi-product boarding application](/developers/api-reference/boarding/create-multi-product-boarding-application) endpoint to create a new boarding application that's linked to an existing paypoint. See the API reference for the full request, response, and parameter details.

A few behaviors to know when calling this endpoint:

* Only one open application per paypoint is allowed at any time. An application is "open" if it's in any non-terminal status, such as `NotSubmitted`, `PendingSignature`, `Underwriting`, or `Boarding`. Wait for the current application to reach a terminal status (`Approved`, `Declined`, or `Withdrawn`) before creating a new one. See [Boarding statuses reference](/guides/pay-ops-boarding-status-reference) for the full status list.
* `recipientEmail` is required. If you don't want Payabli to email the merchant, send to an internal address (like one of your team's emails) and set `returnBoardingAccessInfoInLine` to `true` to retrieve the boarding link directly from the response.
* Pass `submitApplication` in the `onCreate` array to automatically submit the application on creation. This skips the draft state and triggers underwriting immediately, without requiring the merchant to submit manually.

<Warning>
  Always check 

  `isSuccess`

   in the response before proceeding. A 

  `false`

   value means the application wasn't created. Common causes include an open application already existing for the paypoint (

  `409`

   conflict), an invalid 

  `paypointId`

  , or an invalid 

  `templateId`

  .
</Warning>

The successful response returns an `appId` and a `boardingLink`. Use these to:

* Send the boarding link to the merchant or display it in your UI
* Monitor underwriting progress for the application
* Track when the new services activate
* Retrieve application details for reporting

To stay informed of underwriting and boarding status changes without polling, configure [boarding webhooks](/guides/pay-ops-developer-notifications-manage).

## Retrieve applications for a paypoint

Use the [Get multi-product boarding applications for a paypoint](/developers/api-reference/boarding/get-multi-product-boarding-applications-by-paypoint) endpoint to retrieve all boarding applications associated with a specific paypoint. This is useful for tracking underwriting progress across multiple service additions or building reporting views in your UI.

The response includes all merchant data captured on each application, including owner data, signer information, banking details, and the boarding event timeline. Use the `boardingStatus` and `boardingSubStatus` fields on each record to track where each application is in the boarding lifecycle. See [Boarding statuses reference](/guides/pay-ops-boarding-status-reference) for status code meanings.

## Re-underwriting an existing paypoint

To re-underwrite a merchant with updated information:

1. Create a new application with the current `paypointId`.
2. Allow the merchant to update changed business information.
3. Submit for underwriting with the new data.
4. After approval, Payabli merges the changes back to the paypoint.

This approach maintains a full audit trail of underwriting decisions while keeping a single paypoint record. The merchant can update their business information as part of this flow, and the updated data merges back to the existing paypoint after approval.

## Related resources

See these related resources to help you get the most out of Payabli.

<AccordionGroup>
  <Accordion title="References">
    * **[Boarding statuses reference](/guides/pay-ops-boarding-status-reference)** - Learn about statuses and substatuses during the merchant boarding process
    * **[Paypoint statuses](/guides/pay-ops-paypoint-status-reference)** - Learn about the different statuses of paypoints
  </Accordion>

  <Accordion title="Related topics">
    * **[Boarding overview](/guides/pay-ops-boarding-overview)** - Learn how merchant boarding works in Payabli
    * **[Manage notifications](/guides/pay-ops-developer-notifications-manage)** - Learn how to use the Payabli API to add notifications and automated reports for important events
    * **[Create multi-product boarding application](/developers/api-reference/boarding/create-multi-product-boarding-application)** - API reference for the endpoint that creates a boarding application linked to an existing paypoint
    * **[Get multi-product boarding applications for a paypoint](/developers/api-reference/boarding/get-multi-product-boarding-applications-by-paypoint)** - API reference for retrieving all boarding applications associated with a paypoint
  </Accordion>
</AccordionGroup>