Draft. Needs a lawyer's review before use. Nothing on this page is in force yet. Items marked TO FILL IN need an answer. Items marked TO CONFIRM are believed true but not yet checked.

Privacy policy

Last updated: 2026-11-03 (draft)

In short

• Dunly helps businesses recover failed Stripe payments. This policy has two parts, because Dunly has two roles.
• Part A is about people who use Dunly's site and dashboard. Dunly decides how that data is used, so Dunly is the controller.
• Part B is about the customers of the businesses that use Dunly. That business is the controller, and Dunly acts for it under a data processing agreement. Go to that business first.
• Dunly has no analytics, no advertising and no marketing email. In normal use it sets one cookie of its own, which keeps you signed in.
• Dunly does not sell personal data. It shares data with the providers named below, so that the service works.
• To use your rights, write to hello@trydunly.com.

Who we are

Dunly is run by TO FILL IN (legal name, address, company number, country of establishment). You can reach us at hello@trydunly.com.

We have not appointed a data protection officer. (TO CONFIRM with the lawyer.) Representative in the EU: TO CONFIRM (needed only if the operator is established outside the EU).

Part A: people using Dunly's site and dashboard

Dunly is the controller of the data in this part. It covers the people who sign in to the dashboard, the people they invite, the people who write to us, and visitors to our site.

Most people who use the dashboard work for a business that is our customer. Our contract is with that business, not with them. So we rely on our legitimate interests for their data: Article 6(1)(f) of the GDPR. If you are yourself the customer, for example a sole trader, we rely on our contract with you: Article 6(1)(b). Below, "contract or legitimate interests" means this.

You can ask us for a summary of how we balanced our interests against yours.

Your account

• What: your email address, an id, and the date the account was created. There is no password and no name field.
• From: you, when you first sign in with a code. If a colleague invited you, they gave us your address first (see "Invites"). Dunly isn't open for new sign-ups yet, so for now only someone with a live invite can create an account.
• Why: to know who you are, and to let the right people work in an organization. Other members of your organization see your email address and your role.
• Legal basis: contract or legitimate interests. The interest is letting our customers' authorised staff use the service.
• Kept: until you delete your account. An account does not expire if unused.

You need an email address to sign in. Without one you can't use the dashboard.

Sign-in codes

• What: the email address typed, a keyed hash of the 6-digit code, the times, the number of wrong guesses, and the IP address that asked for the code.
• From: you, or whoever typed the address. Anyone can ask for a code for any address, so a row can exist for an address with no account. While sign-ups are closed, an address with no account and no live invite gets no email and no code, but the attempt is still stored: the address typed, the IP address and the times, with a keyed hash of a random value in place of a code. Dunly also asks for a fresh code before dangerous actions.
• Why: to check the code, and to limit abuse: 5 codes per address and 20 per IP address an hour, and 5 wrong guesses end a code. An attempt that sent no email counts toward these limits too.
• Legal basis: legitimate interests. The interest is keeping accounts safe.
• Kept: a code works for 10 minutes. A daily job deletes the row once a day has passed since it expired, and an attempt that sent no email goes the same way. Deleting your account deletes the rows for your address at once.

Failed sign-in attempts

• What: the IP address and the time of a wrong code. No email address.
• From: the browser that made the attempt.
• Why: to stop guessing: 30 wrong codes from one IP address in an hour block further checks from it.
• Legal basis: legitimate interests. The interest is keeping accounts safe.
• Kept: a daily job deletes the row once it is a day old. Deleting your account does not touch these rows, as they aren't linked to you.

Sessions

• What: a keyed hash of your session cookie's value, your browser's User-Agent string (the first 255 characters; it names the browser and operating system), when the session started, when it was last used, and when you last confirmed a code. No IP address is stored for a session.
• From: your browser, when you sign in and as you use the dashboard.
• Why: to keep you signed in, and to show you your sessions so that you can sign any of them out.
• Legal basis: contract or legitimate interests. The interest is keeping accounts usable and safe.
• Kept: a session ends after 14 days without use, and 30 days after sign-in at the latest. A daily job deletes it once a day has passed since it ended or you signed it out. Deleting your account deletes your sessions at once.

