How to build PayPal payment dashboards in Metabase

# PayPal (remote, OAuth in browser) — production
claude mcp add --transport http paypal https://mcp.paypal.com/http

# Sandbox: https://mcp.sandbox.paypal.com/http

{
  "mcpServers": {
    "paypal": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://mcp.paypal.com/sse"]
    }
  }
}

{
  "mcpServers": {
    "paypal": {
      "command": "npx",
      "args": ["-y", "@paypal/mcp", "--tools=all"],
      "env": {
        "PAYPAL_ACCESS_TOKEN": "<YOUR_PAYPAL_ACCESS_TOKEN>",
        "PAYPAL_ENVIRONMENT": "SANDBOX"
      }
    }
  }
}

# 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 PayPal CSV export — creates a table AND a model
mb upload csv --file paypal-transactions.csv --collection root

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

Create a polished Metabase dashboard for PayPal 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 processed volume, net revenue
after fees, refunds, disputes/chargebacks, and payment mix from PayPal data.

Step 1 — Find or load the data:
- First, check what already exists in Metabase (search for PayPal tables and
  models). If durable PayPal 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 PayPal MCP server (OAuth on the remote
  server, or an access token with the local @paypal/mcp package): transactions,
  orders/payments, captures, 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 (PayPal data often arrives as a transactions
export from the Transaction Search / Reporting API). Map the available raw tables
into these analytical concepts where possible: Transactions, Orders/Payments,
Captures, Refunds, Disputes, Fees, and Payouts. Inspect the actual tables and
column names first.

Important:
- Build on whatever data is present; don't claim Metabase connects natively to
  PayPal — it reads a database or CLI-uploaded tables.
- Separate gross processed volume from net revenue (after PayPal fees and
  refunds).
- Compute payment/capture success rate on a consistent denominator.
- Show refunds and disputes as their own lines; don't silently net them into
  volume.
- Report in a single reporting currency; PayPal is multi-currency, so convert
  with a documented rate or split by currency.
- Only build a card if its underlying column/metric exists in the data.
- A single CSV is a point-in-time snapshot: volume and dispute trends need
  history, so build trend cards only if a warehouse sync or multiple uploads
  provide it.

Dashboard title: PayPal Payments Overview

Sections:
1. Executive summary (KPI cards): Processed volume; Net revenue; Fees %; Refund
   rate; Dispute rate; Average transaction value.
2. Volume & net revenue: Volume by day; Gross vs. net; Average transaction value.
3. Refunds & disputes: Refund rate; Disputes/chargebacks by month; Win/loss rate.
4. Payments mix: Volume by payment type, country, and currency; Capture success
   rate.
5. Fees & payouts: Fees as a share of volume; Payouts over time; Net settlement.

Filters: Payment type, Country, Currency, Date range.

Reuse the models Metabase auto-created from uploaded CSVs, or (for a warehouse)
create reusable models: modeled_paypal_transactions, modeled_paypal_refunds, and
modeled_paypal_disputes.

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
PayPal reports. Keep it practical, dense, and executive-readable. Avoid vanity
metrics.

Processed volume and what lands after PayPal fees.

SELECT
  date_trunc('day', transaction_date)                 AS day,
  COUNT(*)                                            AS transactions,
  ROUND(SUM(amount) / 100.0, 2)                       AS gross_volume,
  ROUND(SUM(fee_amount) / 100.0, 2)                   AS fees,
  ROUND(SUM(amount - fee_amount) / 100.0, 2)          AS net_volume
FROM paypal_transactions
WHERE status = 'completed'
  AND transaction_date >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY 1
ORDER BY 1;

Refunds as a share of sales.

SELECT
  date_trunc('month', transaction_date)               AS month,
  COUNT(*) FILTER (WHERE txn_type = 'sale')           AS sales,
  COUNT(*) FILTER (WHERE txn_type = 'refund')         AS refunds,
  ROUND(100.0 * COUNT(*) FILTER (WHERE txn_type = 'refund')
    / NULLIF(COUNT(*) FILTER (WHERE txn_type = 'sale'), 0), 2)
    AS refund_rate_pct
FROM paypal_transactions
GROUP BY 1
ORDER BY 1;

How often you win disputes and chargebacks.

SELECT
  date_trunc('month', opened_at)                      AS month,
  COUNT(*)                                            AS disputes,
  COUNT(*) FILTER (WHERE outcome = 'won')             AS won,
  ROUND(100.0 * COUNT(*) FILTER (WHERE outcome = 'won')
    / NULLIF(COUNT(*), 0), 1)                         AS win_rate_pct
FROM paypal_disputes
GROUP BY 1
ORDER BY 1;