Table of Contents
Overview
This article will go over the recommended procedures for merchants who want to add processors and load balance their transactions across multiple processors. Load balancing is commonly done to help distribute transaction volume and risk.
Adding a Processor
When adding a new processor (MID) to your merchant gateway account, you should ensure that it is set up and configured correctly prior to pushing any traffic to it. This involves validating that the VAR sheet is correct and its details have been entered properly into the gateway during the boarding process.
On the gateway, some things you will want to validate are:
- All desired payment types and currencies have been enabled for the processor.
- The account classification is accurate (ex: E-Commerce).
- The merchant category code (MCC) is correct.
- Maximum monthly volume/ticket amount, required fields, and Duplicate Velocity controls have all been set up correctly (if needed).
Ensuring that the processor has been set up correctly helps prevent unexpected declines/errors in the future.
Testing Phase
Before rolling the new processor into your load balancing setup, we recommend validating that it is set up correctly by performing a variety of test transactions on the processor. Testing should involve different card types/brands as well as different transaction amounts. You should check that funds have been successfully deposited into your merchant account.
Any errors or declines that come up should be investigated. For instance, gateway-level declines can indicate a setup issue on the gateway side for the merchant account. Declines originating from the processor may suggest the boarding details are incorrect, or may have to be raised with the processor for further troubleshooting.
- A 200-level response code indicates a processor decline, usually returned by the card issuing bank.
- A 300 response code indicates a gateway rejection.
- A 400-level response code indicates a processor error. These tend to be a configuration issue.
- For more details on response codes, please see the NMI Developer Portal documentation: Response Codes.
If you are performing recurring/Credential on File transactions, processors may not approve of subsequent transactions that were initially performed on a different processing platform (ex: a subsequent transaction on Elavon where the initial transaction was performed on TSYS). This can result in declines or MasterCard edits due to noncompliance. This is processor-dependent, as such it would be worth discussing this with the processor and NMI Support if you are load balancing recurring transactions.
Rollout Phase
Once the processor has been added and validated to work, you can utilize the gateway's standard Transaction Routing functionality. Transactions can be automatically routed to maintain the dollar amount of the Maximum monthly limit set across each processor.
The gateway also offers the Advanced Transaction Routing Interface as a kind of “load balancer” as it is available for merchants who have two or more processing services. It does not use amounts in the way traditional Transaction Routing does but rather works off of the Merchant Defined Fields (acronym: MDF). For any transaction source that is able to send a value via Merchant Defined Fields, the gateway can intelligently route to a specific processor based on that value. Based off of the MDF sent in the transaction, you can configure a % percentage of transactions to be routed to one or more processor.
It is recommended to shift a smaller amount/percentage of transactions to the new processor before load balancing the full desired amount.
For more details on load balancing settings, please see the Transaction Routing and Advanced Transaction Routing Interface documentation.