Your merchants process through more than one processor, and you want to decide which one handles each transaction. Preczn gives you two ways to make that decision through one transaction API. You can let Preczn route with plans and rules you configure, or you can name the processor on each request and keep the decision in your own routing logic. You can also combine the two. You might know this as payment orchestration, multi-processor routing, or load balancing.

Either way, your platform integrates once. Adding a processor or changing where transactions go doesn't mean a new processor integration.

Who this is for

---

• Platforms whose merchants have active connections to two or more processors.
• Platforms that want routing decisions in configuration they can change without a deploy.
• Platforms that already have a routing or rules engine and want Preczn to execute its decisions.

You don't need this page if each merchant uses one processor. Assign the default plan Preczn creates for that connection. See Assigning Merchants to Plans.

When to use this

---

How it works

---

Preczn decides where a transaction goes from one question: does the request name a processor?

• Yes: Preczn sends the transaction to that processor. This is direct routing for a merchant without a plan, and hybrid routing for a merchant with one. Your code owns the decision.
• No: Preczn applies the merchant's plan. A plan holds the connections it can route to and an ordered list of rules. Preczn evaluates them in a fixed sequence: Order first, then BIN, then the first matching Distribution, Card Brand, or Currency rule. The first rule that selects a connection wins.

The diagram shows both paths.

flowchart LR
    T["Transaction request"] --> Q{"Processor named<br/>on the request?"}
    Q -->|"Yes: direct or hybrid"| N["Named processor"]
    Q -->|"No"| P["Merchant's plan<br/>evaluates rules"]
    P --> A["Processor A"]
    P --> B["Processor B"]

Each response records how the transaction was routed, so you can tell plan routing from direct routing in your reporting.

ACH transactions don't follow plan rules. Preczn sends a bank payment to the first ACH-capable connection in the plan. See Routing Rules.

Plans also offer a Reject Salvage rule, which retries a declined authorization on another connection in the plan. See Routing Rules before you use it.

Prerequisites

---

• Two or more connections configured on your platform. See Connection Configuration.
• Each merchant has active credentials for every processor it routes to. See Assigning Merchants to Plans.

Outline

---

To let Preczn route:

1. Create a plan. Choose the connections it can route to. See Routing Plans.
2. Add rules. Put conditional rules, such as Card Brand or Currency, above the Distribution rule that catches everything else. See Routing Rules.
3. Assign merchants. Assign one merchant at a time, move merchants in bulk, or schedule a move for a future date. See Assigning Merchants to Plans.
4. Send transactions without a processor. Leave processor off the request so the plan decides. See Transaction Routing.

To route with your own logic:

1. Decide the processor in your code for each transaction, using your own rules engine.
2. Name the processor on the request. Preczn sends the transaction there and skips plan rules. See Transaction Routing.

For either path, confirm how each transaction was routed by reading routingSource on the response. See Transaction Routing.

📘

Build plans in test mode first

Plans belong to one mode. Build and exercise a plan in test mode, then recreate it in live mode. See Live vs Test Mode.

Example

---

A veterinary practice platform processes through two card processors.

1. For most practices, the platform creates a plan with both processors. It adds a Card Brand rule that sends American Express to the second processor, above a 50/50 Distribution rule, and moves those practices onto the plan in bulk.
2. A group of large hospital practices has negotiated pricing that the platform's own billing system tracks. For those practices, the platform's code picks the processor and names it on each request. Preczn sends each transaction to the named processor.
3. The platform reads routingSource on each response to report plan-routed and directly routed volume separately.

Related

---

How-to guides

• Routing Plans
• Routing Rules
• Assigning Merchants to Plans
• Transaction Routing

Concepts and use cases

• Connections
• Payment Transactions
• Live vs Test Mode
• Make Payment Methods Portable

Reference

• Process Transaction
• Get Platform Plans
• Update Merchant