How to build Dodo Payments dashboards in Metabase

# Dodo Payments (local NPX server)
claude mcp add dodopayments \
  --env DODO_PAYMENTS_API_KEY=<YOUR_DODO_API_KEY> \
  -- npx -y dodopayments-mcp@latest

{
  "mcpServers": {
    "dodopayments": {
      "command": "npx",
      "args": ["-y", "dodopayments-mcp@latest"],
      "env": { "DODO_PAYMENTS_API_KEY": "<YOUR_DODO_API_KEY>" }
    }
  }
}

{
  "mcpServers": {
    "dodopayments": {
      "command": "npx",
      "args": [
        "-y", "mcp-remote", "https://mcp.dodopayments.com/sse",
        "--header", "Authorization:Bearer ${DODO_PAYMENTS_API_KEY}"
      ],
      "env": { "DODO_PAYMENTS_API_KEY": "<YOUR_DODO_API_KEY>" }
    }
  }
}

# Install the Metabase CLI
npm install -g @metabase/cli

# Log in (opens your browser; requires Metabase v62+)
mb auth login --url https://your-metabase.example.com

# Load a Dodo Payments CSV export — creates a table AND a model
mb upload csv --file dodo-payments.csv --collection root

# Refresh that same table later from a new export
mb upload replace <table-id> --file dodo-payments.csv

Create a polished Metabase dashboard for Dodo Payments analytics.
Work end to end: get the data into Metabase if it isn't there yet, then build.

Goal: Help founders and finance leaders understand payment volume, net revenue,
subscriptions/MRR, failures, refunds, disputes, and payouts from Dodo Payments
data.

Step 1 — Find or load the data:
- First, check what already exists in Metabase (search for Dodo tables and
  models). If durable Dodo data is already present — synced from a warehouse or
  uploaded earlier — use it and skip to Step 2.
- If nothing is there, pull it with the Dodo Payments MCP server using a
  read-only API key: customers, payments, subscriptions, refunds, disputes, and
  payouts. Write each result to a CSV, then load it with the Metabase CLI — run
  "mb upload csv --file <export>.csv" so each upload creates a table and a
  ready-to-query model. Use "mb upload replace <table-id> --file <export>.csv" to
  refresh an existing table instead of creating duplicates.

Step 2 — Inspect before querying:
Do not assume exact table names. Map the available raw tables into these
analytical concepts where possible: Customers, Payments, Subscriptions, Products,
Refunds, Disputes, and Payouts. Inspect the actual tables and column names first.

Important:
- Build on whatever data is present; don't claim Metabase connects natively to
  Dodo — it reads a database or CLI-uploaded tables.
- Dodo is a merchant of record: separate gross from net (after Dodo fees and
  tax). Report net for what the business keeps.
- Compute MRR from active subscriptions, normalizing to a monthly amount.
- Compute payment success rate as succeeded ÷ attempted, scoped to comparable
  payment types.
- Exclude refunds and disputes from net revenue and show their impact
  separately.
- Only build a card if its underlying column/metric exists in the data.
- A single CSV is a point-in-time snapshot: MRR movement and trends need history,
  so build trend cards only if a warehouse sync or multiple uploads provide it.

Dashboard title: Dodo Payments Overview

Sections:
1. Executive summary (KPI cards): Payment volume; Net revenue; MRR; Payment
   success rate; Refund rate; Disputes this month.
2. Payments & net revenue: Volume by day; Gross vs. net; Average transaction
   value.
3. Success & failures: Success rate; Failures by reason; Failures by country and
   method.
4. Subscriptions & MRR: MRR movement; Active subscriptions; Revenue churn.
5. Refunds, disputes & payouts: Refund rate; Disputes by month; Payouts and
   settlement timing; Fees as a share of volume.

Filters: Product, Country, Payment method, Currency, Date range.

Reuse the models Metabase auto-created from uploaded CSVs, or (for a warehouse)
create reusable models: modeled_dodo_payments, modeled_dodo_subscriptions, and
modeled_dodo_mrr (a monthly per-subscription MRR model).

Output: Build the dashboard if you have permission; otherwise provide the exact
questions, SQL, model definitions, and layout. Include caveats for any metric
that cannot be calculated from the available data. Reconcile totals against the
Dodo dashboard. Keep it practical, dense, and executive-readable. Avoid vanity
metrics.

Processed volume and how reliably payments go through.

SELECT
  date_trunc('day', created_at)                       AS day,
  COUNT(*)                                            AS payments,
  COUNT(*) FILTER (WHERE status = 'succeeded')        AS succeeded,
  ROUND(100.0 * COUNT(*) FILTER (WHERE status = 'succeeded')
    / NULLIF(COUNT(*), 0), 2)                         AS success_rate_pct,
  ROUND(SUM(amount) FILTER (WHERE status = 'succeeded') / 100.0, 2)
    AS gross_volume
FROM payments
WHERE created_at >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY 1
ORDER BY 1;

Net revenue is what lands after Dodo fees and tax.

SELECT
  date_trunc('month', created_at)                     AS month,
  ROUND(SUM(amount) / 100.0, 2)                       AS gross_revenue,
  ROUND(SUM(amount - tax_amount - fee_amount) / 100.0, 2) AS net_revenue
FROM payments
WHERE status = 'succeeded'
GROUP BY 1
ORDER BY 1;

Recurring revenue from active subscription products.

-- Requires a monthly MRR model built from Dodo subscriptions
SELECT
  ROUND(SUM(mrr), 2)       AS mrr,
  ROUND(SUM(mrr) * 12, 2)  AS arr,
  COUNT(*)                 AS active_subscriptions
FROM modeled_dodo_mrr
WHERE month = date_trunc('month', CURRENT_DATE);