---
title: "Payments dashboard"
slug: "payments-dashboard"
updated: 2026-03-31T15:52:41Z
published: 2026-03-31T15:52:41Z
canonical: "help.frisbii.com/payments-dashboard"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://help.frisbii.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Payments dashboard

**Plans supporting this feature:** Payment Gateway Starter Growth Scale

## 1. Overview

**Purpose**: The Payments Dashboard provides visibility into all payment activities — from successful and failed transactions to payment method performance. It helps merchants monitor cash flow reliability and optimize payment method mix.

**Who it’s for**: Finance leaders, payment operations teams, RevOps managers, customer success managers, and risk/compliance managers.

**Business Value**:

- Ensures a clear view of incoming and failed payments to maintain stable cash flow.
- Identifies friction points (failed or refunded payments) to reduce churn and revenue leakage.
- Provides insights into payment method performance for negotiation with acquirers and improving customer experience.

---

## 2. Key Questions Answered

- How many payments are successful, failed, or refunded in a given period?
- What is the total transaction amount processed?
- Which payment methods are most used, and how do they perform?
- Are there specific methods with higher risk of failed payments?

---

## 3. Metrics & Definitions

- **Transactions** Number of all processed payment transactions. *Calculation*: Count of transactions
- **Transaction Amount** The total value of all processed transactions. *Calculation*: SUM (transaction amount)
- **Settled Transactions** Payments that were successfully processed and settled with acquirers. *Calculation*: Count of transactions with state = “settled”
- **Failed Transactions** Payments that were not processed successfully due to insufficient funds, technical errors, or declined cards. *Calculation*: Count of transactions with state = “failed”
- **Refunded Transactions** Payments that were returned to the customer after initial settlement. *Calculation*: Count of transactions with state = “refunded”
- **Revenue by Payment Method (split)** Total revenue grouped by payment method type (e.g., card, SEPA, PayPal). *Calculation*: SUM (transaction amount) grouped by payment method type
- **Card Split (sub-metric in existing dashboard)** Breakdown of card payments by card type (Visa, Mastercard, Amex, etc.). *Calculation*: Count of transactions grouped by card brand

---

## 4. Filters

To enable targeted analysis, the following filters are provided:

- **Date** – Filter by transaction date to analyze payment performance over specific periods.
- **Country** – Narrow down results by customer or merchant country to compare regional payment behavior.
- **Payment Method Type** – Focus on specific payment methods (e.g., Card, SEPA, PayPal, Wallets) to assess performance or failure rates.
- **Payment Method Status** – Identify whether payment methods are *Active*, *Expired*, or *Soon to Expire* - useful for understanding continuity risks.
- **Transaction Type** – Refers to the *purpose* of the transaction — what operation it was meant to perform. This filter helps you separate normal payment collections from refunds or pre-authorizations. Common examples include:
  - **Settle** – the main payment transaction, when funds are collected
  - **Refund** – a transaction returning money to a customer
  - **Authorization** – a hold or pre-approval on funds before actual capture
- **Transaction State** – Indicates the *current status* of that transaction within the payment lifecycle. This filter is essential for distinguishing between *what kind of transaction it was* and *what ultimately happened to it*. Common values include:
  - **Settled** – successfully processed and completed
  - **Failed** – attempted but not completed (e.g., insufficient funds, declined card)
  - **Pending** – in progress or awaiting confirmation
  - **Refunded** – completed transaction later reversed
  - **Authorized** – approved but not yet captured

These filters enable targeted analysis and greater insights into specific dimensions of your revenue performance.

---

## 5. Usage Scenarios

- **Finance Leader**: Monitor overall payment health, evaluate success rates, and reconcile revenue flows with accounting.
- **RevOps Manager**: Identify payment methods driving most revenue, evaluate refund and failure trends to support GTM strategy.
- **Customer Success Manager**: Proactively address customer accounts at risk of churn due to repeated failed payments.

---

### FAQ

#### **Why does revenue not match settled invoices?**

Revenue here subtracts discounts, refunds, and credits from settled invoices, while invoices reflect the full billed amount.

#### **What's the difference between transaction type and transaction state?**

- **Transaction Type** describes *what the transaction is meant to do* — its business purpose. Example values: `settle`, `refund`, `authorization`. → Think of it as the *intent* of the payment action.
- **Transaction State** describes *what actually happened* to that transaction in the payment lifecycle. Example values: `SETTLED`, `FAILED`, `PENDING`, `REFUNDED`, `AUTHORIZED`. → Think of it as the *outcome* or current *status*.

📘 **Example:**

- A successful payment → Type: `settle`, State: `SETTLED`
- A failed payment → Type: `settle`, State: `FAILED`
- A refund → Type: `refund`, State: `REFUNDED`

In short: 👉 **Type = “What the transaction tries to do.”** 👉 **State = “What happened to it.”**