A Payments Processor Replaced Self-Managed SFTP With Files.com to Scale High-Risk Merchant Intake

A US payments processor handles card and ACH payments with a specialty in high-risk verticals.

An approved merchant becomes a live one when its files start flowing. Merchants deliver transaction files, including NACHA files for ACH origination, by dropping them over SFTP, and the processor creates transactions from what they upload. The rest of the processor's platform is API-driven; SFTP is the channel its merchants actually use. So every merchant needs a place to drop files, and for years that place was a server the processor ran itself.

To scale that intake channel, the processor needed merchant growth to stop meaning infrastructure growth: each new sandbox and production environment had to become a repeatable provisioning pattern without weakening isolation, automation, or auditability.

The SFTP Servers Behind the Payments Platform

Standing up an SFTP server is easy. Operating one as the front door of a regulated payments platform is not. The processor's self-managed servers came with everything infrastructure ownership brings: patching, uptime responsibility, and an internet-facing endpoint that had to stay secure, all carried by the engineering team responsible for the payments platform.

The heavier cost was isolation. A merchant must never be able to see another merchant's files, and every merchant runs in two environments, a sandbox for testing and a production environment for live transactions. On a self-run server, each of those boundaries is configuration somebody builds and maintains by hand. Every new merchant meant doing that work twice.

That repeated setup was only one layer of custom work. The processor also had to maintain uploads that flowed automatically into an S3-backed processing backend and an audit record that stood up to PCI scrutiny, retained against a seven-year requirement.

The processor selected Files.com to provide that merchant-facing perimeter.

A Merchant Portal Made of Accounts, Not Servers

Files.com became the front door of the processor's platform: the branded SFTP endpoint merchants connect to, running under the processor's own domain, with the servers, isolation, and audit trail delivered as a managed service.

Each merchant is provisioned as a pair of accounts. The sandbox account has permission only to that merchant's sandbox folder, and the production account has permission only to its production folder. Folder-scoped permissions enforce the per-merchant, per-environment boundaries that used to be hand-built server configuration.

Behind the endpoint, the platform connects to the backend the processor already runs. When a merchant uploads a file, an event-driven pull moves it through to Amazon S3, where the processor's API-driven processing takes over; an outbound sync pushes files back the other way, with a connection per environment. Provisioning and management run through the Files.com REST API, so the merchant pattern is applied by code rather than clicked together in a console.

The processor's team stood the new site up as a standalone environment, ran only test data through it until production cutover, and went live without needing guided onboarding.

Merchant Growth Without Infrastructure Growth

With the portal in production, the processor replaced a self-operated SFTP estate with a provisioning pattern. The operational difference appears each time a merchant comes onboard: instead of building and maintaining two boundaries by hand, an engineer applies the same account-and-folder structure again.

• The processor no longer stands up or maintains SFTP servers. Patching, uptime, and the internet-facing endpoint moved to Files.com.
• Onboarding a new merchant is provisioning an account pair and two scoped folders, not building or reconfiguring a server.
• Per-merchant isolation is enforced by the platform's permissions in both environments, instead of by custom configuration someone has to maintain.
• Every upload and download lands in an audit log the processor holds against its seven-year retention requirement.

As the merchant count grows, the pattern simply applies again: another account pair, another two folders, the same S3 flow, and the same audit trail.

A Payments Company, Not an SFTP Host

Today, when the processor signs a merchant, an engineer provisions two accounts and the merchant starts dropping files at an endpoint carrying the processor's name. The file lands in that merchant's own folder, flows into S3, becomes transactions, and shows up in the audit log. Nobody built a server, and nobody will patch one later.

Before Files.com, being a payments processor with an SFTP intake channel meant also being an SFTP hosting operation. What the processor proved is that the merchant-facing perimeter of a regulated platform does not have to be infrastructure the processor owns. It can be a provisioning pattern, and the engineers can stay on the payments platform, which is the business.