Multi-Connection Boarding Forms

When you board a merchant, Preczn gives you two ways to structure the form:

• A single-connection form collects everything needed to onboard the merchant to one fintech connection. This is the right choice when a merchant only needs to be set up on one fintech provider, or when each provider has a fundamentally different experience and you want to keep the flows separate.
• A multi-connection form collects everything needed to onboard the merchant to several fintech connections at the same time. The merchant fills out shared business, ownership, and banking information once, accepts each connection's Terms & Conditions, and is boarded to every connection on submit.

Fintech connections cover the full set of providers a platform can route through — payment processors, lenders, card issuers, banking providers, and more — and that list will continue to grow over time. Both options use the same hosted form, the same template system, and the same POST /v1/forms endpoint. The difference is whether you pass one connection or several when you create the form.

Which Form Should I Use?

Use a single-connection form when:

• The merchant only needs to be live on one fintech connection.
• Different connections are rolled out at different points in the merchant's lifecycle (for example, add card processing now, add financing later).
• Different connections have meaningfully different operational owners and you want each onboarding flow to live on its own.

Use a multi-connection form when:

• The merchant needs to be set up on more than one connection at the same time.
• You want to offer the merchant a single consolidated form for multiple services — for example, signing them up for payments processing and lending at the same time — instead of sending them through a separate form for each.
• The acceptance experience matters: completing one form and accepting two sets of terms feels like a single decision; completing two separate forms feels like extra paperwork.

The benefit of a multi-connection form is convenience, not data preservation. Merchant's information — business details, ownership, banking, attachments — is saved on the merchant record after any boarding form is submitted, so a merchant who fills out a single-connection form today and is added to another connection later won't be re-typing the bulk of their information. Multi-connection just collapses that into a single submission when you already know the merchant needs more than one connection.

If you're unsure, default to a single-connection form. You can always add another connection later through a separate boarding form.

What the Merchant Sees

Most of a multi-connection form looks identical to a single-connection form. The merchant fills out one set of business information, one set of owner information, one set of banking information, and uploads one set of attachments — Preczn computes the combined requirements across the selected connections, so a field is requested if any of the connections needs it. The merchant never sees a per-connection requirements list.

After the shared steps, the form gives each connection its own step, in the order the connections appear in the form's processorNames. A connection's step holds what the merchant completes for that connection, such as its Terms & Conditions or its contacts. Review comes last.

• A connection with one step shows as a single step named after the connection, for example Ramp.
• A connection with two or more steps lists them as substeps under the connection's name, for example GreenSky with Terms & Conditions and Contacts. The substeps expand while the merchant is on one of them.
• A connection with nothing to complete on the form doesn't appear. For example, Jaris adds no step.

Some of these steps appear only when the form is configured for them:

• Terms & Conditions appears when the form shows terms (displayTos).
• Account Login appears when displayNewUserLogin is on.
• PCI Compliance appears when displayPciSaq is on.
• ACH Setup appears when the form collects locations and requires Jack Henry's ACH limits for them.

A single-connection form shows the same steps without grouping them under the connection's name.

When the merchant submits the form, Preczn confirms submission immediately and redirects them to the form's return URL. Boarding to each connection happens in the background — the merchant doesn't wait for it.

Setting Up a Multi-Connection Form

Create the form with the same POST /v1/forms endpoint you already use, but pass connectionIds (plural) with an array of connection names instead of a single connectionId:

{
  "merchantId": "mid_1sxmscs49g95t8y6n79nt922xr",
  "connectionIds": ["Payrix", "Greensky"],
  "formTemplateId": "formTemp_test_7ffxgaw71x82zsg0psxd7q73nh"
}

Each entry in connectionIds can be either a connection name or a connection ID (midCon_...). We recommend using connection names — they're easier to read, easier to copy from a list of supported connections, and don't require you to look up the connection ID for the specific merchant first. Preczn resolves connection names to the matching connection on the merchant.

The response includes connectionIds and processorNames instead of their singular counterparts. The full response carries every field on the form (template overrides, expiration, styling, etc.), so the snippet below shows only the fields that change for multi-connection forms:

{
  "id": "form_5mno6pqr7stu8vwx",
  "merchantId": "mid_1sxmscs49g95t8y6n79nt922xr",
  "connectionIds": [
    "midCon_6v59stftbs837axmpahj21m8jf",
    "midCon_8xq2hbgptn5193cymopdq2x4kc"
  ],
  "processorNames": ["Payrix", "Greensky"],
  "url": "https://boarding.yourplatform.com/form_5mno6pqr7stu8vwx/AcmeCorp",
  "expiresOn": "2026-05-07T10:30:00Z"
}

You send the url to the merchant the same way you would for any other boarding form.

The request follows these rules:

• Include exactly one of connectionId or connectionIds. Sending both, or neither, returns 400 Bad Request.
• Every connection in connectionIds must already be on the merchant. An unknown connection returns 404 Not Found.
• Multi-connection forms are KYC only. A request that combines connectionIds with type: "RFI" returns 400 Bad Request.

🚧

Include every connection's custom fields in the form template

A multi-connection form combines the standard requirement fields across its connections, but it takes custom form fields from the form template only. If the connections you combine rely on different custom fields, the template must include the custom fields for all of them. Contact support for help building a template for a particular set of connections.

FAQ