Why Fintechs Pair a Modular Payment Gateway with Issuer Processing (BaaS)

As transaction volumes increase and new markets are added, a single-provider setup may encounter challenges. Variations in traffic composition and differences in issuer risk appetites, SCA/3DS rules, and latency can lead to issues in transaction approvals. A modular approach, dividing operations into a gateway for routing and 3-D Secure (3DS) policy, and issuer processing for card lifecycle and limit management, allows for better control and adaptation to regional differences.

The gateway manages the authorization process, determining routing and authentication needs. It aims to provide targeted friction in 3DS flows, introducing challenges when necessary and exemptions when permitted. Routing should be adaptable, with rules based on BIN, region, and other factors, and should include latency and error-rate thresholds to ensure fallback options. Retry strategies are implemented with soft, timing-based approaches, using idempotency keys to avoid duplicate transactions.

Observability is crucial for managing idempotency and timing, with decline reason codes normalized and challenge rates tracked. Network tokens reduce challenges by updating lifecycle changes automatically. A payment gateway platform offers a unified control plane for fintech needs.

Issuer Processing Layer: Card Lifecycle and Control

Issuer processing manages card lifecycle events and enforces policy changes. It handles PAN/token provisioning, status enforcement, and consistent application of account-level attributes. Velocity policies, spend limits, and other controls are set and executed in real-time. A BaaS API facilitates policy management without direct processor modification.

Network tokens streamline lifecycle management, reducing 3DS challenges and stabilizing recurring transactions. Clear roles and responsibilities ensure compliance, with the BIN sponsor and program manager overseeing different aspects of policy and operations. The processing platform supports these functions, providing audit trails and managing disputes and chargebacks.

The gateway determines how authorizations proceed, while issuer processing decides if an instrument is usable. Under SCA/PSD2, the gateway manages 3DS policies, executing challenges or exemptions based on signals, while the issuer applies program rules before approving transactions. Tokenization is managed by the processing layer, with the gateway handling tokens without storing raw PAN data. Compliance measures include segregating PAN data and maintaining audit logs for transparency.

Market expansion involves different issuer expectations and acquirer behaviors. For example, European operations may rely on SCA exemptions, while in MENA, a 3DS challenge is often expected for certain transactions. Routing adjustments to use local acquirers and policy changes to manage challenges are necessary for successful market adaptation.

To evaluate the effectiveness of the gateway and issuer split, key metrics should be monitored over a 30–60 day period:

Auth rate by BIN/region/scheme: Establish baselines and targets, and monitor changes. 3DS challenge rate and frictionless share: Track by issuer and acquirer to identify outliers. Recovered soft declines: Measure approvals after retries or re-routes. Refund/settlement latency and webhook reliability: Monitor timing and reliability of events. Network token share: Track token penetration and impact on approvals. Time-to-market for new acquirers/rules: Record the time from decision to implementation.

Implementing a modular gateway with issuer processing provides control over transaction routing, 3DS policies, and lifecycle management. This approach reduces PCI scope, maintains compliance, and improves authorization rates and transaction stability. It allows for rapid adaptation to new markets and operational requirements, shifting control from vendor roadmaps to internal processes.

Based on reporting by TechBullion.