Security

1. How we think about it

A club's Verde account holds its member list, its sales and its money. That is a serious thing to be handed, and the useful response is to say exactly what protects it rather than to list certifications.

Verde is an early company. This page is written so that a club's board, or its lawyer, can read it and form an accurate picture — including of the gaps. Section 12 is the part most security pages do not have.

2. Where your data lives

Verde runs on managed infrastructure in the United States rather than on servers we rack ourselves. Databases and authentication run on Supabase, the application and club websites on Vercel, payments through Stripe, and transactional email through Resend.

That means the physical security, network hardening and patch cadence underneath Verde are handled by companies whose whole business is doing that well. It also means those companies are part of your security picture, which is why they are named here and in the privacy policy rather than described as partners.

3. Encryption

4. One club cannot see another

This is the question every multi-club platform should be able to answer directly, so: separation is enforced in the database itself, not in application code.

Every row of club data carries the club it belongs to, and row-level security policies at the database check that on every read and every write. A request for another club's bookings does not return an empty list because a query filtered it out — it is refused a layer below the application, where a bug in a feature cannot reach past it.

5. Staff access at your club

Your club decides who gets an account and what each role can do. Every plan includes unlimited staff accounts, so nobody ever needs to share one — a shared login is an audit trail that names the wrong person.

At the register, staff identify themselves with a PIN, so a void, a discount or a refund is attributable to a person. Sensitive actions — refunds, price overrides, closing out the day — are permissioned separately from taking a sale.

Removing someone's access takes effect immediately, and it is the first thing to do when a seasonal employee finishes.

6. Who at Verde can see it

Verde is a small team, and pretending otherwise would be transparent. The honest answer is that a very small number of people can reach production data, and that access exists for two reasons only: supporting a club that has asked for help, and keeping the service running.

We do not browse club data out of curiosity. We do not look at one club's numbers to inform a conversation with another. If we need to look at your data to solve something you have reported, that is what we are doing and we will say so.

Administrative access is protected by multi-factor authentication on every underlying service.

7. Card data

Card numbers never reach Verde. They go from the reader or the browser straight to Stripe. Verde stores the card brand, the last four digits, an expiry month, the amount and a refund token — nothing that can be used to charge a card anywhere else.

This is deliberate architecture rather than a policy. The safest way to hold card numbers is not to have them, and it means a compromise of Verde could not expose card data that Verde does not possess.

Stripe is a PCI DSS Level 1 service provider. Because payment data is captured by Stripe's readers and elements rather than by Verde, your club's own PCI scope stays as small as this kind of system allows.

8. The devices

Verde Driver and Verde Carry are purpose-built payment terminals. Card entry, encryption and the connection to the processor happen inside the reader's secure hardware, which the rest of the device — and Verde — cannot read.

Each terminal is registered to one club and is useless to somebody who takes it home. A lost or stolen device should be reported to us so it can be deactivated, but it is not a route into your data on its own.

Do not install other software on a Verde device, and do not use it with another payment platform. That is in the hardware section of the terms for a reason: modifying a payment terminal breaks the guarantee that the paragraph above it is true.

9. Backups and recovery

The database is backed up continuously with point-in-time recovery, so a restore can target a moment rather than the most recent nightly copy. Backups are encrypted and held in the same region as the live data.

A restore is a last resort. The more common recovery is narrower — undoing one destructive action for one club — and point-in-time recovery is what makes that possible without rolling back everybody else's day.

10. Logging and monitoring

Application errors, failed sign-ins, permission denials and payment failures are logged and watched. Logs are kept for ninety days, as stated in the privacy policy.

Logs are written so that they do not contain card numbers, passwords or session tokens. A log file that quietly collects secrets is a breach waiting for somebody to read it.

11. How Verde is built

• Every change goes through version control. There is no editing files on a live server.
• Database changes ship as reviewed migrations, so the schema has a history rather than a current state nobody can explain.
• Dependencies are kept current, and security advisories against them are treated as work rather than as noise.
• Secrets live in environment configuration, never in the repository.
• Access to production is separate from access to the code.

12. What we do not have yet

Every security page you have read claims only strengths. Here is the rest of it, because a club deciding whether to trust Verde with its member list deserves an accurate picture, and because you will find this out eventually anyway.

None of this is a reason not to use Verde. It is the reason the things in sections 3 through 11 are built the way they are: an early company should lean on architecture that fails safe rather than on process it does not yet have.

13. Reporting a vulnerability

If you have found a security problem in Verde, we want to hear about it and you will be thanked rather than threatened.

Email the contact form with enough detail to reproduce it. We acknowledge within two business days, tell you what we have found, and tell you when it is fixed.

What we ask

• Give us reasonable time to fix it before telling anyone else
• Do not access, change or keep data belonging to a club or a member — stop as soon as you have shown a problem exists
• Do not run denial-of-service tests, send spam, or use social engineering against club staff
• Use a test account rather than a live club's account

What we promise

• We will not pursue legal action over research that follows the lines above
• We will tell you what we did about it
• We will credit you if you want to be credited, and stay quiet if you do not

Verde does not run a paid bounty program yet. That is a budget fact, not a view about the value of the work.

14. If something goes wrong

If there is ever a breach affecting a club's data, we will tell that club directly and promptly — not through a status page, and not after a communications plan has been polished.

You will get what we know, what we do not yet know, what data was involved, what we have done to stop it, and what you need to do at your end. If the first message has to say that we are still working out the scope, it will say that rather than wait until the picture is tidy.

Where the law requires notice to members or to a regulator, we will meet those deadlines and help the club meet its own.

15. What we ask of your club

Most of what goes wrong in club software is not an attack on the software. These five things do more for your security than anything on the rest of this page.

• Give every person their own account. Staff accounts are unlimited on every plan.
• Remove access the day someone leaves, especially at the end of a season.
• Do not share PINs, and change one the moment it is written on something.
• Keep card numbers and ID numbers out of note fields. Free text is the most common place club data ends up where it should not be.
• Use a unique password for Verde, not the one also used for the club's email.

16. Contact

Security questions, or a club's own security review, go to a person. Send the questionnaire and we will fill it in.