matchitfy
Log in

Legal

Security

A product that reads a merchant's bank balance and writes to their accounting system has to be able to explain itself. This page separates what is already true from what is designed and not yet built, because a security page that blurs the two is worth nothing.

This document is available in English only. Security claims have to be exact, and an unreviewed translation of an exact claim stops being one. The English text governs.

Last reviewed 9 August 2026. Matchitfy is in development. No merchant data is being processed by anyone, because there are no merchants yet.

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.

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 built yet

These are open, and saying so is the point of this section.

  • Full disk encryption at rest is not in place on the current server. Data on disk is protected by access control, not by encryption of the volume. This is why order identifiers are hashed rather than merely access-controlled, and it will be closed before the first merchant connects a store.
  • No third-party penetration test has been done. One will be, before general availability, and we will say who did it and when.
  • No SOC 2 report and no ISO 27001 certificate. We will not imply otherwise with a badge. If your procurement process requires one, we are not ready for you yet, and that is a straight answer rather than a roadmap.
  • Multi-factor authentication for merchant accounts is designed and not yet implemented. It will exist before accounts open.

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.