> For the complete documentation index, see [llms.txt](https://docs.coupler.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.coupler.io/sources/category/finance-and-accounting/braintree/best-practices.md).

# Best Practices

## Recommended setup

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th></tr></thead><tbody><tr><td><strong>Match credentials to environment</strong></td><td>Always confirm whether you need Sandbox or Production credentials before setting up. Mixing them is the most common source of empty or incorrect exports.</td></tr><tr><td><strong>Start with Transactions</strong></td><td>Transactions is the richest and most frequently queried entity. Get it flowing first, then layer in Subscriptions and Disputes as separate entities in the same data flow.</td></tr><tr><td><strong>Join Subscriptions to Plans</strong></td><td>Use Coupler.io's Join transformation on `plan_id` to enrich your subscription records with plan name, price, and billing frequency — useful for MRR breakdowns by tier.</td></tr><tr><td><strong>Join Disputes to Transactions</strong></td><td>Link disputes back to transactions using `transaction_id` to calculate your chargeback rate by payment method, merchant account, or date range.</td></tr></tbody></table>

## Data refresh and scheduling

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th></tr></thead><tbody><tr><td><strong>Daily refresh for Transactions and Disputes</strong></td><td>Transaction status changes (e.g., authorized → settled → disputed) happen throughout the day. A daily refresh keeps your revenue and risk numbers current.</td></tr><tr><td><strong>Weekly is enough for Plans and Discounts</strong></td><td>These entities change infrequently. A weekly or even manual refresh is sufficient unless you're actively rolling out new pricing or promotions.</td></tr></tbody></table>

## Performance optimization

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th></tr></thead><tbody><tr><td><strong>Set a meaningful start date</strong></td><td>The start date directly controls how many transaction records are fetched. For ongoing reporting, set it to 90 days or less — pull your full history separately in a one-time data flow.</td></tr><tr><td><strong>Use Aggregate for revenue summaries</strong></td><td>Rather than loading every transaction into a spreadsheet and summing there, use Coupler.io's Aggregate transformation to pre-group by day or month. This keeps destination files lean and fast.</td></tr></tbody></table>

## Common pitfalls

{% hint style="danger" %}
**Don't report on raw transaction totals without filtering by status.** Including failed, voided, or authorized-but-not-settled transactions will inflate revenue figures. Always filter to `status = settled` for accurate revenue reporting.
{% endhint %}

{% columns %}
{% column %}

#### Do

* Filter transactions by `status = settled` for revenue reports
* Use separate data flows for Sandbox vs. Production
* Join Disputes to Transactions to calculate chargeback rates
* Use Append to combine data from multiple merchant accounts
  {% endcolumn %}

{% column %}

#### Don't

* Mix Sandbox and Production credentials in the same data flow
* Set the start date to your company's founding date for routine refreshes
* Assume refunds appear as negative amounts on original transactions
* Report subscription counts without filtering by status
  {% endcolumn %}
  {% endcolumns %}


---

# 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://docs.coupler.io/sources/category/finance-and-accounting/braintree/best-practices.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.