QisstPay — Hybrid Cloud Infrastructure for a BNPL Fintech
AWS ECS · GCP Cloud Run · Terraform · PCI DSS · Redis · MySQL · VPN Integrations
- QisstPay is a Buy Now Pay Later fintech, which means every piece of infrastructure touches regulated financial data. I joined as a DevOps Engineer when the platform ran almost entirely on AWS with manual, inconsistent deployments.
- Over 20 months I co-owned the migration of 17 backend microservices (Python, Java, Go) to GCP Cloud Run, maintained PCI DSS compliance across AWS workloads and the office network, and built the secure VPN integrations with banks and telecom providers used for credit scoring.
- The result was a hybrid AWS + GCP platform processing 1M+ daily transactions, with autoscaling, faster builds, and audit documentation that survived PCI DSS review.
The Challenge
The starting state was a mix of AWS services and manual processes. Deployments were slow and inconsistent.
The credit-scoring problem was its own category. To approve or decline a BNPL transaction in real time, the system needed data from banks and telecom providers. These institutions would only connect over private, audited IPsec tunnels. Each partner had a different network team, different parameters, different certificate requirements, and different timelines. What looked like one integration on a product roadmap was three or four separate infrastructure projects in practice.
Constraints
- PCI DSS compliance was non-negotiable and continuously audited -- every infrastructure change had to be defensible to an assessor.
- Financial partners (banks, telecoms) dictated their own VPN parameters and timelines; we adapted to them, never the reverse.
- Zero-downtime expectations: BNPL checkout is revenue-critical -- an outage is merchants losing sales in real time.
- I worked within a platform/DevOps team.
Key Decisions
Where to run the 17 microservicesCloud Run for the stateless microservices, ECS retained for stateful payment services
Considered: Stay on AWS (ECS everywhere) / GKE / GCP Cloud Run
Why: Cloud Run gave us per-request pricing and zero capacity planning for stateless workloads. ECS stayed for services needing persistent VPN connections where cold starts were unacceptable.
Trade-off: Two clouds means two IAM models, two networks to secure, and PCI scope documentation spanning both. We accepted the operational overhead because the autoscaling and cost model justified it.
How to keep two clouds consistentSingle Terraform codebase, separate state per environment
Considered: Console-driven setup per cloud / Terraform with per-cloud modules in one repository
Why: Auditability: when the PCI assessor asks "who changed this security group and when," the answer is a git commit, not a memory.
Trade-off: Terraform state management across two providers and multiple environments was its own overhead. Emergency console changes happened and caused drift that required manual reconciliation.
VPN architecture for bank/telecom integrationsPer-partner dedicated IPsec tunnels
Considered: Managed VPN gateways / Self-managed IPsec instances / Per-partner dedicated tunnels
Why: Each financial institution had unique IPsec parameters and certificate requirements. A shared hub would have required all partners to agree on common settings, which was not realistic.
Trade-off: More tunnels to monitor and maintain. Each partner integration was its own project with its own timeline.
PCI DSS scope boundaryNetwork-segmented cardholder data environment with minimized scope
Considered: Treat everything as in-scope / Segment a cardholder data environment and minimize scope
Why: Every system in PCI scope multiplies audit burden -- segmentation is the difference between auditing a room and auditing the building.
Trade-off: Segmentation required strict network policies and careful routing. Services that needed cardholder data had to be explicitly placed inside the CDE.
The Approach
The Cloud Run migration was the largest single project during my tenure. Seventeen stateless microservices moved from fixed-capacity infrastructure to Cloud Run, where each service auto-scales independently based on request volume. The services were already containerized, but the build pipelines, health check configurations, and traffic routing all had to be reworked for Cloud Run's model.
Terraform was the discipline layer across both clouds. We maintained a single codebase with separate state files per environment, so every infrastructure change was a pull request, a review, and a git commit. When a PCI assessor asked who changed a security group and when, the answer was a commit hash, not a memory.
PCI DSS work was continuous, not a one-time project. I was involved in audit documentation, evidence collection, and working with assessors. The office network was also in scope because developers accessed production systems from the Islamabad office.
The VPN integrations were where infrastructure work and business requirements collided most directly. The credit-scoring data flow went: merchant checkout triggers a scoring request, the scoring service queries banks and telecom providers over IPsec tunnels, receives their data, runs the scoring model, and returns an approve/decline decision -- all within the latency budget of a checkout flow.
System Architecture
Hybrid Cloud Architecture
Click any component to see how it fits into the hybrid cloud architecture.
Interactive Demo
Walk through the system design and data flow for this project step by step.
The transaction crosses two cloud providers and two private networks in under four seconds. PCI DSS scope (dashed borders above) is limited to the AWS nodes that touch cardholder data. The credit scoring service on GCP receives a tokenized payload and never sees raw card numbers. The VPN branches run in parallel -- a slow telecom response does not block the bank response.
Simplified simulation of the production transaction path. Topology and latencies are representative.
Overview
Business Impact
The Cloud Run migration moved 17 stateless microservices off fixed-capacity infrastructure and onto autoscaling. Peak transaction periods like Friday prayer surges and month-end salary disbursements no longer required capacity planning or manual scaling.
PCI DSS compliance was maintained across audits during my tenure, covering all three environments. The VPN integrations with banks and telecom partners went live and served production credit-scoring traffic throughout my time at the company.
What Went Wrong
max_connections limit. Queries started queueing, then timing out, and payment confirmations stalled for roughly eight minutes. The fix was a connection pooler in front of RDS and lowering the per-instance pool size.The second problem was slower: MySQL queries degrading over months. The transaction ledger table grew past 200 million rows and several queries were doing full table scans. The ledger lookup that checks whether a customer has an outstanding installment was scanning the entire table instead of hitting a composite index on
(customer_id, status, due_date). It had never been indexed because the table was small when the query was written. Adding the index brought the lookup from 1200ms to 3ms. We found six more queries in the same state and added slow-query logging with a 500ms threshold after that.The third was a VPN tunnel flap during a bank partner go-live. The IPsec tunnel dropped every 90 minutes in production -- a dead peer detection timeout mismatch. Our side was set to 30 seconds, theirs to 120. During low-traffic periods neither side sent keepalives fast enough. The bank network team took two weeks to acknowledge the issue. We worked around it with a cron that detected tunnel state changes and forced a rekey.
Lessons Learned
Slow queries are a deployment problem, not a DBA problem. The unindexed ledger lookup was not a mistake -- it was correct when the table had 10 million rows. The mistake was not having a process to catch it as the table grew. Slow-query logging with weekly review is trivially cheap and would have caught it months earlier.
VPN integrations with banks are infrastructure projects with a political timeline. The DPD mismatch was a five-minute config change on both sides. Getting the bank to make that change took three weeks. Every VPN integration I have done since, I insist on a shared parameter sheet signed off by both network teams before tunnel setup begins.
Technical Highlights
- Hybrid multi-cloud architecture across AWS ECS, GCP Cloud Run, and on-premise bare metal servers
- 17 microservices migrated from fixed-capacity infrastructure to autoscaling Cloud Run
- Single Terraform codebase managing both clouds with separate state per environment
- PCI DSS compliance maintained across AWS, GCP, and office network throughout my tenure
- Point-to-point IPsec VPN tunnels to banks and telecom providers for real-time credit scoring
- MySQL read/write replica topology -- primary handles transaction writes, replicas serve analytics and consumer reads
- Network segmentation with dedicated VLANs for cardholder data, internal services, and management traffic
- Encryption at rest with AES-256 for stored card data and TLS 1.2+ for all data in transit
- Centralized log aggregation with tamper-evident audit trails retained for 12 months per PCI DSS Requirement 10
- Automated vulnerability scanning with Nessus and quarterly ASV scans per PCI DSS Requirement 11
Frequently Asked Questions
Q: What were the security and compliance requirements for QisstPay?
The infrastructure had to comply with PCI DSS audits. This required strict VPC segmentation, implementing secure VPN tunnels with banking institutions, deploying a secure GCP Cloud Run setup for 17 microservices, and setting up centralized audit log collections.
Q: How was the database scaling managed for high transaction volumes?
We optimized PostgreSQL performance by establishing Redis caching layers and implementing table partitioning on transaction tables. This successfully mitigated database bottlenecks during high-volume sales events.
Q: What was the outcome of the migration to Cloud Run?
By migrating the 17 microservices from virtual machines to containerized Google Cloud Run, we established automated scale-to-zero when idle, cut code deploy times by 60%, and significantly simplified microservices management.
Want results like this for your infrastructure?
I specialize in taking complex AI pipelines and cloud setups from concept to high-availability production. Let's discuss how to optimize your workloads, secure your environment, and reduce cloud costs.