Money and data, in the right place

1. Card details never pass through us

Payment takes place inside fields hosted by Stripe, a certified PCI DSS Level 1 provider. The full card number, expiry date and CVV never reach our servers.

What we see is that a payment succeeded, the amount, and the last four digits so you can recognise your card in your history. We do not store cards.

This is not just a security measure; it is a design decision. Data you don't keep can't leak from you.

2. Money is never held by us

Each player pays their share with their own card, and the amount goes directly to the partner's Stripe account. We keep the commission on the transaction and nothing else.

Kourt does not hold third-party funds and does not operate as a payment service provider. There is no escrow account holding court revenue.

3. Encryption

• In transit: all communication between the app, the website and Desk and the API runs over TLS 1.2 or higher. We serve nothing over HTTP.
• At rest: the database and backups are encrypted at disk level.
• Passwords: are not stored in readable form. Authentication is handled by a separate identity provider using modern hashing algorithms.
• Secrets: API keys and credentials live in environment variables, never in the code or the repository.

4. Role-based access

The platform has four distinct management environments — court, coach, shop and internal administration. Each person's role determines what they see, and the check is enforced in the API, not in the interface.

• A court sees only its own bookings. It cannot see another court's data.
• A coach sees only their own students.
• Internal accounts have the minimum scope their work requires.

A screen not showing a button is not security. The restriction is enforced on the server, where it cannot be bypassed from the browser.

5. Audit log

Actions with consequences are logged: availability changes, booking confirmation or cancellation, refunds, role changes, access to customer data.

The log lets us answer "who changed it and when" — which is the only useful answer when something goes wrong.

6. Data minimisation

We don't ask for data "just in case". We don't ask players for a tax ID, we don't ask for ID to let you play, and we don't ask for access to your contacts.

Location permission is optional: the app works with the area you enter yourself.

Retention periods are written down and finite — see the table in the Privacy Policy, section 9. You can delete your account and history yourself, with one click.

7. Backups and recovery

We keep automatic encrypted backups of the database, with a tested restore procedure. A backup that hasn't been tested is not a backup.

8. How we write code

• Every change goes through code review before it reaches production.
• Automated tests on the critical paths: bookings, payments, permissions.
• Dependencies are monitored for known vulnerabilities and kept up to date.
• Separate development and production environments. We don't test with real customer data.
• Inputs are validated on the server, against strict schemas.

9. If an incident occurs

If a data breach occurs that poses a risk to your rights:

1. We contain the incident and stop the cause.
2. We notify the Hellenic Data Protection Authority (HDPA) within 72 hours of becoming aware of it.
3. We notify you without undue delay, explaining what happened, which data is affected and what you should do.
4. We publish what we changed so that it doesn't happen again.

You won't hear about an incident from someone else first.

10. What you can do

• Use a unique password, ideally from a password manager.
• Don't share your account.
• We will never ask you for your password, full card number or verification code by email, message or phone. If someone asks you for it, it isn't us.
• Keep the app up to date.
• If you see something suspicious, write to hello@dinami.ai.

11. Reporting a vulnerability

If you've found a security gap, we want to know. Send what you found and how to reproduce it to hello@dinami.ai.

We commit to:

• respond within three business days,
• keep you informed of progress,
• not take legal action against you for good-faith research that did not harm user data or disrupt the service.

Please do not disclose the finding publicly before we fix it, and do not access other users' data to prove the issue.