Skip to content
A railway junction at night, several tracks diverging under red and white signal lamps.

FinTech · Engineering, no AI

Payment routing for MENA, LATAM and Southeast Asia

A single payment provider stopped working once the client sold in new regions. An orchestration layer now routes each transaction by rule, and reroutes it when a provider fails.

Client
Recurring billing and subscription management for media and entertainment brands
Segment
FinTech, payments
Regions
MENA, LATAM, Southeast Asia
Built on
Primer orchestration, with Adyen, Yuno and regional providers
  • Primer
  • Adyen
  • Yuno
  • Node.js
  • AWS Lambda
  • Amazon SQS
  • Amazon SNS
  • Amazon S3
  • AWS CDK
  • SST
  • AWS Vault

Before

What was true before

Expansion into MENA, LATAM and Southeast Asia exposed the limits of a setup with one payment provider. Approval rates and revenue fell, partly from data formatting mismatches and partly from missing local coverage. Each new provider took months of development and QA, routing was static, and an outage at the provider could stop every transaction.

  • Static routing, with no way to send a transaction to the provider most likely to approve it
  • Months of work to add each new provider
  • One provider outage could halt all payments
  • Problems reported by users before monitoring caught them

After

What we did

An orchestration layer on Primer connects several providers behind one API. A rule-based engine routes and retries each transaction from its metadata, a second processor takes over when one fails, and dashboards show approval rates, decline reasons and latency per provider.

Build log

How it was built

work log · FinTech · Recurring billing provider for media platforms7 steps
  1. 01

    Built an orchestration layer on Primer connecting Adyen, Yuno and regional providers

  2. 02

    Designed an API-first, event-driven microservices architecture integrated with Primer and the client SRM system

  3. 03

    Built a rule-based engine for routing and retries driven by transaction metadata

  4. 04

    Added multi-processor redundancy that reroutes transactions automatically during a provider outage

  5. 05

    Built dashboards for approval rates, decline reasons and latency per provider

  6. 06

    Set up infrastructure as code with SST, credentials in AWS Vault, and CI/CD with automated tests

  7. 07

    Added real-time monitoring and alerting in place of user-reported issues

Measured

Results

As reported in the published case.

faster processor integration, from months to weeks
80%
requests per second handled under load
10K+
control over payment workflows through orchestration
100%
  • A 20 to 30% boost in approval rates in key regions is projected on the published case, not yet measured
  • The architecture targets 99.99% uptime
The published case on oxagile.com

This engagement did not include AI. It is here as evidence of the engineering that AI work sits on.

Next step

Yours would be the next one.

Tell us where it breaks, and you get a written answer on what breaks first and what it costs.