top of page

Middle for Berkeley cards processing

Client Background

A small fintech company with an existing user base had a mobile application that was previously integrated with a third-party card processing provider. Over time, their product strategy evolved, and they decided to migrate to Berkeley’s card issuing platform to gain greater control, better economics, and compliance flexibility.


However, this introduced a significant technical challenge:

Their existing mobile app was deeply coupled with the original card processing API. Changing the app’s API contracts and business logic would have been costly and unclear if some users didn't want to update their application.

The Challenge

  • Berkeley’s backend had its own API and contracts.

  • The mobile app had been built around the previous provider’s API schema, logic, and assumptions.

  • A full rewrite of the mobile integration layer was not an option due to cost and user management risks.


Creating a middleware layer was offered by us that preserves the original API contract for the iOS app, while handling all necessary translations, retries, and state transformations required to work with Berkeley’s backend.


Our Solution: Middleware-Based API Compatibility Layer on AWS

We designed a cloud-native middleware that contained contract adapters, shielding the mobile app from any breaking changes, while enabling a complete backend switch.

API Compatibility Layer

We re-implemented the entire previous API contracts (used by the mobile app) within the middleware. To connect with Berkeley’s backend, we built an adapters that transformed requests/responses to and from Berkeley’s formats.

  • Field-level mapping between old and new APIs

  • Conditional logic for behavioral differences

  • State normalization to keep UI and backend in sync

Cloud Infrastructure & Deployment

We provisioned a production-grade AWS infrastructure using our internal Terraform templates, enabling rapid, secure, and repeatable environment creation.

Stack Components

  • Amazon ECS (Fargate): To run stateless Java microservices

  • Java 21 + Spring Boot: For modern, high-performance backend development

  • Amazon Aurora (PostgreSQL): For card metadata and state tracking

  • Amazon Cognito: For user authentication (optional, based on endpoint)

  • Amazon S3: For secure file and config storage

  • Amazon CloudFront: For fast and secure delivery to mobile clients

  • Amazon CloudWatch: For centralized observability, alerts, and logs

Testing & Seamless Cutover

To ensure a zero-downtime migration, we deployed the middleware in parallel with the legacy backend and ran full regression tests using real and synthetic traffic.

  • End-to-end integration tests were automated against the original mobile API contract.

  • We monitored shadow traffic to compare responses from both backends and validate functional parity.

  • Operational dashboards and alarms were configured in CloudWatch for real-time confidence.

Final Migration: DNS Cutover

At the go-live moment, we simply updated the DNS record to point the mobile app to the new AWS-hosted middleware.

No mobile app code change, no app update, no downtime. The mobile app continued working exactly as before, now powered by Berkeley’s backend through our middleware.




This project highlights our expertise in building cloud software solutions and Java-based cloud native systems on AWS — enabling fintech companies to change providers seamlessly and safely.

bottom of page