Multi-product boarding

Applies to: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

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.

Create the linked application

Call POST /api/Boarding/applications with the existing paypointId and the templateId.

Auto-populate data

Payabli copies eligible paypoint data into the new application.

Merchant fills remaining details

The merchant completes any fields that are specific to the new service.

Submit for underwriting

The application goes through underwriting if the template requires it.

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.

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 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 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.

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.

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.

Retrieve applications for a paypoint

Use the Get multi-product boarding applications for a 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 for status code meanings.

Re-underwriting an existing paypoint

To re-underwrite a merchant with updated information:

Create a new application with the current paypointId.
Allow the merchant to update changed business information.
Submit for underwriting with the new data.
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.

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

References

Boarding statuses reference - Learn about statuses and substatuses during the merchant boarding process
Paypoint statuses - Learn about the different statuses of paypoints