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.

Two parts of the wizard adapt to the connections you selected:

• Terms & Conditions. If two or more connections each have their own T&C, the merchant sees a separate T&C step for each connection, labeled with the connection name (for example, T&C — Payrix followed by T&C — GreenSky). The merchant accepts each one independently. If only one of the selected connections has T&C, the merchant just sees one unlabeled T&C step.
• Connection-specific steps. A few wizard steps only make sense for certain connections — Account Login is Payrix-specific, and the PCI Compliance attestation is Adyen-specific. These steps appear automatically when at least one of the selected connections needs them, and are skipped otherwise.

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.

Things to Know

🚧

Make sure your form template covers every connection's fields

A multi-connection form automatically combines the standard requirement fields across the selected connections, but custom form fields are inherited from the form template only — they are not aggregated from the connections themselves. If two of the connections you're combining each rely on different custom fields, the form template you reference must include the custom fields for both. Reach out to support if you need help putting together a template that covers a particular set of connections.

📘

Pass connectionId or connectionIds, not both

A request must include exactly one of the two fields. Sending both, or neither, returns 400 Bad Request.

📘

Multi-connection forms are KYC only

RFI (request-for-information) forms continue to use a single connectionId. A request that combines connectionIds with type: "RFI" is rejected with a 400 Bad Request.

A few other behaviors worth knowing about:

• Every connection must already exist on the merchant. An unknown connection in the array returns 404 Not Found.
• If one connection fails to board, the others still proceed. The connection whose boarding failed moves to Error status; the rest are unaffected. Standard connection-status webhooks let you observe each connection's outcome independently.
• Auto-transmit applies to every selected connection. When the form template has autoTransmitMerchantData enabled, submission triggers boarding for all of the form's connections.