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

Valmar Merchant Services, operating as Valmar Payments, processes card and ACH payments with a specialty in high-risk verticals, including CBD and hemp retailers, online lenders, and debt collection agencies.

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 Valmar creates transactions from what they upload. The rest of Valmar'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 Valmar ran itself.

To scale that intake channel, Valmar 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. Valmar'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. Valmar 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.

Valmar selected Files.com to provide that merchant-facing perimeter.

A Merchant Portal Made of Accounts, Not Servers

Files.com became the front door of Valmar's processing platform: the branded SFTP endpoint merchants connect to, running under Valmar'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 Valmar already runs. When a merchant uploads a file, an event-driven pull moves it through to Amazon S3, where Valmar'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.

Valmar'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, Valmar 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.

• Valmar 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 Valmar 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 Valmar signs a merchant, an engineer provisions two accounts and the merchant starts dropping files at an endpoint carrying Valmar'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 Valmar 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.