Memberships and who did what

• What: which organizations you belong to, and your role in each. Also who connected a Stripe account, who confirmed that Stripe's emails are off, who pressed Start recovering and who added a sending domain, with the times and the version of the terms in force at the start of recovery.
• From: you and the other members of your organization.
• Why: to decide who can do what, and to know under which terms recovery started.
• Legal basis: contract or legitimate interests. The interest is running the account and being able to show what was agreed.
• Kept: a membership goes when you leave or are removed, when you delete your account and when the organization is erased. Deleting your account clears you from the "who" records. The times and the terms version stay until the connection is erased.

Organization name and branding

• What: the organization's name, and the sender name, support address, colour and logo for recovery emails and the payment page. Some of these come from the connected Stripe account: business name, support email, colour and logo.
• From: you, your colleagues and your Stripe account.
• A new personal organization starts out named with your email address. Dunly gives it the Stripe business name when you connect Stripe, if it still carries your address and Stripe has a name. You can rename it at any time. While it carries your address, your colleagues and invitees see it. Customers don't: Dunly doesn't show them a name with an @ in it.
• If your organization has no support address, customers see an owner's email address. Dunly then uses the email address of the owner who connected Stripe, or else the earliest owner, as the support address and Reply-To on recovery emails and on the payment page. The dashboard's settings show when this is happening, and you can set another address there.
• Why: to run the service under your organization's name.
• Legal basis: contract or legitimate interests. The interest is showing customers who is contacting them and how to reach that business.
• Kept: until the organization is erased, 7 days after it is deleted. If you delete your account and an organization carries exactly your email address as its name, Dunly renames it. A name that merely contains your address is left as it is.

Invites

• What: the invited person's email address, the organization, who invited them, a hash of the invite's token, the dates, and a record of each invite email sent.
• From: the colleague or organization that invited you, not you. Our invite email tells you this and links here.
• Why: to send the invite and let you accept it. While sign-ups are closed, a live invite is also what lets a new address get a sign-in code and an account. Owners see the address and who invited it. You see the organization's name and who invited you.
• Legal basis: legitimate interests. The interest is letting our customers bring their team into the account.
• Kept: the invite link works for 7 days. The invite itself has no time-based deletion. Accepted, revoked and expired invites stay until the organization is erased, or until an account with the invited address is deleted. If you never had an account and want yours removed, write to hello@trydunly.com and we remove it by hand. The record of each invite email sent is deleted by a daily job once it is two days old.

Billing details

• What: the legal name, address, VAT number and billing email an owner enters on the Billing page. Each can name a person: a sole trader's own name, or a named billing contact.
• From: an owner of the organization, who may not be the person named.
• Why: to invoice the business.
• Legal basis: our legal duty to issue invoices and keep tax records: Article 6(1)(c). Where that duty doesn't reach, legitimate interests: collecting our fee and settling disputes about it.
• Kept: owners can change or clear them at any time, but each closed statement keeps its own copy (see below). They are not deleted when an organization is erased or an account is deleted, so that a final invoice can still be sent. Period: TO FILL IN (billing record retention, set by the tax and accounting law of the country of establishment).

You don't have to enter billing details to use Dunly, but we need them to invoice you.

The billing ledger

Dunly keeps a ledger so it can bill and prove what it billed. It keeps its own copy of what a bill needs, so erasing a case, a merchant or an organization doesn't reach it.

