#Ruby, Payments, Multiple Payments π¬π§
Designing a Unified Multi-Gateway Payment Layer in Ruby on Rails
Ghina Ajour
Ghina Ajour
2 min read
Integrating a single payment gateway is rarely trivial. Integrating multiple gateways across regions, currencies, and business models quickly becomes a maintenance nightmare.
Our online ticketing platform operates globally and support multiple payment service providers (PSPs): Stripe, PayPal, Viva Wallet, Checkout, Network International, Volt, Thawani, 2C2P, and others. Each gateway has its own authentication model, payload structure, naming conventions, and feature gaps.
This article explains how we builtΒ active_payments, a Ruby gem that provides a single, consistent API over multiple payment gateways, while still allowing gateway-specific capabilities such as marketplaces, tokenization, and off-session payments.
Rather than focusing on theory, I will walk through real production adapters for Stripe and Viva Wallet.
The Core Problem
The problems we wanted to solve were:
- Every gateway calls the same thing by a different name:
Β Β charge, sale, capture, payment_intent
- Authentication varies wildly:
- API keys, Basic Auth, Bearer tokens, OAuth-style token exchange
- Payloads are incompatible:
- Currency exponent handling
- Metadata support
- Refund semantics
- Marketplace support is not standardized
- Without discipline, this leads to:
- Gateway-specific conditionals spread across the Rails app
- Tight coupling between business logic and PSP APIs
- High regression risk when adding or modifying gateways