Building a Compliance-Ready Payment API for a Fintech Under a Strict Deadline
- By Viktoriia Serhiienko
CLIENT
A US fintech company offering embedded payment infrastructure to mid-sized e-commerce platforms. The company was Series B, had around 180 employees, and was processing roughly $400M in annual payment volume at the time of engagement. They operated under a banking-as-a-service model through a partner bank, which meant their technical architecture was subject to both their own compliance requirements and the partner bank’s technical standards.
CHALLENGE
The company had committed to a large e-commerce client with a specific go-live date four months out. The client required a payment API that met PCI DSS Level 1 requirements, supported split payment flows across multiple merchant accounts, and integrated with the client’s existing order management system via a defined webhook contract.
The internal engineering team had built the company’s original payment processing layer, but that layer was not PCI Level 1 compliant. It had been built for the company’s own earlier use cases and had accumulated architecture decisions that would need to change before it could pass a Level 1 assessment. The team knew this. What they hadn’t scoped was how much of the existing architecture those changes would touch.
We were brought in six weeks after the contract with the e-commerce client was signed. The four-month deadline was fixed. The partner bank’s technical review of any new API had a six-week lead time, which was not negotiable.
SOLUTION
The first conversation was about scope. Four months to design, build, and pass a PCI Level 1 assessment for a new payment API was tight. Two months to do that while also making architectural changes to the existing payment processing layer was not realistic.
We recommended a clean separation: a new API layer built to PCI Level 1 requirements from day one, running alongside the existing layer rather than on top of it, with the existing layer left unchanged for the duration of the engagement. The e-commerce client’s integration would go through the new API. The existing layer would be addressed in a separate engagement after the deadline had passed.
The client’s CTO pushed back on this. He wanted the architectural cleanup to happen in parallel. We walked through the timeline: six weeks for the partner bank review meant the API specification needed to be locked before we had finished any architectural cleanup. We couldn’t lock a spec for a system we were still changing. The separation was necessary, not a preference.
With that settled, the first three weeks went to API specification, threat modeling, and the PCI scoping exercise. The scoping exercise determined what was in scope for the Level 1 assessment — and minimizing scope was the most important technical decision in the first month. A narrower scope meant fewer systems to harden, fewer controls to implement, and a faster path through the assessment.
The split payment flow required careful design. The e-commerce client’s merchants had complex payout structures: platform fees, seller payouts, and third-party service fees all needed to settle to different accounts from a single transaction. We built the split payment logic as a separate service with its own audit trail, isolated from the core payment processing path, with every split calculated and logged before any funds moved.
The partner bank’s technical review came back with fourteen items after six weeks. Three were blocking, eleven were advisory. We addressed the blocking items in ten days. The bank signed off on week eight.
The API passed the Level 1 assessment on the first attempt. It went live on the agreed date. The e-commerce client’s first month of processing ran without a payment routing failure.
RESULT
The API went live on the agreed date, four months after engagement start, and passed PCI DSS Level 1 assessment on the first attempt.
The e-commerce client’s first month of processing: zero payment routing failures, $12M in transaction volume processed.
The partner bank’s fourteen-item technical review was resolved in ten days for the blocking items. Completing the review without extending the timeline required prioritization decisions the client’s team hadn’t expected to have to make. Making them early was the right call.
The split payment service processed payouts to three account types per transaction across thousands of daily orders without a reconciliation error in the first sixty days.
Six months after go-live, the client signed a second large e-commerce platform. The new integration used the same API layer with configuration changes only, no new development required.
TECHNOLOGY STACK
- Java + Spring Boot – payment API layer with PCI-scoped service boundary enforced at the network level.
- PostgreSQL – transaction and audit log persistence with encryption at rest and field-level encryption for cardholder data.
- AWS (VPC, KMS, CloudTrail) – PCI-compliant infrastructure with network isolation, key management, and immutable audit logging.
- Stripe Connect – underlying payment processing for split payment flows and multi-account settlement.
- HashiCorp Vault – secrets management for API credentials and encryption keys across all environments.
- Datadog – transaction monitoring, latency tracking, and anomaly detection on payment flows.
- Terraform – infrastructure as code with separate state per environment and mandatory peer review on all changes.
If you’re building payment infrastructure under a tight compliance deadline, the scoping decisions made in the first few weeks can determine whether the timeline is achievable. We’re happy to help you define a realistic scope and timeline before commitments are made.
Viktoriia Serhiienko
Share:
