> For the complete documentation index, see [llms.txt](https://help.flycode.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.flycode.com/subscription-compliance/legal-and-tracking-requirements.md).

# Legal & Tracking Requirements

What billing consent records to store (timestamp, IP, exact opt-in language) and how to monitor whether customers hit friction in your cancellation flow by comparing attempts with completions.

Two operational habits keep a subscription business on the right side of auto-renewal rules: keeping evidence of consent, and measuring whether cancellation actually works.

## Do I really need to store proof of consent for billing?

Yes. Regulators and card networks increasingly expect you to retain consent artifacts for recurring billing: the timestamp of the opt-in, the customer's IP address or device identifier, the exact language and pricing shown at the moment of consent, and the version of the terms they agreed to. A Boolean "agreed = true" flag in your database is not enough, because it cannot show what the customer actually saw. Store the rendered consent text (or a versioned reference to it) alongside the event, keep it for the life of the subscription plus your dispute window, and make it retrievable per customer. The same records are what win recurring-billing chargebacks, since issuers ask for proof the cardholder agreed to the recurring charge.

## How can I monitor whether customers are hitting friction in the cancel flow?

Track every cancellation attempt as an event, from the first click on "cancel" to completion, and compare attempts with successes. If failed or abandoned attempts exceed completions by more than about 5 percent, customers are getting stuck somewhere in the flow, which is both a compliance signal (friction is what regulators call a dark pattern) and a churn signal (a customer who cannot cancel disputes the charge instead). Instrument each step so you can see where drop-off happens, watch support tickets and chargebacks tagged "could not cancel", and review the flow whenever you change it. Separately, keep involuntary churn (failed payments) out of this metric; those customers did not try to cancel, and mixing them in hides both problems.

## Related

* [Regulatory Rules](https://help.flycode.com/subscription-compliance/regulatory-rules)
* [What Is Involuntary Churn?](https://help.flycode.com/understanding-involuntary-churn/what-is-involuntary-churn)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://help.flycode.com/subscription-compliance/legal-and-tracking-requirements.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
