By Eric Kuvykin. Substantially revised October 17, 2026. The original publication date and URL are retained.
Identify what the system is actually choosing
Payment routing can refer to choices among providers, supported networks or different payment methods. Those choices have different technical and contractual constraints. Ask the vendor to describe precisely which decision its system makes, which parties authorize that choice and which information is used.
Do not evaluate a routing product through a single promised approval rate. Begin with the business problem: unresolved failures, a dependency on one service or a documented cost issue. Define the transaction set and the outcome the business wants to improve before reviewing a proposed algorithm.
Use a comparable sample
Separate channels, payment methods and customer journeys when comparing results. A change in the mix of transactions can make a routing change appear effective even if the underlying performance is unchanged. Keep the denominator visible: attempts, completed orders and settled payments are different counts.
Record failures by the information the provider actually supplies. Avoid presenting a guessed cause as a confirmed issuer decision. Ask which failures are safe to retry, which require customer action and which should stop further attempts under the provider’s supported process.
Test the failure between systems
A second provider is useful only if the handoff preserves a clear transaction status. Test what happens when the first request times out after submission. The orchestration system should have a supported way to check whether the first attempt succeeded before another charge is initiated.
Ask how duplicate prevention works across providers, how refunds find the original transaction and how staff investigate a disputed order. Request a demonstration using approved test cases. A diagram that shows arrows between platforms does not prove that every exception has an owner or an audit trail.
Include reconciliation and constraints in the comparison
Calculate complete costs, including gateway charges, orchestration fees and the work needed to reconcile multiple reports. Review contractual and network requirements with the relevant providers. Visa’s merchant rules resource is one primary starting point; it does not replace confirmation of the actual routing configuration.
For businesses with Florida, New York and New Jersey locations, keep merchant accounts and entity identifiers distinct in the test. Do not let a routing dashboard obscure which account accepted a transaction or where its proceeds should appear. Geography should describe the operating records, not become an unexplained risk signal.
Roll out a tested change in a controlled scope with an agreed rollback condition. Monitor completed orders, duplicate charges, unresolved payments and support effort together. A modest improvement that is easy to explain may be more useful than an impressive headline metric that leaves accounting unable to close the day.
Keep a change log linking each configuration update to its test evidence and approval. Reassess after a provider or checkout integration changes. A sound routing strategy improves a defined payment workflow while preserving the merchant’s ability to explain every attempted charge.
Sources and next steps
Primary reference: Visa’s current rules and merchant resources. Use the current resource and confirm implementation details with the provider or appropriate adviser.
Related reading: Card-Not-Present Fraud: Review the Order Before Repeating the Charge; B2B Payments: Connect the Invoice, Remittance and Bank Record.
For the wider operating context, continue to the Florida, New York and New Jersey business guides on All State Merchants. Its state and local resources complement the payment workflow discussed here.
Eric Kuvykin writes about payments, fintech and business operations. Browse the article library for additional practical guides.