• What, for each recovery billed: ids for the organization, merchant and case; the Stripe account id; the Stripe invoice id and number; the amount, currency, fee, dates and who recovered it; the terms version; and a merchant name.
• The merchant name is the Stripe business name, or else the organization's name. Dunly doesn't copy an organization name with an @ in it, so a default name made from your email address stays off the ledger, and the row then has no name. A business name or organization name can still be a person's name, for a sole trader for example, and it stays.
• What, for each credit: the amount, the date, the kind, and the Stripe ids of the event and of the refunded charge or dispute.
• What, for each monthly statement: the organization's id, the month, the totals and a copy of the billing details as they stood when it closed. That copy is not updated if the details change later.
• It holds no customer names, email addresses or customer ids. But a Stripe invoice id and number lead to a customer for anyone with access to that Stripe account. See Part B.
• From: the merchant's Stripe account, the case, and the billing details above.
• Why: to bill, to credit refunds and disputes, and to answer questions about a bill.
• Legal basis: as for billing details.
• Kept: after the case log, the merchant and the organization are gone, and after your account is deleted. Period: TO FILL IN (billing record retention, set by the tax and accounting law of the country of establishment). Nothing deletes these rows automatically today, so once the period ends we have to delete them by hand.

Emails to hello@trydunly.com

• What: your address and whatever you write.
• From: you.
• Why: to answer you.
• Legal basis: contract or legitimate interests. The interest is answering people who write to us.
• Kept: TO FILL IN (support mail retention). The mail is forwarded by Cloudflare to a mailbox at TO FILL IN (mailbox provider).

Emails we send you

We send sign-in codes and invites. Owners also get a notice when a loss report finishes, and a notice when a monthly statement closes. All go through Resend. Owners can't turn those notices off, as they go with the owner role.

We send no marketing email. There is no newsletter, no mailing list and no form on our site.

Visiting trydunly.com

Our website has no cookies, no scripts, no forms and no images, and it loads no files from anyone else. The fonts are our own. What the web proxy records about a visit is covered under "Logs".

Who receives this data, and where

• The people in your organization. See above.
• Dunly's operator. Once a month the operator gets an email listing what to invoice: organization and merchant names and ids, billing details and amounts. Alerts about failures go to the same address, and can name ids such as an invoice or Stripe account. It's sent through Resend, to a mailbox at TO FILL IN (operator mailbox provider).
• Authorities, if the law requires us to give them data.
• The providers below. We name each one.

Transfers outside the EEA

Some of these providers are in the United States, so your data goes there.

On 2026-11-03 we checked the EU-US Data Privacy Framework list at dataprivacyframework.gov. It showed:

• Stripe, LLC: active.
• Cloudflare, Inc.: active.
• Amazon.com, Inc.: active. AWS says it is covered by that certification.
• Resend (Plus Five Five, Inc.): "Active - Re-certification under Review". That status can change, so check the list for the current one.

Each of these providers' data processing terms also provides for the European Commission's standard contractual clauses. You can read them at Stripe, Resend, Cloudflare and AWS. Ask us at hello@trydunly.com if you want help finding a copy.

What stays after you delete your account

You delete your account from the dashboard. You confirm with a fresh code and type your email address. You can't do it while you are the only owner of an organization that has other members: make someone else an owner, or delete the organization, first.

Deleting it erases at once your account, your sessions, your memberships, the sign-in codes for your address and every invite sent to your address. An organization where you are the only member is erased at once too, with no 7-day wait.

These stay, and this is why:

• The ledger, statements and billing details. We need them for tax and to answer questions about bills. See above.
• Organizations with other members. The data belongs to them. You are cleared from the "who" records and from invites you sent, but those invites stay, with the address of the person invited.
• Failed sign-in records for your IP address, for up to about two days. They aren't linked to you.
• Emails already sent. Resend keeps its own records for its own period (TO CONFIRM), and mail you sent us stays as "Emails to hello@trydunly.com" says.
• Backups. Deleted data stays in database backups until those backups rotate out. Backup retention: TO FILL IN.
• Logs. See "Logs".

Your rights

You can ask us:

• for a copy of your data and information about how we use it (access);
• to correct it;
• to delete it;
• to limit how we use it (restriction);
• to give you the data you gave us in a common format, or send it to someone else (portability), where the law gives you that right.

Write to hello@trydunly.com from the address you use on Dunly, or say which address you mean. We answer within one month, and we may ask you to confirm that you are who you say you are. We can refuse a request in part where the law allows, for example for records tax law makes us keep, and we tell you why.

