Preczn supports multiple methods for routing payment transactions to the appropriate processor.
This guide explains the three routing methods available, how to implement each, how to interpret the response, and frequently asked questions. Code snippets are included to illustrate the different routing strategies.

Routing Methods

1. Direct Routing

Use this method when you want to route a transaction explicitly to a specific processor without using routing plans.

When to Use:

Your platform wants to control the logic directly of where to route transactions
The merchant is not assigned to a routing plan.
You provide a processor value in the transaction request. NOTE The merchant must have an Active connection with the requested processor.

How It Works:

Preczn routes the transaction directly to the specified processor.
Because the merchant is not assigned to a routing plan, this transaction is not considered in any plan’s metrics and will not influence how future transactions are distributed by a plan if assigned later.

Request Example:

{
    "merchantId": "mid_test_5m7nk9z6048awv31xpk9n9pgv9",
    "type": "sale",
    "firstName": "Bob",
    "lastName": "Johnson",
    "payment": {
        "token": "tkn_test_1yqja402b69jttmkr8nsmgw6t0"
    },
    "currency": "USD",
    "amount": 1235,
    "processor": "Payrix" /// NOTE - Transaction will be directly routed to Payrix for this merchant
}

Response Example

{
    "amount": 1235,
    "authorization": {
        "approvedAmount": 1235,
        "avs": "U",
        "cvv": "U",
        "partial": false,
        "processorCode": "1",
        "processorMessage": "APPROVED",
        "processorTransactionId": "t1_txn_68fbc7401e337651595684b",
        "status": "A"
    },
    "createdOn": "2025-10-24T18:36:47Z",
    "currency": "USD",
    "email": "[email protected]",
    "fee": 0,
    "firstName": "Bob",
    "id": "txn_test_5ax0bg4gaa8shas9d835sw7h1d",
    "lastName": "Johnson",
    "merchantId": "mid_test_5m7nk9z6048awv31xpk9n9pgv9",
    "payment": {
        "bin": "400002",
        "brand": "VISA",
        "expiration": "0330",
        "last4": "0000",
        "token": "tkn_test_1yqja402b69jttmkr8nsmgw6t0",
        "type": "CREDIT"
    },
    "phone": "267-874-3837",
    "platformId": "pfm_2cvhyw8d448d9bsxdrytdn25pf",   
   /// NOTE the absence of plan since the transaction was directly routed
    "processor": {
        "id": "pfmCon_test_5njj7djqq289haw0cte3ymmp24",
        "name": "Payrix",
        "routingSource": "direct" /// NOTE that routing source is set to direct
    },
    "type": "sale"
}

2. Plan Routing

Use this method when you want Preczn to determine the routing processor based on a merchant’s assigned plan.
You can read more about setting up plans and rules in the plans documentation.

When to Use:

When your platform wants to preconfigure routing rules with plans, and allows Preczn to route the transaction based on rules and data from prior transactions.
The merchant is assigned to a routing plan.
You do not include a processor value in the request, the routing rules will be pulled directly from the plan itself.

How It Works:

Preczn evaluates the plan and chooses the appropriate processor based on the rules defined in the plan.
The transaction is tracked and will influence how future transactions are routed based on plan logic.

Request Example:

{
    "merchantId": "mid_test_5m7nk9z6048awv31xpk9n9pgv9",
    "type": "sale",
    "firstName": "Bob",
    "lastName": "Johnson",
    "payment": {
        "token": "tkn_test_1yqja402b69jttmkr8nsmgw6t0"
    },
    "currency": "USD",
    "amount": 1235,
    "processor": "Payrix" /// NOTE - Transaction will be directly routed to Payrix for this merchant, even though the merchant is assigned to a plan.
}

Response Example

