Payment Orchestration FAQ

What is payment orchestration?

Payment orchestration is a control layer that sits between your application and multiple payment processors or acquirers. It provides a unified API while enabling routing, retries, failover, observability, and optimization across providers.

Processors continue to handle authorization, clearing, and settlement. The orchestration layer determines how and where transactions are processed.

If you're new to Hyperswitch, start here:

• What is Hyperswitch?

• Architecture Overview

Does orchestration replace my payment processor?

No. Orchestration complements processors.

Processors:

• Connect to card networks

• Authorize and settle transactions

• Provide risk tooling

Orchestration:

• Routes transactions

• Applies retry and failover logic

• Normalizes responses

• Centralizes configuration

• Enables cross-PSP reporting

For implementation details, see:

• Connector Integration

• Payments API Reference

Why would I need orchestration if I already use a PSP?

A single PSP may be sufficient early on. Orchestration becomes relevant when payments materially impact revenue, cost, or availability.

Common triggers include:

• Improving authorization rates

• Reducing processing costs

• Expanding to multiple regions

• Avoiding single-provider dependency

• Supporting marketplace or ISV complexity

For routing and configuration examples:

• Routing Documentation

How does orchestration improve authorization rates?

Approval improvements typically come from:

• BIN or country-based routing

• Local acquirer selection

• Success-rate-aware routing

• Automated retry with alternate processors

For technical details:

• Routing Rules Configuration

How does orchestration reduce processing costs?

Cost optimization may involve:

• Routing to lower-cost processors

• Domestic versus cross-border optimization

• Negotiating across multiple providers

• Intelligent retry strategies

To configure cost-based routing:

• Connector Matrix

How complex is it to implement?

Implementation typically involves:

1. Integrating with the Payments API

2. Configuring one or more connectors

3. Defining routing rules

4. Testing in sandbox

Start here:

• Your First Payment Guide

• Unified Local Setup Using Docker

For API details:

• API Reference

Can I migrate gradually?

Yes. Migration can be done incrementally using routing rules or traffic splitting.

Common strategies:

• Route a small percentage of traffic

• Pilot by geography or BIN range

• Run A/B comparisons across processors

• Enable instant rollback

What happens if the orchestration layer fails?

High availability depends on deployment architecture.

Best practices include:

• Horizontal scaling

• Load balancing

• Health checks

• Observability and alerting

See:

• Deployment Guide

How does orchestration affect PCI compliance?

Compliance impact depends on deployment model and integration pattern.

Considerations include:

• Card data handling

• Tokenization strategy

• Encryption key management

• Self-hosted versus SaaS responsibilities

For more details:

• Security and Compliance Overview

How does orchestration handle multiple payment methods?

Orchestration normalizes payment methods across connectors while preserving connector-specific capabilities.

Supported methods may include:

• Cards

• ACH

• Wallets

• Buy Now Pay Later

• Alternative payment methods

See:

• Supported Payment Methods

• Connector Documentation

How does reporting and reconciliation work?

Hyperswitch centralizes transaction metadata and routing decisions, enabling unified reporting across processors.

For logging and monitoring:

• Observability Documentation

• Log Export and Storage

This simplifies:

• Cross-PSP reconciliation