ConnexPay Builds a Preview-Only Files.com Alternative to Microsoft SharePoint and Ad Hoc Card Sharing

ConnexPay is a B2B payments company built on a single idea: put payment acceptance and virtual card issuing on one platform, with one contract and one reconciliation. It was the first company to do it, and the design is patented. The company grew up in travel, where agencies, tour operators, and consolidators take money in and pay suppliers out in the same motion. Today it moves more than $10 billion in payments a year for clients on six continents, issuing cards through US banking partners under Visa and Mastercard licenses.

A business like that runs on exactly the data PCI DSS exists to protect. Full card numbers, bank routing and account numbers, names, and dates of birth are the working material of card issuing. And people at ConnexPay have legitimate, everyday reasons to pass those values along: a card network requests card details, or an issuing bank needs customer validation data.

“We have to remain PCI compliant in order to make any money at all; otherwise, we're not a company.”

The question was never whether this data would be shared. It was what it would travel through. ConnexPay built a governed channel on Files.com, the same platform that carries its payments file exchange, instead of adding another product to the stack. Sensitive values could go into text files shared through password-protected, expiring, preview-only links, backed by Azure storage encrypted under keys ConnexPay manages.

Full Card Numbers in JIRA Tickets, Bank Data on SharePoint

The compliant way to share those values did not exist, and the convenient ways did. When someone needed to get a full card number to a colleague, it went where the work already happens: a JIRA ticket, a Slack message, an email. None of those channels is built to carry cardholder data, and ConnexPay's data loss prevention tooling said so constantly. Alerts fired every day.

Each alert cost the security team the same way. Someone had to chase it down, redact the value, and tell the person not to do it again. The advice never stuck, because there was nowhere better to send them.

External sharing had the same shape. Customer validation data bound for one of ConnexPay's issuing bank partners went out through SharePoint.

The problem persisted because detection is not a channel. DLP can flag a card number in a ticket, but a warning only changes behavior when there is a compliant path as easy as the one being misused. That path had a specific set of requirements: PCI-compliant end to end, with encryption under ConnexPay's own control. Simple enough for non-technical staff and for outside recipients. Access that expires on its own. And the power to grant third-party access held inside the infrastructure and security teams rather than spread across the business.

The Policy: A Text File, an Expiring Link, No Download

Files.com gave ConnexPay one governed route by which a sensitive value could leave a ConnexPay system and reach a person, inside or outside the company.

The policy the CISO defined is deliberately simple. The sensitive value, whether a card number or an API key, goes into a text file on Files.com. The person who needs it receives a Files.com share link: password-protected, set to expire, and preview-only. The recipient opens the link in a browser, previews the file, and copies the value. They cannot download it, so no copy of the file lands on a laptop or in an inbox.

“Like MasterCard asking us for cards sometimes, we can do that through Files.com, backed by our Azure storage that's using customer-managed keys for encryption.”

That last clause is load-bearing. Through a Files.com remote server mount, the files behind those links live in ConnexPay's own Azure Blob storage, encrypted under keys ConnexPay manages. Files.com is the governed front on storage the company already controls. Internal users sign in through Microsoft Entra ID on a dedicated Files.com site under a ConnexPay-branded domain, kept separate from the sites where clients and banking partners exchange files, so internal sharing and client data stay apart as a deliberate PCI control. Activity streams through the Files.com SIEM integration into Datadog, where ConnexPay's analysts already watch.

For the issuing bank partner, ConnexPay set up controlled Files.com access alongside the SharePoint process it was designed to replace. The bank's staff hold their own logins on ConnexPay's client-facing Files.com site, with folder permissions scoping exactly what they can reach and a record of their activity. Granting that access stays where the VP of Technical Operations insisted it stay: requests go through a ticket to the infrastructure and security teams.

A Compliant Answer for Every Alert

As rollout began, the new route gave the security team somewhere compliant to point people. When an alert fires on a card number in a ticket, the response no longer has to be just a warning. A Files.com link can do the same job under the controls ConnexPay defined.

ConnexPay also closed its own PCI evidence chain. Files.com supplied a PCI Attestation of Compliance as a third-party service provider, the exact evidence ConnexPay's assessment requires of every vendor that touches cardholder data.

And because the channel is a policy on a platform rather than a separate product, the next sensitive exchange already has a home. A new request from a card network or a new banking counterpart means a folder, a permission, and a link under the same rules, not a new tool.

From Policy Violation to Governed Exchange

Sharing a full card number is something ConnexPay's business legitimately requires. Its new route gives that act a defined shape: a text file, a Files.com link that expires, and a record of who opened it, on storage encrypted under ConnexPay's own keys.

That is the lesson worth carrying out of this story. DLP tooling can identify a policy violation. It cannot give employees somewhere better to put regulated data. ConnexPay's answer was to make the compliant channel as easy as the ones people were misusing, and to build it on Files.com, the platform it already ran.