How to build Adyen payment dashboards in Metabase

# Adyen (official alpha, local server — build/run per the repo README)
claude mcp add adyen \
  --env ADYEN_API_KEY=<YOUR_ADYEN_API_KEY> \
  --env ADYEN_MERCHANT_ACCOUNT=<YOUR_MERCHANT_ACCOUNT> \
  -- /path/to/adyen-mcp

{
  "mcpServers": {
    "adyen": {
      "command": "/path/to/adyen-mcp",
      "env": {
        "ADYEN_API_KEY": "<YOUR_ADYEN_API_KEY>",
        "ADYEN_MERCHANT_ACCOUNT": "<YOUR_MERCHANT_ACCOUNT>"
      }
    }
  }
}

# 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 an Adyen CSV export — creates a table AND a model
mb upload csv --file adyen-settlement.csv --collection root

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

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

Goal: Help payments and finance leaders understand authorization rate, processed
and net volume, refunds, chargebacks, fees, and settlement from Adyen data.

Step 1 — Find or load the data:
- First, check what already exists in Metabase (search for Adyen tables and
  models). If durable Adyen 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 Adyen's local MCP server using read-only
  credentials: payments (authorisations), captures, refunds, chargebacks, and
  settlement detail records. 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: Payments (authorisations), Captures, Refunds,
Chargebacks/Disputes, Fees (interchange, scheme, markup), Settlements, and
Payouts. Inspect the actual tables and column names first.

Important:
- Build on whatever data is present; don't claim Metabase connects natively to
  Adyen — it reads a database or CLI-uploaded tables.
- Compute authorization rate as authorised ÷ attempted, and segment by method,
  issuer, and country.
- Separate processed volume from net settlement (after interchange, scheme, and
  Adyen fees).
- Track chargeback rate against scheme thresholds.
- Report in a single reporting currency; Adyen 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: settlement, auth-rate, and chargeback
  trends need history, so build trend cards only if a warehouse sync or multiple
  uploads provide it.

Dashboard title: Adyen Payments Overview

Sections:
1. Executive summary (KPI cards): Processed volume; Net settlement; Authorization
   rate; Refund rate; Chargeback rate; Fees %.
2. Authorization & conversion: Auth rate by day; by method/issuer; declines by
   reason.
3. Volume & net settlement: Processed vs. captured; Net settled; Fee breakdown.
4. Refunds & chargebacks: Refund rate; Chargebacks vs. thresholds; Win/loss rate.
5. Settlement & fees: Settlement timing; Fees as a share of volume; Net
   settlement by currency.

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

Reuse the models Metabase auto-created from uploaded CSVs, or (for a warehouse)
create reusable models: modeled_adyen_payments, modeled_adyen_settlement_details,
and modeled_adyen_chargebacks.

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

Authorised payments as a share of attempts.

SELECT
  date_trunc('day', created_at)                       AS day,
  COUNT(*)                                            AS attempts,
  COUNT(*) FILTER (WHERE result = 'Authorised')       AS authorised,
  ROUND(100.0 * COUNT(*) FILTER (WHERE result = 'Authorised')
    / NULLIF(COUNT(*), 0), 2)                         AS auth_rate_pct
FROM payments
WHERE created_at >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY 1
ORDER BY 1;

Where declines cluster across payment methods.

SELECT
  payment_method,
  COUNT(*)                                            AS attempts,
  ROUND(100.0 * COUNT(*) FILTER (WHERE result = 'Authorised')
    / NULLIF(COUNT(*), 0), 2)                         AS auth_rate_pct
FROM payments
WHERE created_at >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY payment_method
ORDER BY attempts DESC;

From settlement detail records — the source of truth for net.

-- Net settlement from settlement detail records
SELECT
  date_trunc('month', booking_date)                   AS month,
  ROUND(SUM(gross_debit - gross_credit) / 100.0, 2)   AS gross_amount,
  ROUND(SUM(commission + markup + scheme_fees + interchange) / 100.0, 2)
    AS total_fees,
  ROUND(SUM(net_debit - net_credit) / 100.0, 2)       AS net_settled
FROM settlement_details
GROUP BY 1
ORDER BY 1;