Dashboard Operations

The dashboard gathers context around a single record for payment operations. The menu shows Transactions; in the API and domain model these records are payments. Charges are provider attempts; multiple charges under one payment are normal (routing fallback, re-confirm).

This page reflects current screens; do not assume alarm or reporting features that are not listed.

Sidebar (left menu)

Menu groups and items are fixed in the dashboard left menu. The Surface column below is the sidebar label you see in the UI. Detail screens are not separate sidebar items; open them from the relevant list row or global search.

Global search (command palette): navigates to payment, charge, refund, and payment method IDs.

Dashboard group

Payments group

Billing group

Providers group

Developers group

Additional features group

Outside the sidebar but common in operations: top bar account switcher (production / sandbox), Settings (account members, sandbox accounts).

Detail screens (not in sidebar, opened from lists)

Transactions list

The list paginates payments for the selected account. Click a row or the eye icon to open detail.

Columns: payment ID (copyable short display), amount, status, customer (email/name/ID), charge count, relations (charges / routing_plans / events summary with tooltip), created at.

List data: API call requests include_charges, include_routing_plans, include_events, include_customer with payment; charge and event counts are visible before opening detail.

Pagination: 10 / 25 / 50 / 100 rows.

Transaction detail (payment hub)

The header shows payment status and shortened ID. Cards below follow operational review order.

Summary and money

• Hero: Amount, currency, status badge.
• Lifecycle: Payment status (map to merchant order state).
• Money: Authorized / captured / refunded totals from charges; compare with payment amount.

Identity and context

• Fingerprints: Payment ID, account, checkout session ID, provider and config references (copyable); links to related charge rows.
• Customer: Linked customer summary.
• Checkout session: If payment has checkout_session_id, session card loads (status, token context).

Payment method (important)

The Payment Methods card shows methods used on this payment per charge attempt tab (newest attempt on top).

Typical fields per tab:

• Card type, method ID, network badge, status
• Resolution: network, brand, country, issuer, IIN, provider name
• Customer context: customer_id, guest / non-guest, attach status to customer
• Fingerprint: primary / secondary fingerprint (if present)
• Save preference: requested, planned, affected, failed (card save plan after confirm)

If there are no charges, only payment method records; if charges exist, tabs follow charge order priority.

Provider and attempts

• Providers / Provider configs: Summaries of providers and configs seen on charges.
• KPI: Short metrics such as number of providers tried.
• Charges: Per attempt: status, attempt_no, amount, error summary (if declined), provider/method name; JSON preview (side sheet) and Go to charge detail (/charges/{id}).

Routing and events

• Routing plans: Plan ID, current_index; mini flow preview on hover; full plan in side sheet (React flow).
• Events: Timeline; row click opens event sheet: trace_id, request_id, payment_id, charge_id, routing_plan_id, checkout_session_id, payload JSON.
• Routing flow (full width): Tabbed interactive routing diagram when multiple plans exist (candidates, outcome nodes, charge mapping).

Other

• Metadata: Merchant metadata JSON.

Side panels (sheet)

Panels opened from detail without leaving the page:

Charges list

All charge attempts in account scope.

Columns: charge ID, amount, status, payment ID (shortened), transaction reference (provider_order_id or rrn from transaction; no flat transaction_id field), provider name, created at.

Row click opens charge detail.

Charge detail

API: rich detail with include_attempt_details=true.

Cards:

For decline or REQUIRES_ACTION analysis, this screen goes deeper than the charge list on payment detail.

Payment Methods list

Saved payment methods on the account (card tokens, guest checkout methods, etc.).

List columns: ID, type, network, customer ID, guest/non-guest badge, status, save preference summary (planned / affected), created at.

Row actions (conditional):

• Attach: When ACTIVE, not guest, and no customer: dialog to attach to customer
• Detach: When linked to customer: detach confirmation
• Attach/detach disabled for guest or inactive methods

Detail screen:

• Basics: type, category, network, status, issuer, country
• Customer context + attach/detach buttons (same rules as list)
• Fingerprint primary / secondary
• Save preference flags
• Raw metadata JSON

Same data model as method tabs on payment detail; hub screen manages all account methods.

Recommended review order (incident)

1. Open detail by payment ID from sidebar Transactions.
2. Check merchant state expectation with Lifecycle and Money.
3. On Charges card: how many attempts, which status (especially DECLINED).
4. On Payment Methods tabs: which card/network/issuer was tried.
5. Use Routing + Routing flow to see if fallback happened.
6. Take request_id / trace_id from Events; match with webhook log.
7. If needed, drill into Charges detail (charge row or sidebar).
8. If checkout-sourced, verify Checkout session card.

Redirect or Virtual Terminal result alone is not proof; close with status on these screens and webhook.

Sandbox account selection

The top bar account picker switches between production and linked sandbox accounts. Transactions, Charges, and Payment Methods lists show data for the selected account; sandbox outcome is not a live financial guarantee.

Team focus areas

Related docs

• Request Trace and Observability
• Business Flow - Payments & Charges
• Payment Lifecycle and Confirm
• Data Models - Payments & Charges
• Webhook Delivery and Security