MyBridgePay Changing a Processor on a Merchant Account
Why processor changes require special handling
A processor change affects how transactions are authorized, batched, settled, and funded. Even if the Merchant Account remains the same in MyBridgePay, the processor behind that account may have different identifiers, settlement behavior, and processing rules. Because of that, transactions started under one processor should not be left unfinished when another processor is activated.
A safe processor change is not just a boarding task. It is a settlement and reconciliation task first, and a configuration task second.
Required rules before changing a processor
1. Ensure open authorizations are captured or voided
An authorization is not the same as a completed payment. It only reserves funds. Before changing processors, every open authorization must be resolved one of two ways:
Capture it if the merchant intends to complete the sale.
Void it if the transaction should not be completed.
Leaving authorizations open during a processor change creates risk. The authorization belongs to the prior processing path, and once the account changes over, users may no longer be able to manage that authorization in a clean, predictable way.
Do not leave open auths behind. An open auth that is not captured or voided can lead to customer confusion, expired holds, missed revenue, or settlement exceptions.
Typical examples include:
A merchant ran Auth Only transactions and planned to capture later.
A user has pending authorizations in Batch Management with editable capture amounts.
A restaurant, hospitality, or delayed-fulfillment workflow still has outstanding auth activity that has not been finalized.
Review Batch Management carefully and resolve every open auth before moving forward.
2. Settle all transactions before making the processor change
This is the first and most important rule. Any unsettled transactions must be completed through the current processor before a change is made. If a batch remains open and a processor is changed, transactions in that batch may not settle correctly, may not fund on time, or may require manual investigation.
In MyBridgePay, unsettled transactions are managed through Batch Management. Users with the proper rights can review the open batch, confirm what is pending, and submit the batch for settlement.
Why this matters: Settlement is the step that moves approved transactions from reserved funds to merchant funding. If transactions are approved but not settled before the processor change, the merchant may not receive expected funds and support teams may have a difficult reconciliation path afterward.
Before proceeding, confirm all of the following:
No open batch remains on the Merchant Account.
No unsettled sales are waiting in Batch Management.
No unsettled refunds or other open items remain that belong to the current processor.
3. Board the new processor only after prior activity is complete
Once the current processor activity is fully closed out, the new processor can be boarded. In MyBridgePay, processor configuration is performed under Account Management >> Merchant Account >> Processors. Depending on role permissions, access to processor options is controlled by the user’s boarding and processor rights.
When boarding the replacement processor, verify that all required setup values are entered exactly as provided by the processor or MSP. Processor setups commonly depend on values such as merchant IDs, terminal IDs, connection strings, host settings, payment type options, and other processor-specific parameters.
Best practice: Do not activate or rely on the new processor until the previous processor’s transactions, authorizations, and settlement cycle are fully complete and reviewed.
Also keep in mind:
The active processor should be clearly identified on the Processors tab.
Processor-specific capabilities may vary.
Threshold controls, payment types accepted, and gateway configuration settings may need review on the newly boarded processor.
If the Merchant Account uses applications such as Virtual Terminal, Hosted Payment Page, Recurring Billing, import tools, or APIs, validate the new processor for those actual use cases.
4. Always run a test transaction
After the new processor is configured, run a live functional test before declaring the change complete. A saved processor record is not the same as a validated processor setup. The test confirms that the account can actually authorize, report, and move through the expected processing flow.
At minimum, the post-change validation should confirm:
The transaction approves successfully.
The transaction appears in Find Transactions or reporting.
The transaction lands in the correct batch behavior for that processor.
The merchant can proceed with normal processing on the new setup.
Recommended validation: Run a small-dollar sale, confirm it appears in reporting, and review Batch Management to make sure the transaction is behaving as expected for that processor setup.
If the merchant uses more than one payment path, expand testing accordingly. For example:
Virtual Terminal users should test in the Virtual Terminal.
API merchants should validate through their integration path.
Recurring Billing merchants should review any processor-dependent payment behavior before resuming scheduled billing.
ACH merchants should confirm the correct ACH processor remains configured separately where applicable.
Table of Contents: