For many enterprises, payment tokenization is no longer a single-country, single-gateway requirement. Global organizations often operate across multiple business units, currencies, acquiring banks, processors, and payment gateways. When payment architecture is too rigid, it creates operational friction, increases implementation effort, and limits how finance and payments teams can scale. 

Oracle Fusion Payments introduced a more flexible tokenization model that supports multiple payment gateways and multiple merchant IDs using routing rules driven by transaction context. Oracle’s model extends tokenization routing beyond just business unit and allows gateway and merchant account selection using parameters such as business unit, currency, payer, first-party country, payer country, and source product. It also includes routing-rule-based tokenization, enhanced UI support, token upgrades, and import support for legacy and FBDI-driven use cases. 

NexInfo helps organizations implement this capability as part of a broader Oracle Fusion Payments architecture—designing routing logic, configuring payment systems and accounts, upgrading existing token models, and aligning global tokenization strategy with enterprise payment operations. 

Why This Capability Matters 

Oracle’s earlier tokenization model supported only one payment system for tokenization and allowed multiple merchant IDs only using business unit as the routing basis. It also required that a single business unit not map to more than one MID in that setup. Oracle explicitly identifies these as the current capability and limitation of the earlier model. 

That model worked for simpler organizations, but it became restrictive for enterprises that needed to: 

  • use more than one payment gateway 
  • route tokenization by currency, customer, country, or business context 
  • support regional processors and acquirers 
  • manage different merchant relationships across geographies 
  • centralize ERP while decentralizing payment execution 

Oracle’s enhanced model adds a routing layer between transaction context and payment system account selection, enabling the system to identify the appropriate gateway and merchant ID dynamically. The supported routing inputs include business unit, currency, payer, first-party country, payer country, and source product. 

This is where NexInfo adds implementation value. 

How NexInfo Implements Multiple Payment Gateways in Oracle Fusion Payments 

NexInfo treats this capability as a payment operating model design exercise, not just a setup task. We help clients design the full tokenization architecture around their legal, commercial, banking, and payment gateway relationships. 

  1. Global Payments Architecture Assessment

NexInfo begins by assessing the client’s current and target-state payment landscape, including: 

  • countries of operation 
  • business units and legal structures 
  • gateway relationships 
  • merchant IDs 
  • processors 
  • acquirer banks 
  • remittance bank accounts 
  • transaction currencies 
  • source products and channels 

Oracle’s payment architecture supports payment system setup at the gateway level and payment system accounts aligned to merchant IDs, while processors remain internal to the merchant and are not captured in Payments. Oracle also notes that the acquirer is represented as the remittance bank account in Receivables. 

NexInfo maps these relationships into a clean Oracle Fusion Payments design so clients can scale routing without creating brittle one-off configurations. 

  1. Payment System and Merchant Account Design

Oracle’s model allows a gateway such as CyberSource to be configured as a payment system, with multiple merchant IDs represented through payment system accounts. Oracle’s example shows separate payment system accounts corresponding to country-specific MIDs. 

NexInfo helps clients define: 

  • which gateways should be configured as payment systems 
  • how merchant IDs should be represented as payment system accounts 
  • how to align merchant IDs to regional payment operations 
  • how to support local versus shared gateway strategies 
  • how to structure default and exception routing 

This is especially valuable for enterprises operating with regional processors and acquirer relationships across multiple markets. 

  1. Routing Rule Strategy and Design

This is the heart of the new capability. 

Oracle’s updated tokenization design introduces routing rules setup so tokenization and transaction routing can be determined using multiple parameters rather than business unit alone. The new flow uses these routing rules to select the applicable gateway and merchant ID before launching the hosted payment page.

NexInfo works with clients to define practical routing strategies such as: 

  • business unit + currency routing 
  • regional payer routing 
  • source-product-based routing 
  • first-party country routing 
  • payer country routing 
  • hybrid global and local gateway models 

We help clients avoid overcomplicated rule structures while still enabling the flexibility Oracle now supports. 

  1. UI, Security, and Funds Capture Configuration

Oracle’s solution components include enhancements in several areas: 

  • routing rules for tokenization and transaction routing 
  • credit card UI support for payment system, account, and profile 
  • credit card LOV filtering in real time based on routing rules 
  • system security options to capture the default tokenization payment system 
  • NexInfo configures all of these in a coordinated way so the business users have a clean operational experience. We ensure that: 
  • the right gateway is available in the right context 
  • payment system defaults are aligned correctly 
  • card LOV behavior is predictable 
  • funds capture setup remains manageable after go-live 
  • gateway-specific tokenization behavior is visible and supportable 
  1. Existing Token Upgrade Planning

Oracle clearly states that this feature requires upgrading existing tokens because tokens are now striped by payment system, payment system account, and funds capture process profile. Oracle also notes that upgrade can be triggered automatically at one of two points: when tokenization routing rules are created, or when a credit card settlement-related process is submitted. 

This is a critical implementation consideration. 

NexInfo helps clients plan and execute token upgrades by: 

  • identifying the impact on existing stored cards 
  • validating current token inventory 
  • aligning gateway-specific token ownership 
  • sequencing rule setup and token upgrade events 
  • reducing production risk during enablement 

For organizations with a large installed base of tokens, this planning is essential. 

  1. Import and Conversion Use Cases

