Last updated Nov 1, 2026 · Draft under legal review, not yet in effect
Privacy Policy
This policy explains what ESDvalidator ("we", "us") collects when you use our website, the free diagnostic, the API and the dashboard (together, the "Service"), why we collect it, how long we keep it and who we share it with.
In short: We keep only what the Service needs, never store full card numbers and delete data on fixed schedules.
What we collect
- Account data: your name, work email, password (stored as a hash by our authentication provider), and two-factor settings if you turn them on.
- Organization data: organization name, team members and their roles, invitations, API keys (stored only as a keyed hash; we cannot show a key again after it is created) and the interchange rates you choose to enter.
- Diagnostic data: when you upload a fee report from Adyen or Stripe, we read it in memory and keep only the columns we need: transaction id, card brand and product, the rate received, the amount, the merchant account and the sale date. Columns outside that list, such as masked card numbers, shopper names, shopper references, emails and metadata, are discarded while the file is read. The file itself is never stored.
- API request data: for each request we keep metadata: endpoint, status, result, score, amounts, merchant reference and category code, card brand, product, funding and the first 6 digits of the card, and latency. With test keys we also keep the request payload for 7 days. With live keys we never keep the payload.
- Batch data: when you send a file to
POST /v1/batches, we keep each line until its item is processed, then only the result. The line of an item that failed because of an error on our side stays until it is retried or the batch is deleted. A line with a full card number is rejected and never stored. Each processed item is also recorded as an API request, with the metadata and retention described above. - Webhook data: for each endpoint your organization adds, the URL, the events it receives and its environment. The signing secret is stored only encrypted and shown once. For each event we keep the payload we sent and the result of each delivery: the response code or failure type and the time. We do not read the body of your endpoint's response. Webhook payloads carry no card data:
api_key.revokedcarries only the key prefix and the time it was revoked,batch.completedcarries only the batch id, status, counts and completion time, never item results, and the test event carries only the endpoint URL. - Notification data: notices shown inside the dashboard, one copy for each person, with whether that person read it, and your notification preferences. A notice holds only what its sentence needs, such as the name or email of someone who joined your team, the name and prefix of an API key, the address of a webhook endpoint, the name of a merchant, or usage and error counts. It holds no transaction data.
- Session data: for each sign-in, the browser and operating system, the city and country our hosting provider derives from your connection, and the sign-in and last access times, so you can see and sign out your sessions in your account. The IP address is not kept in this record. If you choose to trust a device, we keep only a hash of the device token, next to the browser and when it was trusted and last used.
- Check one transaction data: the transaction you paste is checked on our servers and is not stored. To limit each visitor to 10 checks a day, we keep a daily count per IP address. The IP address is stored only as a salted hash, never as the address itself, next to the day and the number of checks.
- Contact sales data: when you write to us through Contact sales, your name, work email, company, company type, pricing model, monthly commercial card volume, gateway and message. The form sends them to our inbox by email; they are not stored in the Service's database.
- Technical data: our hosting provider records standard request logs, such as IP address, time and path, to run and secure the Service.
What we never collect
- Full card numbers. Every uploaded file and every API request is checked for card numbers before anything is stored. A file with a full card number is rejected as a whole, and an API request with one is rejected with an error. Neither is stored.
- Gateway credentials. The diagnostic works from files you download yourself. We never ask for your Adyen or Stripe login or API keys.
How we use it
- To provide the Service: run diagnostics, answer API requests and show results in your dashboard.
- To secure the Service: authentication, rate limits, abuse prevention and the audit log of changes in your organization.
- To contact you about your account, security and material changes to the Service.
- To answer your Contact sales request and talk with you about a plan.
We do not sell or share your personal information for advertising.
How long we keep it
| Data | Retention |
|---|---|
| Fee report you upload for a diagnostic | Read in memory and never stored. A file that contains a full card number is rejected as a whole. |
| Normalized diagnostic rows (transaction id, card product, rate received, amount, merchant account) | 90 days, then deleted automatically. |
| Diagnostic summary | Until your organization deletes the diagnostic or the organization itself. |
| API request payloads | Stored only for test keys, for 7 days. Payloads sent with live keys are never stored. |
| API request metadata (endpoint, result, score, amounts, card product, first 6 digits of the card, latency) | 13 months, then deleted automatically. |
| Audit log (who did what, and when, in your organization) | 1 year, then deleted automatically. |
| Batch files sent to POST /v1/batches (each line as sent) | Each line is deleted as soon as its item is processed. Only the line of an item that failed because of an error on our side is kept, so it can be retried, until the batch is deleted. A line with a full card number is rejected and never stored. |
| Batches and their results (status, counts and the result of each item) | 30 days after the batch is sent, then deleted automatically by a daily cleanup. |
| Webhook endpoints (URL, events and environment) | Until an owner or admin deletes the endpoint, or the organization is deleted. |
| Webhook signing secrets | Stored only encrypted and shown once, when the endpoint is created or the secret is rolled. After a roll, the previous secret keeps signing for 24 hours. Deleted with the endpoint. |
| Webhook events and deliveries (event payload, response code or failure type, attempt times) | 30 days, then deleted automatically by a daily cleanup. Deleting an endpoint deletes its deliveries. |
| Sign-in sessions (browser and operating system, city and country, sign-in and last access times) | A session ends after 12 hours, or after 30 days with “Keep me signed in”, or when you sign it out. Records of sessions that ended more than 30 days ago are deleted the next time you sign in, and all of them when your account is deleted. |
| Trusted devices (a hash of the device token, browser, and when it was trusted and last used) | Trusted for 30 days from when you confirm the code. Records that expired or were removed more than 30 days ago are deleted the next time you trust a device, and all of them when your account is deleted. |
| In-portal notifications (the notice, and whether you read it) | 90 days, read or not, then deleted automatically by a daily cleanup. A person who leaves an organization loses its notifications at once. |
| Notification preferences | Until you change them or your account is deleted. |
| Account and organization data | While your account is active. Deleting an organization removes its diagnostics, keys and request data. You can ask us to delete your account at any time. |
| Check one transaction daily count (salted hash of the IP address, day and number of checks) | Kept for the current and the previous day (UTC), then deleted automatically by a daily cleanup. The transaction you paste is never stored. |
| Contact sales messages | Kept in our hi@ inbox for 24 months after our last exchange, unless you become a customer, or sooner if you ask us to delete it. Customers follow the account and organization data row. |
| Full card numbers | Never stored. Requests that contain one are rejected. |
Deletion runs automatically on a daily or monthly schedule, so data may remain for up to one cycle after its retention period ends. Session and trusted device records are cleaned up when you sign in or trust a device, as the table says.
Who we share it with
We use these subprocessors to run the Service. They process data only on our instructions.
| Subprocessor | Purpose | Location |
|---|---|---|
| Supabase, Inc. | Database and user authentication | United States (us-east-1) |
| Vercel Inc. | Hosting and application runtime | United States (iad1) |
| Resend, Inc. | Transactional email: account emails and Contact sales messages | United States |
We may also disclose information when required by law or to protect the rights and safety of our users and the Service.
Cookies
We use only the cookies needed to keep you signed in and secure your session. We do not use advertising or analytics cookies.
- Sign-in cookies: they close with your browser, or last 30 days if you choose "Keep me signed in", together with a cookie that records that choice for the same 30 days.
- Trusted device cookie: set only if you choose to trust a device, for 30 days. It holds a random token; we keep only its hash.
Security
Data is encrypted in transit. Each organization's data is isolated at the database level, API keys are stored as keyed hashes, and two-factor authentication is available for every account. See the Data Processing Agreement for the full list of measures.
Your rights
You can ask to access, correct, export or delete your personal information. Residents of California and other US states with privacy laws have these rights under those laws, and we will not discriminate against you for using them. Organization owners can delete diagnostics directly in the dashboard. For anything else, write to hi@esdvalidator.com.
When we process data on behalf of a business customer, such as the transactions in a fee report, that customer decides how the data is used. Requests about that data should go to the customer, and we will help them answer.
Children
The Service is for businesses and is not directed to anyone under 18.
Changes
We will post changes on this page and update the date above. For material changes, we will also notify account owners by email.