Some of this you can do yourself in the dashboard: delete your account, see and sign out your sessions, leave an organization, and, for owners, change the billing details or revoke an invite. Revoking only ends the invite: the row and the address stay, as "Invites" says.

Some things are not built into the dashboard, so they go by email. There is no self-service export of your data, and no way to change your account's email address yourself. Write to hello@trydunly.com for either.

We don't rely on your consent for anything in Part A, so there is no consent to withdraw.

You can complain. You can complain to the data protection authority of the country where you live, where you work or where the problem happened, or to the authority of our country of establishment: TO FILL IN (authority, address and website). We'd like the chance to put it right first, but you don't have to come to us first.

Your right to object

Where we rely on legitimate interests, you can object at any time, for reasons to do with your situation. Write to hello@trydunly.com. We then stop, unless we have compelling grounds that outweigh your interests, or we need the data for a legal claim.

Automated decisions

We make no decisions about you by automated means that have legal or similarly significant effects, and we don't profile you. Sign-in limits are automatic: too many codes or wrong guesses block further tries for a while.

Children

Dunly is for businesses, not for children. We don't ask for anyone's age. If you think a child has given us their data, write to hello@trydunly.com.

Part B: customers of businesses that use Dunly

If you got an email about a failed payment, or opened a payment page, this part is for you. It is also for customers of those businesses who never heard from Dunly, as Dunly can hold data about them too:

• In a loss report. A merchant that connects Stripe gets a report on its last 90 days of failed subscription renewals. It holds each customer's email address, name, amount, dates, last decline code and outcome. It exists before the merchant starts recovery, and stays until the merchant's data is erased. It doesn't contact anyone. If the merchant later starts recovery, Dunly reads its invoices again and can then email customers whose invoices are still unpaid.
• Left to Stripe alone. A share of failed payments, chosen at random, gets no emails from Dunly. Dunly still holds a case about them.
• Known only from Stripe events. Dunly receives events about the merchant's whole Stripe account, including customers whose payments never failed. See "What Dunly handles for the merchant".

Who is responsible

The business you pay (the "merchant") is the controller of your data. It decides to use Dunly, and it holds your subscription and your Stripe customer record. Dunly acts for that merchant, on its instructions, under a data processing agreement. You can read the agreement and the list of sub-processors.

Go to the merchant first. That includes questions and requests to see or delete your data. Its support address is in the email and on the payment page. If you write to us instead, at hello@trydunly.com, we pass your request to the merchant where we can tell which one it is, and we help the merchant answer it. We keep your message as "Emails to hello@trydunly.com" says. You can also complain to a data protection authority, as in Part A.

What Dunly handles for the merchant

• From the merchant's Stripe account: your email address and name, Stripe ids, the invoice amount and currency, the invoice number and description, the reason a payment was declined, and the case's status and dates.
• Copies of Stripe events. Dunly receives invoice events, subscription cancellations, customer updates, refund and dispute events for the merchant's whole Stripe account, including customers whose payments didn't fail. An event can hold more, such as a billing address or phone number. Dunly deletes the copy once it has processed the event. It keeps a row with the event's id, type and dates and no customer data for 30 days.
• What you do: which email you were sent, that you clicked a link, that you viewed the page, that you saved a card or confirmed with your bank, and how retries went. To spot email security scanners, Dunly checks the browser's User-Agent at the click, but doesn't store it. No IP address is stored for a click or a page view.
• Bounces and complaints: an address that bounced or complained, per merchant, so that merchant's emails stop going to it.

Your merchant's privacy notice should explain why it does this. The merchant decides the legal basis.

What you see

• An email in the merchant's name, saying a payment failed, with a link to a payment page. It says it was sent by Dunly on the merchant's behalf.
• The payment page shows the merchant's name, the amount, your email address in part, the invoice number and description if there are any, and the brand and last four digits of your card. Dunly reads those two from Stripe to show them and doesn't store them.