Oracle’s solution also extends beyond UI-based token creation. It includes: 

  • legacy token import support through FBDI 
  • capture of payment system account and profile in legacy token import 
  • ESS support for token upgrade handling 
  • handling of imported transaction scenarios where routing context determines the applicable gateway tagging 
  • NexInfo supports clients with: 
  • legacy token migration 
  • conversion design 
  • FBDI preparation 
  • import validation 
  • coexistence transition planning 
  • source-to-target mapping for payment system account assignment 

This is especially important during gateway consolidation, ERP migration, or country rollout programs. 

What Oracle’s Enhanced Model Enables 

Oracle’s redesigned tokenization approach gives organizations several major advantages. 

First, it enables multiple gateways in one Oracle Fusion ERP environment, which was not supported in the earlier model.

Second, it allows routing based on more than just business unit, adding business unit, currency, payer, first-party country, payer country, and source product to the routing logic.

Third, it improves usability by enhancing the user interface, real-time card filtering, and default payment system setup.

Fourth, it supports controlled rollout because the feature is GA in 24B, with an opt-in strategy where it is enabled by default for new customers and disabled for upgrading customers until they choose to enable it.

NexInfo helps clients turn those product capabilities into a workable global payments design. 

NexInfo Services Offered for Oracle Fusion Payments Tokenization 

NexInfo offers a full set of implementation and optimization services around this Oracle capability. 

Oracle Fusion Payments Assessment Services 

We evaluate existing payment gateway architecture, merchant account structure, regional payment flows, and tokenization requirements. 

Payment Gateway and Merchant ID Design 

We design the target model for payment systems, payment system accounts, default payment logic, and country-specific merchant alignment. 

Tokenization Routing Rule Implementation 

We configure routing rules using supported Oracle parameters and align them to real transaction scenarios. 

Existing Token Upgrade and Enablement Planning 

We support opt-in activation, upgrade sequencing, testing, and rollout governance. 

Legacy Token Migration and Import Services 

We design and execute migration approaches for imported tokens and FBDI-based scenarios. 

Funds Capture and Receivables Alignment 

We connect tokenization architecture to downstream funds capture and remittance banking setup. 

Testing and Production Rollout Support 

We validate UI flows, hosted payment page behavior, token stripe correctness, routing outputs, and multi-gateway transaction handling. 

Managed Services and Post-Go-Live Support 

We provide ongoing support for gateway expansion, routing rule changes, new country enablement, and payment architecture optimization. 

Typical NexInfo Implementation Scenarios 

Clients commonly engage NexInfo for this capability in scenarios such as: 

a global Oracle ERP rollout with local merchant relationships 

migration from a single gateway model to a multi-gateway design 

adding new regions or currencies to an existing Oracle Payments environment 

aligning tokenization with different processors and acquirers by country 

separating domestic and cross-border payment gateway flows 

converting legacy tokens during Oracle Cloud transformation 

In each case, NexInfo focuses on designing a payment architecture that is scalable and supportable—not just technically possible. 

Why NexInfo as the Implementation Partner 

Oracle has delivered the platform capability. NexInfo provides the implementation discipline to make it work in real enterprises. 

Clients choose NexInfo because we combine: 

  • Oracle Fusion Payments configuration expertise 
  • global ERP implementation experience 
  • payment architecture design thinking 
  • conversion and migration support 
  • practical rollout governance 
  • long-term managed services capability 

We do not just configure payment systems. We help organizations build a tokenization and payment gateway operating model that aligns with how their business actually transacts. 

FAQ 

What changed in Oracle Fusion Payments for credit card tokenization? 

Oracle added support for multiple payment gateways and more flexible routing using transaction context. The earlier model supported only one payment system for tokenization and multiple merchant IDs only through business unit. The enhanced model adds routing rules using parameters such as business unit, currency, payer, first-party country, payer country, and source product. 

How does NexInfo implement multi-gateway tokenization? 

NexInfo implements it through gateway architecture assessment, merchant account design, routing rule setup, UI and security configuration, token upgrade planning, import support, and rollout testing. 

Can Oracle Fusion Payments support multiple merchant IDs? 

Yes. Oracle supports multiple payment system accounts representing multiple merchant IDs, and the enhanced routing model can now determine the right payment system and payment system account using broader transaction context. 

What implementation services does NexInfo offer for this capability? 

NexInfo offers assessment, design, routing rule configuration, token upgrade support, migration services, funds capture alignment, testing, and ongoing managed services. 

Do existing tokens need to be upgraded? 

Yes. Oracle states that existing tokens require upgrade because token striping now includes payment system, payment system account, and funds capture process profile. Oracle provides upgrade triggers during routing rule creation or settlement-related processing. 

Is this feature automatically enabled for all Oracle customers? 

No. Oracle describes it as GA in 24B with an opt-in strategy. It is enabled by default for new customers and disabled for upgrading customers until they opt in. 

Can NexInfo help with legacy token import and conversion? 

Yes. Oracle supports legacy token import enhancements, and NexInfo helps clients design, validate, and execute conversion strategies across existing token inventories and gateway models. 

 Multiple payment gateways for credit card tokenization is more than a product enhancement—it is a major step forward in how global organizations can structure payment operations inside Oracle Fusion Cloud ERP. Oracle’s enhanced model adds routing flexibility, multi-gateway support, token upgrade handling, UI improvements, and stronger support for imported and legacy token scenarios. 

NexInfo helps clients implement that capability with the architecture, governance, and rollout strategy needed for success. 

For organizations expanding globally, consolidating payment operations, or modernizing tokenization in Oracle Fusion Payments, NexInfo serves as the implementation partner that turns Oracle functionality into a reliable, scalable enterprise payments design.