ConnexPay Delivers Card Data with Files.com, the SFTP Server It Never Had to Build

ConnexPay is a B2B payments company that runs the two halves of a payment, accepting funds in and issuing virtual cards back out, on a single platform with one contract and one reconciliation. The design is patented. Built first for travel, an industry the payments world had long written off as high risk, ConnexPay now serves online marketplaces, ticket brokers, delivery services, and insurance and warranty providers, and processes more than $10 billion in payments a year on behalf of hundreds of clients.

The cost of ConnexPay’s outbound-only file operation arrived with a new product. ConnexPay designed a service that delivers card information to its customers, and the deliverable is a file. There was nothing to deliver it with. A revenue product was blocked on a capability the company had never built.

A business like that runs on files. Settlement files, accounting files, and payment files move constantly between ConnexPay, its clients, and its banking partners, and all of it sits inside PCI DSS scope. Yet for its entire history, ConnexPay stood on only one side of those transfers: the client side. It connected out to other companies’ servers. Nobody could connect in to ConnexPay.

Fifty Outbound Connections and Nothing to Deliver With

ConnexPay’s file estate was roughly 50 outbound SFTP connections, each one built by hand and maintained by hand by the infrastructure team, each one reaching out to a partner to pick up files. Clients who needed to exchange files with ConnexPay had to host the endpoint themselves or fetch from somewhere else. ConnexPay could require a client to put or get, but it could not hand a client a login, and it could not push a file to anyone.

Extending the old pattern was no answer: as more external clients connected over time, every new relationship would mean another bespoke connection for the same team to build and keep running.

Why a Payments Company Avoided Running a File Server

The gap was deliberate. An internet-facing file server at a payments company sits squarely inside the audit perimeter. The environment had to hold up under PCI DSS, and ConnexPay’s VP of Technical Operations set a second bar: it had to demonstrate HITRUST compliance, and an environment that could not do so would stop the project. Client data could not mix with internal data. Each client needed its own credentials, a password or a private key. And the estate ran entirely in Azure, where the obvious native answer, SFTP on an Azure Storage Account, had been set aside for its functional limitations.

So the server ConnexPay needed was specific. An SFTP endpoint a client could reach with nothing more than a username and a key. Files landing in the Azure Blob Storage the application already used. Processing triggered the moment a file arrives, instead of an application polling storage on a loop. Client-facing traffic held apart from internal users in a way an assessor would accept. ConnexPay selected Files.com to be that server.

Files.com in Front of the Azure Storage ConnexPay Already Ran

Files.com gave ConnexPay a hosted SFTP server without moving a byte of data out of its own cloud. Through a Files.com Remote Server Mount, the platform fronts ConnexPay’s Azure Blob Storage, which stays encrypted under ConnexPay’s own customer-managed keys. A client signs in with a username and a password or private key, drops settlement, accounting, or payment files, or picks up files ConnexPay has delivered, on a schedule or ad hoc. The moment a file lands, a Files.com Automation pushes it into Azure Blob for the application to process. That is the event-driven behavior the team wanted: the file’s arrival starts the work.

The compliance boundary is built out of sites. ConnexPay runs a parent site and child sites, keeping production separate from non-production and client-facing sites separate from internal users. Keeping client data apart from internal accounts was framed from the start as a PCI and HITRUST control, and the site structure enforces it rather than leaving it to a policy document.

Correctness mattered on the outbound side, too. If delivery and archiving ran as two separate jobs, a file arriving between them could be archived without ever being sent. ConnexPay used a single Files.com Move Files automation with multiple destinations to deliver the file set to a vendor’s SFTP site and move the same set into a date-organized archive in Azure. The archive can only ever contain exactly the files that were delivered.

A New Product, Delivered as Files

With the Files.com workflow in production, ConnexPay replaced a client-only posture it had held its entire history with a delivery capability its next product was built on.

“We used to just require our clients to either put or get files. Now, with your product, we are able to deliver files. Our first real implementation is around payments, a new product that we have that will deliver card information to our customers.”

The first production workload is live, and clients are connecting. The results run wider than one product:

• ConnexPay delivers payment files outbound for the first time in its history. The new card-information product runs on that capability.
• Onboarding the next client is a credential, not a construction project. Instead of another hand-built connection added to the 50 the infrastructure team already maintained, a client gets a username and a password or key on a server ConnexPay never has to host or patch.
• Regulated data never leaves ConnexPay’s Azure and stays under ConnexPay’s own encryption keys, and Files.com’s PCI Attestation of Compliance feeds ConnexPay’s own assessment as an attested third-party service provider.
• Vendor deliveries and their archive cannot drift apart. A single automation guarantees the archive holds exactly what was sent.

From SFTP Client to File-Delivery Platform

Today, a ConnexPay client that needs to exchange payment files gets a login and connects. A file the client drops starts processing the moment it arrives, and a file ConnexPay owes them is waiting for pickup or delivered to their server on schedule. Before Files.com, every one of those relationships was another outbound connection for an engineer to build by hand, and delivering anything at all was impossible.

The larger point is what ConnexPay did not have to do. It spent years avoiding an SFTP server because of what running one inside a PCI and HITRUST perimeter would cost. It still has never built one. Files.com is the server, the data sits in ConnexPay’s own Azure Blob Storage under ConnexPay’s own keys, and the company that could once only fetch files now ships a product whose entire delivery mechanism is a file.