A PCI-Minimized Credit Application Middleware on AWS

The Situation

A large national specialty retailer had just migrated its eCommerce platform to SAP Commerce Cloud and was ready to launch a new revenue stream: branded credit offers at checkout. Customers would be offered both a Visa co-branded and a private-label credit card, with the ability to apply, get approved, and use the new account on the same order without leaving the site.

That deceptively simple customer experience requires a great deal of work underneath. The credit decisioning sits with Alliance Data Systems (ADS), the card tokenization for actual payment runs through Cayan, and the storefront itself is SAP Commerce Cloud. None of those systems were designed to talk to each other. They speak different protocols (JSON and SOAP/XML), sit in different trust zones, and handle card data with very different expectations. Connecting them naively would have pulled the entire SAP Commerce Cloud environment into PCI scope, and with it the retailer’s whole eCommerce infrastructure.

The retailer engaged a commerce delivery partner to run the program, and Black Magic was brought in as the architect and builder of the middleware service that would make the integration work without expanding PCI scope.

The Approach

The design intent for the middleware was simple and unforgiving: be the only part of the system that ever touches live card data, keep it in memory for as long as the transaction requires and not a millisecond longer, and let everything upstream and downstream deal exclusively in tokens.

A dedicated middleware service as the single PCI-scoped component. The browser posts the applicant’s data to the middleware as JSON. The middleware forwards to ADS for decisioning, receives back virtual card data for approved applicants, calls Cayan with a SOAP/XML request to tokenize the card, and returns only the ADS response plus the Cayan token to the browser. SAP Commerce Cloud only ever sees the token, which is the heart of keeping the storefront out of PCI scope. The middleware itself stores no card numbers. Non-PCI logging was kept deliberately minimal and audit-ready.

Multi-protocol integration, done cleanly. ADS specified its Instant Credit Application (v6.3.2) and Batch Prescreen Acceptance (v7.0.0) protocols, both JSON-over-HTTPS. Cayan was SOAP/XML with a published WSDL. Rather than leak these shapes into the consuming applications, the middleware normalized both into a clean internal model and translated at its edges. Integration testing used SoapUI against the WSDL to validate the Cayan side independently of the in-session browser flow.

A multi-AZ AWS footprint sized for the traffic pattern. The service runs in AWS US West 2 (Oregon) with high availability across two availability zones. Public subnets host application load balancers and NAT gateways. Private subnets host the EC2 application instances, so nothing compute-side is directly internet-exposed. A development subnet parallels the production layout so promotions happen with infrastructure parity, not infrastructure surprises. Everything on dual-AZ, because a credit application flow that times out in the middle is indistinguishable, from the customer’s perspective, from a broken checkout.

An approval flow that preserves the session. The integration with SAP Commerce Cloud was explicitly scoped to keep the account usable on the same order. Upon approval, the new credit account token flows back to the storefront via the customer’s session, so the payment method is already populated when the customer hits the payment step. This is the difference between “apply for credit” being a feature and being a conversion driver.

Deliverables

A middleware service designed and built from scratch, deployed to AWS
A PCI-minimizing architecture validated against audit requirements, with card data scope contained to a single service boundary
ADS Instant Credit Application and Batch Prescreen Acceptance protocol integrations
Cayan SOAP/XML tokenization integration
A dual-AZ AWS production environment plus a development environment with matching layout
Throughput and performance testing covering the realistic concurrent-applicant load
Implementation and operations documentation written for both engineering support and PCI audit review
A clean handoff point to SAP Commerce Cloud so the storefront team could consume tokens without rewriting their checkout

What Made It Land

The design was not trying to be clever. It was trying to be inspectable. A PCI middleware earns its keep by being easy for an auditor to read and easy for an on-call engineer to trace when something goes sideways at 2am. We chose conventional components, put the card-handling logic in one place, kept the blast radius small, and made every data flow explicit in the architecture documentation.

We also sized the infrastructure for the actual traffic pattern rather than for a theoretical one. Credit application volume is spiky around promotions and checkout crunches, not sustained. Dual-AZ with ALBs and right-sized instances, plus the option to scale laterally, was the right answer. Overbuilt reference architectures would have added cost and audit surface with no customer benefit.

The Takeaway

Offering credit at checkout is a conversion lever worth fighting for, but the infrastructure underneath it is where integrations go to die. Three vendors with three protocols and three security postures, one storefront that shouldn’t have to know about any of them, and an auditor who will ask hard questions. Getting this right is a specialty.