{
    "amount": 1235,
    "authorization": {
        "approvedAmount": 1235,
        "avs": "U",
        "cvv": "U",
        "partial": false,
        "processorCode": "1",
        "processorMessage": "APPROVED",
        "processorTransactionId": "t1_txn_68fbc7401e337651595684b",
        "status": "A"
    },
    "createdOn": "2025-10-24T18:36:47Z",
    "currency": "USD",
    "email": "[email protected]",
    "fee": 0,
    "firstName": "Bob",
    "id": "txn_test_5ax0bg4gaa8shas9d835sw7h1d",
    "lastName": "Johnson",
    "merchantId": "mid_test_5m7nk9z6048awv31xpk9n9pgv9",
    "payment": {
        "bin": "400002",
        "brand": "VISA",
        "expiration": "0330",
        "last4": "0000",
        "token": "tkn_test_1yqja402b69jttmkr8nsmgw6t0",
        "type": "CREDIT"
    },
    "phone": "267-874-3837",
    "platformId": "pfm_2cvhyw8d448d9bsxdrytdn25pf",   
   /// NOTE the absence of plan since the transaction was directly routed, even though the merchant is     assigned to a plan.  The plan was not used for this transaction.
    "processor": {
        "id": "pfmCon_test_5njj7djqq289haw0cte3ymmp24",
        "name": "Payrix",
        "routingSource": "direct" /// NOTE that routing source is set to direct as a result of the transaction being process by the requested processor and not the plan.
    },
    "type": "sale"
}

3. Hybrid Routing

This method combines both direct and plan-based routing logic.

❗️
Consider Rule Set When Using
When direct routing a transaction for a merchant assigned to a plan, the transaction will still inform future routing decisions made by the plan.
For example, if your plan is configured to route 50% of volume to Processor A and 50% to Processor B, manually directing a transaction to Processor A may affect how the plan routes the next transaction—helping maintain the intended volume distribution across processors.

When to Use:

As a platform, you need optionality to directly route transactions, while still wanting most transactions to rely upon the plan rule set.
The merchant is assigned to a routing plan.
You include a processor value and that processor is part of the plan. (NOTE Processors included in the request must be part of the plan. This is necessary so that the plan routing rules are followed for subsequent request)

How It Works:

Preczn routes the transaction to the specified processor.
The transaction is tracked and will influence how future transactions are routed based on plan logic.

Request Example:

{
    "merchantId": "mid_test_5m7nk9z6048awv31xpk9n9pgv9",
    "type": "sale",
    "firstName": "Bob",
    "lastName": "Johnson",
    "payment": {
        "token": "tkn_test_1yqja402b69jttmkr8nsmgw6t0"
    },
    "currency": "USD",
    "amount": 1235,
    "processor": "Payrix" /// NOTE - Transaction will be directly routed to Payrix for this merchant.
}

Response Example

{
    "merchantId": "mid_test_5m7nk9z6048awv31xpk9n9pgv9",
    "type": "sale",
    "firstName": "Bob",
    "lastName": "Johnson",
    "payment": {
        "token": "tkn_test_1yqja402b69jttmkr8nsmgw6t0"
    },
    "currency": "USD",
    "amount": 1235,
    "processor": "Payrix" /// NOTE - Transaction will be directly routed to Payrix for this merchant.
}

Error Scenarios

Missing Routing Data

Occurs when neither a processor is specified in the request nor a routing plan is assigned to the merchant.

{
    "message": "Transaction routing could not be resolved. All transactions require either a specified processor or a routing plan assigned to the merchant.",
    "error": "Not Found",
    "statusCode": 404
}

Hybrid Routing: Processor Not in Plan

Occurs when a processor is provided, but it’s not part of the merchant's assigned plan.

{
    "message": "Transaction routing could not be resolved. The requested processor is not part of the merchant’s assigned routing plan.",
    "error": "Not Found",
    "statusCode": 404
}

Direct Routing: Missing Processor Credentials

Occurs when the processor is specified, but the merchant is not Active at the connection and lacks the valid credentials.

