Security

This page describes the measures StixFlow applies to protect accounts, credentials and payment data, the part that remains the merchant’s responsibility, and how to report a vulnerability. It describes practices in place at the date shown above and is not a contractual service level.

1. Payment data

Card numbers and security codes are entered in components controlled by the payment service provider and are sent directly to it. They never reach StixFlow’s servers and are not stored by StixFlow. StixFlow receives only the result of the payment and limited information such as the card brand and its last four digits.

Payment transactions are executed by licensed payment service providers that maintain their own PCI DSS certification. Merchants remain responsible for PCI DSS compliance at the level applicable to their own integration.

2. Encryption

• In transit. All exchanges with the website, the dashboard, the payment pages and the API use HTTPS (TLS). Plain HTTP requests are redirected to HTTPS.
• At rest. Recoverable secrets, such as webhook signing secrets and the sealed copy of API keys, are encrypted with AES-256 using a key kept outside the database.

3. Accounts and credentials

• Passwords are never stored in clear text. They are hashed with Argon2id, a salted, memory-hard algorithm.
• API secret keys are verified against a hash. A sealed copy, encrypted with AES-256, allows an authorised administrator to reveal a key when support requires it; each reveal is recorded in the audit log.
• Test keys (sk_test_) and live keys (sk_live_) are distinct and cannot be used in the other environment.
• Live keys are issued only after business verification and the signature of the Merchant Agreement by both parties.
• Session cookies are not readable by scripts and forms are protected against cross-site request forgery.

4. Isolation of merchant data

Each request is executed in the context of a single merchant. Identifiers that belong to another merchant are rejected at application level. The test and production environments are strictly separate.

5. API and webhooks

• The API is authenticated by a secret key sent as a bearer token, from the merchant’s server only.
• Creation requests accept an idempotency key, so that a retry does not create a duplicate.
• Each webhook is signed with HMAC-SHA256 over a timestamp and the body. Merchants should verify the signature and reject old timestamps.

6. Fraud prevention

When a merchant turns Shield on, each payment is screened for fraud before it is authorized, and is then approved or declined. Screening does not guarantee that all fraud will be detected. Strong customer authentication is applied by the payment service provider where the regulation requires it.

7. Logging and monitoring

Application events, security events and sensitive administrative actions are logged, in particular any reveal of a merchant’s key by an administrator. Logs are used to detect, investigate and resolve incidents.

8. Hosting

The platform and its databases are hosted in the European Union by OVH SAS, which maintains its own physical and network security measures.

9. Incidents

Security incidents are assessed, contained and documented. Where an incident affects personal data, the merchants concerned are notified without undue delay, as provided in the Data Processing Agreement, and the competent authority is notified where the law requires it.

10. What merchants are responsible for

• Keeping API keys and passwords secret, on the server side only, and rotating them if they may have been exposed.
• Never placing a secret key in a web page, a mobile application or a public repository.
• Verifying webhook signatures before acting on an event.
• Securing their own websites, systems and staff access.
• Reporting to StixFlow within twenty-four (24) hours any incident likely to affect the service, their keys or payment data.
• Never sending a live secret key by email or in a support request.

11. Reporting a vulnerability

If you believe you have found a security vulnerability in StixFlow, write to [email protected]. Please include a description of the issue, the steps to reproduce it and the affected URL or endpoint.

We ask researchers to act in good faith:

• test only on your own account and in the test environment wherever possible;
• do not access, modify or delete data that is not yours, and stop as soon as you encounter any;
• do not degrade the service: no denial-of-service, no mass automated scanning, no social engineering, no physical intrusion;
• give us a reasonable time to fix the issue before disclosing it.

We acknowledge reports, keep the reporter informed of the outcome, and do not take legal action against a person who has complied with these rules. StixFlow does not currently run a paid bug bounty programme.