Dunly never sees or stores your full card number or security code. You type them into Stripe's own form on the page, and they go straight to Stripe.

Dunly's email doesn't carry an unsubscribe link, because it is about a failed payment, not marketing. Dunly sends you no marketing.

To stop the emails, write to the merchant or to hello@trydunly.com. The merchant has no button for this in Dunly. It can void or settle the invoice in Stripe, which ends the emails, or write to us. If you or the merchant ask us, we stop them by hand and tell the merchant. They also end when the invoice is paid.

A share of failed payments, chosen at random, gets no emails from Dunly and is left to Stripe alone, so the merchant can see Dunly's real effect. Dunly also retries cards on a schedule, if the merchant chooses that. Neither decides anything about you beyond whether you get an email or a retry.

How long

The merchant's data stays while it is connected to Dunly. If it disconnects, the data is erased automatically within 12 months. If it deletes its organization in Dunly, the data is erased 7 days later. The merchant can ask us to delete it sooner. Deleted data stays in database backups until they rotate out: TO FILL IN (backup retention).

What Dunly does for its own purposes

A little of what happens around a payment page is for Dunly's own needs, not the merchant's:

• Limits on payment links. To stop a link being used to call Stripe without limit, Dunly counts requests per IP address (for IPv6, per /64 block) and per case. The IP address is held in memory only. An entry idle for an hour goes at the next cleanup, which runs only when another request arrives, so on a quiet system it can stay longer. All of them go when Dunly restarts. It isn't written to the database or to the logs. Legal basis: legitimate interests, namely keeping the service safe and working.
• Email provider's bounce list. Resend keeps its own list of addresses that bounced or complained, across all of Dunly's account, not per merchant. So a bounce or complaint on one merchant's email can stop another merchant's email to you. That list is at Resend, and Dunly's deletions don't reach it.
• The billing ledger. If your payment was recovered, the ledger in Part A holds the Stripe invoice id and number and the amount. It doesn't hold your name, email address or customer id. While the case still exists, the merchant's bill shows your name and email address by reading them from the case.
• Logs. See "Logs". They don't normally name you.

Cookies and similar storage

Dunly has no analytics, no advertising, no pixels, no session recording and no error reporting service. We ask for no consent, because we only use what the service needs in order to work.

Our website and the payment page. Dunly sets no cookie on trydunly.com or on the payment page, and the payment page uses no local or session storage of Dunly's.

Stripe on the payment page. The payment page loads Stripe.js from js.stripe.com whenever it opens, even for a link that has expired, and Stripe's form runs in its own frames. Stripe is a separate company, and these are its tools. Stripe says that Stripe.js collects signals about your device and activity, such as mouse movement, time on the page and device details, and sends them to Stripe to detect fraud, and that it can load hCaptcha. Stripe lists the cookies __stripe_mid (one year) and __stripe_sid (30 minutes) as essential for fraud prevention. Stripe may set these or others; we go by what Stripe says and have not listed them ourselves. Read Stripe's privacy policy, its cookie policy and its cookie list. The dashboard doesn't load Stripe.js.

Logs

Dunly's application writes a line for each request. It holds the method, the route (a pattern such as GET /pay/{token}, so a payment link's token doesn't get into the log), the status, the time taken and any error. It holds no IP address, no User-Agent, no user id, no email address, no query string and no request body. A request that matches no route isn't logged.

Other log lines hold ids (of cases, merchants, organizations, Stripe accounts, invoices and events), counts, sending domain names, and error messages. An error message from a provider can quote what it was given, which can include an email address. Alerts sent to the operator are logged too.

These logs help us run the service and fix faults. Legal basis: legitimate interests, namely keeping the service working and safe. How long they are kept: TO FILL IN (log retention).

In front of the application is a web proxy, for our site as well. Whether it records IP addresses, and for how long: TO CONFIRM.

Changes to this policy

If we change this policy in a way that matters to you, we email account holders before it takes effect, and say what changed. If we want to use your data for a new purpose, we tell you first. The date at the top shows the last change.