Smart APM Routing Engine

What is Smart APM?

Smart APM (Alternative Payment Method) is a unified payment abstraction layer that allows merchants to offer multiple localized payment methods through a single API integration.

Instead of integrating separately with each regional provider, merchants submit a single SMART_APM request. The Smart Routing Engine determines the most appropriate payment method and routes the transaction to the correct Smart handler based on context and commercial scope.

How Smart Routing Works

When a SMART_APM transaction is initiated, the Smart Routing Engine evaluates:

1. Merchant Configuration
   Enabled payment types, regions, and providers.

2. Transaction Context
   Country, currency, device type, and payment flow.

3. Commercial Constraints
   Merchant agreements, enabled routing model, and data requirements.

4. Optimal Method Selection
   Selection of the best-supported payment method for the given context.

The request is then forwarded to one of the Smart APM handlers:

• SMART_BANK_TRANSFER
• SMART_E_WALLET
• SMART_MOBILE_WALLET
• SMART_QR
• SMART_VOUCHER
• SMART_CARRIER_BILLING
• SMART_BNPL

Each handler has a specialized payload and response tailored to its payment capabilities.

Commercial Scope & Routing Guarantees

Smart APM routing is governed by the merchant’s commercial agreement and approved payment scope.

Before implementation, merchants must coordinate with their Account Manager to confirm what Smart APM is allowed to do for their account.

Confirm During Onboarding

• Enabled Smart APM handlers
• Approved end providers per region
• Supported countries, currencies, and devices
• Provider-specific data requirements
• Compliance or regulatory obligations

📌

Note

Smart APM simplifies integration, but it does not override commercial agreements or regulatory requirements.

Routing Stability Guarantee

Smart Routing always respects merchant-approved data collection flows.

Exirom will not route a transaction to a provider or payment method that requires additional merchant-side data unless:

• the requirement has been explicitly disclosed
• the merchant has agreed to collect and provide the data
• the integration is prepared for those fields

⚠️

Important
Routing will never silently introduce new mandatory fields or payer data requirements without prior notice and merchant agreement.

This ensures predictable production behavior and avoids unexpected validation failures.

Fixed DTOs and Runtime Validation

All Smart APM integrations use fixed request and response DTOs.

• DTO schemas never change
• No provider-specific payloads are introduced
• Differences exist only in runtime validation rules

A field may appear optional in the schema but be required depending on:

• the selected provider
• the merchant’s commercial scope
• regional or regulatory constraints

Smart Routing resolves the provider first, then applies the relevant validation rules.

⚠️

Important
Nullable fields must be treated as conditionally required. Requiredness is determined at runtime after routing.

Commercial and Routing Models

Smart APM supports two distinct operational models.
The active model directly impacts routing behavior and data requirements.

Exirom as Payfac (Sub-Merchant Model)

In this model, the merchant operates under Exirom-managed MIDs.

• Exirom acts as the Payfac
• The merchant is onboarded as a sub-merchant
• Routing is limited to Exirom-approved providers
• Data requirements are standardized and minimized

Characteristics

• Faster onboarding
• Simplified KYC and compliance
• Fewer required payer fields
• Exirom controls routing and provider rules

Best suited for merchants prioritizing speed and reduced operational overhead.

Exirom as Gateway (Direct Provider Agreements)

In this model, Exirom operates as a payment gateway, while the merchant maintains direct commercial agreements with one or more providers.

• Provider requirements are defined by the merchant’s contracts
• Some providers may require additional payer data
• Routing is constrained to merchant-approved providers only
• Validation rules may differ per provider

⚠️

Important
Smart Routing will never route to a provider that the merchant has not explicitly enabled and prepared for.

Recommended Integration Pattern

To support all Smart APM methods with a single implementation, merchants should use a configuration-driven integration model.

Core Principles

• One integration for all providers
• Conditional fields handled via configuration
• No hardcoded provider logic
• Flexible UI and backend for additional data collection

Practical Guidance

• Maintain configuration for:
  • enabled Smart APM handlers
  • allowed providers
  • required fields per route or provider
  • vaulting and reuse behavior
• Validate requests using configuration rather than static rules
• Render payer input fields only when required
• Support retry flows when additional data is requested after routing

💡

Best Practice

Use feature flags or remote configuration so new providers, regions, or rules can be enabled without redevelopment.

Operational Considerations

• Routing decisions may evolve based on availability and context
• Conditional validation errors should be handled gracefully
• Session continuity should be preserved using merchant identifiers or tokens
• Retry flows should reuse the same session to reduce user friction

✅

Outcome
A single Smart APM integration that remains stable, predictable, and adaptable as providers, regions, and commercial terms evolve.

• Flexibility: Support for e-wallets, mobile wallets, QR payments, bank transfers, carrier billing, vouchers, and BNPL in one place.