Payment Processing
API

The Problem

The client was a FinTech startup building a payment orchestration layer for SMB merchants across the EU. They had a Series A close in 10 weeks and needed a working, compliant product to demo to investors — not a mockup, not a prototype, but real transaction processing with real compliance documentation.

Their original technical co-founder had left the company six months prior. The team had working business logic in scattered Java services but nothing resembling a production API. PCI-DSS scope was unknown and undocumented. Fraud handling was an afterthought. They needed everything built from scratch, correctly, fast.

Our Approach

Week one was a compliance assessment. PCI-DSS scoping is often misunderstood — many startups over-scope themselves, taking on SAQ D requirements when SAQ A or SAQ A-EP would suffice. We mapped their payment flows, identified the appropriate compliance level, and designed an architecture that minimised scope rather than blindly applying every control.

We chose Stripe Connect as the underlying processor — not because it was the easiest option, but because it was the correct one for their merchant-of-record model and would accelerate compliance significantly. Our role was to build the orchestration layer on top: routing logic, fraud scoring, retry handling, webhook processing, and the merchant-facing API.

• Event-driven architecture with idempotency keys throughout — no duplicate charges, ever
• Rule-based fraud engine with velocity checks, device fingerprinting, and ML scoring
• Redis-backed rate limiting per merchant with configurable thresholds
• Comprehensive audit log for every state transition — queryable, immutable, exportable
• Multi-region active-passive failover on AWS (eu-west-1 primary, eu-central-1 standby)
• Real-time webhook delivery with exponential backoff and dead-letter queuing

The Build

Four two-week sprints. Sprint 1 established the core transaction lifecycle — create, capture, refund, void — with full idempotency and audit logging. Sprint 2 built the fraud engine and rate limiting. Sprint 3 added the merchant dashboard, reporting APIs, and webhook infrastructure. Sprint 4 was load testing, penetration testing, and compliance documentation.

We load-tested to 10× expected peak — 5,000 concurrent transactions — before signing off. The p95 response time at that load was 67ms. Under normal conditions, 45ms. The fraud engine flagged 94% of test fraudulent transactions in our red team exercises, with a false positive rate under 0.3%.

The Result

MVP shipped at week 8. The client had a working payment gateway, full PCI-DSS documentation, and a live demo environment ready for their investor meetings. They closed their Series A two weeks later.

Six months post-launch, the system has processed over 2.8 million transactions with 99.99% uptime across all regions. The client's engineering team has since added three engineers to the codebase — all onboarded within a week, the clearest sign the architecture held up under real conditions.