{
    "message": "Transaction routing could not be resolved. Merchant is missing credentials for the requested processor.",
    "error": "Not Found",
    "statusCode": 404
}

Understanding How A Transaction Was Routed

The response from a transaction request will include the routingSource field as part of the processor object, which tells you how the routing decision was made:

routingSource	Meaning
`direct`	Explicitly routed via the specified processor.
`plan`	Routed via plan logic

Example Response Direct Routing

Note in the response below, the processor.routingSource is set to direct and the plan is omitted from the response

{
    "amount": 1235,
    "authorization": {
        "approvedAmount": 1235,
        "avs": "U",
        "cvv": "M",
        "partial": false,
        "processorCode": "1",
        "processorMessage": "APPROVED",
        "processorTransactionId": "t1_txn_68fbc4855b83d60109db7dc",
        "status": "A"
    },
    "createdOn": "2025-10-24T18:25:08Z",
    "currency": "USD",
    "fee": 0,
    "firstName": "Bob",
    "id": "txn_test_5c33sm8jn79fdvv612qe14j26c",
    "lastName": "Johnson",
    "merchantId": "mid_test_5m7nk9z6048awv31xpk9n9pgv9",
    "payment": {
        "bin": "400002",
        "brand": "VISA",
        "expiration": "0330",
        "isTestMode": true,
        "last4": "0000",
        "token": "tkn_test_1yqja402b69jttmkr8nsmgw6t0",
        "type": "CREDIT"
    },
    "platformId": "pfm_2cvhyw8d448d9bsxdrytdn25pf",
    /// NOTE the absence of plan since the transaction was directly routed.
    "processor": {
        "id": "pfmCon_test_5njj7djqq289haw0cte3ymmp24",
        "name": "Payrix",
        "routingSource": "direct"  /// NOTE that routing source is set to direct.
    },
    "type": "sale"
}

Example Response Plan Routing

Note in the response below, the processor.routingSource is set to plan and the plan property is returned to indicate the plan that was used.

{
    "amount": 1235,
    "authorization": {
        "approvedAmount": 0,
        "processorCode": "12",
        "processorMessage": "Declined",
        "processorTransactionId": "A80A1ACCA6B1",
        "status": "D"
    },
    "createdOn": "2025-10-24T18:29:14Z",
    "currency": "USD",
    "fee": 0,
    "firstName": "Bob",
    "id": "txn_test_43zx6rbcrc8jfr0fh2ytdz476h",
    "lastName": "Johnson",
    "merchantId": "mid_test_2ewxxe7ec397q94haqes1259ce",
    "payment": {
        "bin": "400002",
        "brand": "VISA",
        "expiration": "0330",
        "last4": "0000",
        "type": "CREDIT"
    },
    "plan": { /// NOTE the presence of plan that was used to route.
        "id": "plan_test_20y87a288b83k9080c0kj3xd60",
        "name": "Multiple Connections"
    },
    "platformId": "pfm_2cvhyw8d448d9bsxdrytdn25pf",
    "processor": {
        "id": "pfmCon_test_4gafzemxb785ztrgtcmjgx9w1c",
        "name": "PayflowPro",
        "routingSource": "plan" /// NOTE that routing source is set to plan.
    },
    "type": "sale"
}

Frequently Asked Questions (FAQ)

What processor values can I use?

You may use any of the supported processor enumerations for connections that support transactions. Refer to our Process Transaction API Guide for enumerations.

What happens if I send a processor value and the merchant is assigned to a plan?

If the processor is part of the plan, Hybrid Routing occurs. If not, you'll receive an error.

Can I use Plan Routing without assigning a plan to the merchant?

No. A merchant must be assigned to a routing plan in order for Plan Routing to work.

How can I test different routing methods?

Use test merchant records with and without assigned plans, and include or exclude the processor in your transaction request.

Will the plan object always appear in the response?

Only if the merchant was assigned to a plan at the time of the transaction.