How do you analyze Flutterwave payments in Metabase?

{
  "mcpServers": {
    "flutterwave": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-flutterwave",
        "--tools=read_transaction,read_transaction_with_reference,read_transaction_timeline"
      ],
      "env": { "FLW_SECRET_KEY": "your-secret-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 scoped Flutterwave export - creates a table and a model
mb upload csv --file flutterwave-export.csv --collection "Finance & Accounting"

# Refresh the same table later
mb upload replace <table-id> --file flutterwave-export.csv

Create a polished Metabase dashboard for Flutterwave finance analytics.
Work end to end: find existing modeled data first; if none exists, load a minimal
read-only snapshot or describe the warehouse sync required.

Goal: Connect Flutterwave to Metabase for transaction success, settlements, payout timing, fees, refunds, chargebacks, and reconciliation dashboards.

Inspect before querying:
- Inspect actual tables, column names, currencies, status values, and timestamps.
- Do not assume the source schema matches this guide exactly.
- Reconcile source totals before publishing any finance KPI.

Important:
- Do not claim Metabase connects natively to Flutterwave; it reads a
  supported database or CLI-uploaded tables.
- Keep native amount, native currency, and reporting-currency amount separate.
- Distinguish authorization, posting, payment, settlement, and reconciliation
  states where the source exposes them.
- Use stable business keys and apply updates/deletes during incremental syncs.
- Exclude account numbers, personal data, and secrets from broad dashboards.
- Only build cards whose required fields and history are actually present.

Dashboard sections:
1. Finance overview: Payment volume and success; Settled amount; Collection vs. payout balance; Fees and chargebacks.
2. Operations: Flagged settlements; Failed payments; Pending transfers; Refund and chargeback queue.
3. Controls and reconciliation: Successful payments not settled; Settlement destination exceptions; Duplicate references; Webhook and API freshness.
4. Planning and trends: Method and country mix; Settlement forecast; Fee-rate trend; Cross-border volume.

Suggested models: modeled_flutterwave_transactions, modeled_flutterwave_settlements, modeled_flutterwave_refunds_chargebacks.

Output: Build the dashboard if you have permission; otherwise provide the exact
questions, SQL, model definitions, and layout. State refresh time, reporting
currency, accounting basis, and any reconciliation caveats.

SELECT
  currency,
  COUNT(*) AS settled_transactions,
  percentile_cont(0.5) WITHIN GROUP (
    ORDER BY EXTRACT(EPOCH FROM (settled_at - paid_at)) / 3600.0
  ) AS median_settlement_hours,
  percentile_cont(0.9) WITHIN GROUP (
    ORDER BY EXTRACT(EPOCH FROM (settled_at - paid_at)) / 3600.0
  ) AS p90_settlement_hours
FROM modeled_flutterwave_settlements
WHERE settlement_status = 'SUCCESSFUL'
GROUP BY 1
ORDER BY 1;

Compare normalized lifecycle states from one API version with an explicit attempt denominator.

SELECT
  payment_method,
  currency,
  COUNT(*) AS attempts,
  COUNT(*) FILTER (WHERE payment_status = 'successful') AS successful,
  ROUND(100.0 * COUNT(*) FILTER (WHERE payment_status = 'successful')
    / NULLIF(COUNT(*), 0), 2) AS success_rate_pct
FROM modeled_flutterwave_payments
WHERE created_at >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY 1, 2
ORDER BY attempts DESC;