Security

Last reviewed 19 August 2026. Matchitfy is in development. No merchant data is being processed by anyone, because there are no merchants yet: the stores connected today are sandbox accounts of the platforms themselves.

What is already true

In transit

Everything is served over TLS. HTTP is redirected, never served. There is no mixed content because there are no third-party assets: no fonts, no scripts, no images loaded from anywhere but this domain.

In the browser

The content security policy allows scripts only from this origin. There is not one inline <script> and not one onclick= attribute anywhere on this site, which is what makes that policy enforceable rather than decorative. Both facts are checked by a build gate, not by anyone remembering.

Order identifiers are hashed, not stored

The identifier that would link a payout line back to a customer is stored as a hash. A copy of our database, on its own, cannot answer the question "who bought this". This is a property of the schema, enforced by a test that fails the build if a column ever holds one in the clear.

Sign-in and second factor

Accounts exist behind a password stored as a bcrypt hash, never in the clear. A second factor is available to every account: enabled in Settings, it makes sign-in require a one-time code on top of the password, and the login enforces it once it is on.

Credentials for connected systems

Access tokens for stores and accounting systems are encrypted at the application layer before they are written, with a key that lives outside the database. A database dump does not yield a usable token.

Bank access, when a merchant enables it

We never hold a bank credential. Bank connections are delegated to a regulated aggregator that holds the credential and grants us read access to transactions. We cannot move money, we cannot initiate a payment, and read access can be revoked by the merchant at any time without contacting us.

Secrets

No secret is ever committed to source control. Configuration files in the repository are templates of variable names; the values live only on the server, outside the repository, and are never printed to a log.

What is not in place yet, and what protects you meanwhile

These are open. We list them because a security page that only says what is done is not a security page.

• Volume-level disk encryption is not enabled on the current server. What matters most does not depend on it: every third-party token is encrypted by the application before it is written, so it stays unreadable even to someone holding the disk or the database, and order identifiers are stored hashed rather than merely access-controlled. Volume encryption is an additional layer, and it will be closed before the first merchant connects a store.
• No third-party penetration test yet. One is planned before general availability, and when it happens we will publish who did it and when — not just that it passed.
• No SOC 2 report or ISO 27001 certificate yet, and no badge pretending otherwise. The controls those audits look for are already in place and described on this page: encryption at rest for every third-party token, TLS everywhere, second factor available and enforced at sign-in, least-privilege read-only scopes, a hash-chained log of every action the platform runs, and no end-customer personal data in the product at all. Formal certification is a question of when, not whether. If your procurement needs a date, write to us and we will talk about the timeline instead of guessing at it here.

How the product is built

• Every database query is parameterised. String concatenation into SQL is blocked at review, and the rule holds even where the input comes from our own configuration.
• Every webhook is verified by HMAC signature before its body is read, using a comparison that takes the same time whether the signature matches on the first byte or the last.
• The database connection is never held open across a network call to an external API. This is a reliability rule rather than a security one, but an exhausted connection pool is an outage, and an outage during reconciliation is a correctness problem.
• Read-only access by default. The permissions requested from a store are read scopes. Nothing we ask for allows us to change an order, a product or a price.

Reporting a vulnerability

Write to security@matchitfy.com. Please include enough detail to reproduce it. We will acknowledge within two business days and tell you what we intend to do.

We will not take legal action against anyone who reports a problem in good faith, who does not access data belonging to anyone else, who does not degrade the service, and who gives us a reasonable chance to fix it before publishing. We do not currently pay bounties, and we will say so up front rather than after you have done the work.

If something goes wrong

Affected merchants are notified without undue delay and within 72 hours of us becoming aware, with what we know, what we do not yet know, and what we are doing. We will not wait for a complete picture, because a notification that waits for one arrives too late to be acted on.

See also the privacy policy, the terms of service and the list of subprocessors.