Skip to content
Human Standards

Feedback & Confirmation - Stripe Dashboard

Principle

Section titled “Principle”

System Status Visibility: Keep users informed about what’s happening through clear, immediate feedback. Never leave users wondering if their action worked.

The Problem

Section titled “The Problem”

Financial systems involve high-stakes actions where users need confidence that operations completed successfully. Traditional enterprise systems often fail by:

  • Silent failures: Actions fail with no indication
  • Vague messages: “Error occurred” with no context
  • Delayed feedback: Wait 5-10 seconds to see if it worked
  • Unclear status: Is it processing? Did it complete? Did it fail?
  • No confirmation: Action completes silently, users uncertain
  • Hidden errors: Problems buried in logs, not shown to user

This creates user anxiety and distrust:

  • “Did that work?” - Users click repeatedly
  • “Should I try again?” - Risk of duplicate transactions
  • “What went wrong?” - No actionable information
  • “Can I trust this?” - Confidence eroded by opacity

Financial platforms especially need to communicate clearly because mistakes have real monetary consequences.

Stripe’s Implementation

Section titled “Stripe’s Implementation”

Stripe’s documentation presents the Dashboard as an operational surface for finding transactions, inspecting status, managing payments, monitoring an integration, and exporting reports. That makes it a useful system-status case, but the evidence supports specific documented behaviors—not every visual or timing detail previously attributed to the product (Stripe: Web Dashboard).

Design Decisions

Section titled “Design Decisions”

1. Status is attached to the operational object

  • The Transactions area lists customer payments and their status
  • Users can filter transactions and inspect related account resources
  • The Dashboard home also surfaces unresolved disputes and identity-verification work

These capabilities are documented in Stripe’s Dashboard guide.

2. Failure information supports a next action

  • When an issuer provides decline information, Stripe exposes it in the Dashboard and API
  • Decline codes and failure messages provide diagnostic context
  • Stripe’s guidance distinguishes on-session recovery (ask for another payment method) from off-session recovery (notify the customer)

See Stripe: Card declines.

3. High-consequence actions expose scope before execution

  • The Dashboard refund flow starts from a specific payment
  • A full refund is the default, while a partial refund requires an explicit amount
  • A reason is required, with a note required for “Other”
  • Stripe documents when refunds can be canceled and exposes refund state and reference details

See Stripe: Refund and cancel payments.

4. Integration feedback preserves technical evidence

  • Workbench logs successful and failed API requests
  • Logs include the original request, response, and related API resources
  • Webhook delivery views distinguish Delivered, Pending, and Failed attempts and expose response details

Primary evidence: Stripe Dashboard: Monitor and test and Stripe: View event deliveries.

5. Asynchronous changes are represented as events

  • Stripe can push event data to registered destinations when account activity occurs
  • Events cover asynchronous outcomes such as bank confirmation, disputes, and recurring-payment success
  • Stripe explicitly warns that duplicate delivery can occur and that event order is not guaranteed

See Stripe: Receive events.

6. Reporting turns status into a durable artifact

  • Dashboard reporting covers historical transactions, payments, and payouts
  • Reports can be filtered, given custom columns, and exported
  • Stripe’s reporting documentation supports CSV download for accounting work

See Stripe: Reporting.

Together, these patterns create a chain from business object → current status → diagnostic detail → next action → event history or export. That chain is the transferable design lesson; claims about toast placement, color, animation, WebSockets, or sub-second response are outside the published evidence reviewed for this page.

Transferable Design Analysis

Section titled “Transferable Design Analysis”

The following are design inferences from the documented operational model, not Stripe-published outcome findings.

User Confidence & Trust

Section titled “User Confidence & Trust”
  • Visible object state can reduce ambiguity about what the system recorded
  • Failure context can make the next recovery step more specific
  • Event history provides evidence when the current state alone is insufficient
  • Exports let operators reconcile the interface with another record

Error Prevention & Recovery

Section titled “Error Prevention & Recovery”
  • Scoped refund inputs make amount and reason explicit
  • Status visibility can discourage repeated actions made only to check whether the first worked
  • Decline detail can route recovery to a new payment method or customer contact
  • Request and delivery logs support self-service diagnosis before escalation

Operational Efficiency

Section titled “Operational Efficiency”
  • Object-level status reduces the need to infer state from a separate log
  • Decline detail supports a defined recovery path
  • Event-delivery history gives developers evidence for integration failures
  • Exports preserve operational data for reconciliation and analysis

Business Implications

Section titled “Business Implications”
  • Traceability from a payment or refund to its current state
  • Safer operations through scoped actions and documented state transitions
  • Faster diagnosis when API calls or event deliveries fail
  • Reconciliation support through filterable and exportable reports

Evidence Boundary

Section titled “Evidence Boundary”

Stripe’s public documentation establishes the Dashboard capabilities and state model above. It does not publish the confidence, duplicate-action, support-ticket, task-time, or satisfaction comparisons previously shown on this page. Those figures have been removed.

To evaluate feedback quality in a financial operations interface, measure:

MeasureMethod
State comprehensionAsk users to identify current state and next action from defined scenarios
Duplicate-action rateRepeated mutations with the same intent, normalized by eligible actions
Recovery completionFailed operations successfully resolved without support intervention
Diagnostic timeTime from an alert to the relevant request, event, or decline evidence
Reconciliation defectsDifferences between product state and exported/accounting records

Human Standards Connection

Section titled “Human Standards Connection”
Section titled “Related Documentation”

MCP Validation Rules

Section titled “MCP Validation Rules”

When you use the Human Standards MCP server, these rules enforce feedback patterns:

feedback-immediate-required

// Triggered when actions lack immediate feedback
{
  severity: 'warning',
  rule: 'feedback-immediate-required',
  message: 'User actions should provide immediate feedback (<1 second)',
  recommendation: 'Show loading state immediately, then success/error notification',
  reference: '/interaction-patterns/notifications-feedback/'
}

feedback-success-confirmation

// Checks for success confirmations
{
  severity: 'info',
  rule: 'feedback-success-confirmation',
  message: 'Successful actions should confirm completion',
  recommendation: 'Use toast notification or inline message to confirm success',
  reference: '/interaction-patterns/notifications-feedback/'
}

defensive-specific-errors

// Validates error message specificity
{
  severity: 'error',
  rule: 'defensive-specific-errors',
  message: 'Generic error messages like "Error occurred" are not helpful',
  recommendation: 'Provide specific error with actionable recovery steps',
  reference: '/decision-making-errors/defensive-design/'
}

feedback-loading-states

// Checks for loading indicators
{
  severity: 'warning',
  rule: 'feedback-loading-states',
  message: 'Async operations should show loading state',
  recommendation: 'Use skeleton loaders or spinners to indicate progress',
  reference: '/interaction-patterns/notifications-feedback/'
}

How to Query This Pattern via MCP

Section titled “How to Query This Pattern via MCP”
// Get relevant heuristics for feedback patterns
const systemStatus = await mcp.callTool('get_heuristic', { id: 'H1' });
// Returns: Visibility of system status - loading states, feedback, progress


const errorRecovery = await mcp.callTool('get_heuristic', { id: 'H9' });
// Returns: Help users recover from errors - clear messages, solutions


// Search for feedback-specific documentation
const feedbackDocs = await mcp.callTool('search_standards', { query: 'feedback notifications' });
// Returns: Feedback patterns, timing guidelines, toast notifications


// Example results inform implementation:
// - H1 (System Status): Show loading state immediately, success/error feedback
// - H9 (Error Recovery): Specific error messages with actionable solutions
// - Feedback docs: Toast positioning, auto-dismiss timing, accessibility

How to Apply This Pattern

Section titled “How to Apply This Pattern”

React Implementation Example

Section titled “React Implementation Example”
import { useState } from 'react';


// Toast notification types
type ToastType = 'success' | 'error' | 'info' | 'warning';


interface Toast {
  id: string;
  type: ToastType;
  message: string;
  description?: string;
  duration?: number;
}


// Example toast notification component
export function ToastNotification({
  toast,
  onDismiss
}: {
  toast: Toast;
  onDismiss: () => void;
}) {
  const [isHovered, setIsHovered] = useState(false);


  // Auto-dismiss after duration (pause on hover)
  useState(() => {
    if (!isHovered && toast.duration) {
      const timer = setTimeout(onDismiss, toast.duration);
      return () => clearTimeout(timer);
    }
  });


  const icons = {
    success: '✓',
    error: '✗',
    info: 'ℹ',
    warning: '⚠'
  };


  return (
    <div
      className={`toast toast-${toast.type}`}
      role="status"
      aria-live="polite"
      onMouseEnter={() => setIsHovered(true)}
      onMouseLeave={() => setIsHovered(false)}
    >
      <div className="toast-icon" aria-hidden="true">
        {icons[toast.type]}
      </div>


      <div className="toast-content">
        <div className="toast-message">{toast.message}</div>
        {toast.description && (
          <div className="toast-description">{toast.description}</div>
        )}
      </div>


      <button
        onClick={onDismiss}
        className="toast-close"
        aria-label="Dismiss notification"
      >
        ✕
      </button>
    </div>
  );
}


// Toast container (manages multiple toasts)
export function ToastContainer({ toasts }: { toasts: Toast[] }) {
  return (
    <div className="toast-container" aria-live="polite" aria-atomic="false">
      {toasts.map(toast => (
        <ToastNotification key={toast.id} toast={toast} onDismiss={() => {}} />
      ))}
    </div>
  );
}


// Async action button with feedback states
export function AsyncActionButton({
  label,
  onAction,
  successMessage,
  errorMessage,
  variant = 'primary'
}: {
  label: string;
  onAction: () => Promise<void>;
  successMessage?: string;
  errorMessage?: string;
  variant?: 'primary' | 'danger';
}) {
  const [state, setState] = useState<'idle' | 'loading' | 'success' | 'error'>('idle');


  const handleClick = async () => {
    setState('loading');


    try {
      await onAction();
      setState('success');


      // Show success toast
      if (successMessage) {
        showToast({
          type: 'success',
          message: successMessage
        });
      }


      // Reset to idle after brief success state
      setTimeout(() => setState('idle'), 2000);
    } catch (error) {
      setState('error');


      // Show error toast
      showToast({
        type: 'error',
        message: errorMessage || 'An error occurred',
        description: error instanceof Error ? error.message : undefined
      });


      // Reset to idle after error shown
      setTimeout(() => setState('idle'), 3000);
    }
  };


  return (
    <button
      onClick={handleClick}
      disabled={state === 'loading'}
      className={`async-button ${variant} ${state}`}
      aria-busy={state === 'loading'}
    >
      {state === 'loading' && (
        <span className="button-spinner" aria-hidden="true">⏳</span>
      )}
      {state === 'success' && (
        <span className="button-icon" aria-hidden="true">✓</span>
      )}
      {state === 'error' && (
        <span className="button-icon" aria-hidden="true">✗</span>
      )}
      <span>{label}</span>
    </button>
  );
}


// Confirmation dialog for destructive actions
export function ConfirmationDialog({
  isOpen,
  onClose,
  onConfirm,
  title,
  message,
  confirmLabel = 'Confirm',
  isDangerous = false
}: {
  isOpen: boolean;
  onClose: () => void;
  onConfirm: () => Promise<void>;
  title: string;
  message: string;
  confirmLabel?: string;
  isDangerous?: boolean;
}) {
  const [isConfirming, setIsConfirming] = useState(false);


  const handleConfirm = async () => {
    setIsConfirming(true);
    try {
      await onConfirm();
      onClose();
    } catch (error) {
      // Error handling
      setIsConfirming(false);
    }
  };


  if (!isOpen) return null;


  return (
    <div className="dialog-backdrop" onClick={onClose}>
      <div
        className="confirmation-dialog"
        onClick={(e) => e.stopPropagation()}
        role="alertdialog"
        aria-labelledby="dialog-title"
        aria-describedby="dialog-message"
      >
        <h2 id="dialog-title">{title}</h2>
        <p id="dialog-message">{message}</p>


        <div className="dialog-actions">
          <button
            onClick={onClose}
            disabled={isConfirming}
            className="button-secondary"
          >
            Cancel
          </button>
          <button
            onClick={handleConfirm}
            disabled={isConfirming}
            className={isDangerous ? 'button-danger' : 'button-primary'}
          >
            {isConfirming ? 'Processing...' : confirmLabel}
          </button>
        </div>
      </div>
    </div>
  );
}


// Example status badge
export function StatusBadge({
  status,
  label
}: {
  status: 'success' | 'error' | 'pending' | 'warning';
  label: string;
}) {
  const icons = {
    success: '✓',
    error: '✗',
    pending: '⏳',
    warning: '⚠'
  };


  return (
    <span className={`status-badge status-${status}`} role="status">
      <span className="badge-icon" aria-hidden="true">
        {icons[status]}
      </span>
      <span className="badge-label">{label}</span>
    </span>
  );
}


// Skeleton loader for loading states
export function SkeletonLoader() {
  return (
    <div className="skeleton-loader" role="status" aria-label="Loading content">
      <div className="skeleton-line skeleton-line-full" />
      <div className="skeleton-line skeleton-line-75" />
      <div className="skeleton-line skeleton-line-50" />
    </div>
  );
}


// Global toast manager (simplified)
let toastCounter = 0;
const toastListeners: Array<(toast: Toast) => void> = [];


function showToast(toast: Omit<Toast, 'id'>) {
  const fullToast: Toast = {
    ...toast,
    id: `toast-${toastCounter++}`,
    duration: toast.duration || 5000
  };


  toastListeners.forEach(listener => listener(fullToast));
}

CSS Example (Operational Feedback)

Section titled “CSS Example (Operational Feedback)”
/* Toast container (top-right corner) */
.toast-container {
  position: fixed;
  top: 20px;
  right: 20px;
  z-index: 10000;
  display: flex;
  flex-direction: column;
  gap: 12px;
  pointer-events: none;
}


/* Toast notification */
.toast {
  display: flex;
  align-items: flex-start;
  gap: 12px;
  min-width: 300px;
  max-width: 450px;
  padding: 16px;
  border-radius: 8px;
  box-shadow: 0 4px 12px rgba(0, 0, 0, 0.15);
  pointer-events: auto;
  animation: slideInRight 0.3s ease-out;
}


@keyframes slideInRight {
  from {
    transform: translateX(400px);
    opacity: 0;
  }
  to {
    transform: translateX(0);
    opacity: 1;
  }
}


/* Toast variants (Stripe colors) */
.toast-success {
  background: #0ACF83; /* Stripe green */
  color: #FFFFFF;
}


.toast-error {
  background: #FF5252; /* Red */
  color: #FFFFFF;
}


.toast-info {
  background: #2196F3; /* Blue */
  color: #FFFFFF;
}


.toast-warning {
  background: #FFB020; /* Orange */
  color: #000000;
}


.toast-icon {
  font-size: 20px;
  font-weight: bold;
  min-width: 24px;
  text-align: center;
}


.toast-content {
  flex: 1;
}


.toast-message {
  font-weight: 600;
  font-size: 14px;
  margin-bottom: 4px;
}


.toast-description {
  font-size: 13px;
  opacity: 0.9;
}


.toast-close {
  background: transparent;
  border: none;
  color: inherit;
  font-size: 18px;
  cursor: pointer;
  padding: 4px;
  opacity: 0.7;
  transition: opacity 0.2s;
}


.toast-close:hover {
  opacity: 1;
}


/* Async action button states */
.async-button {
  display: inline-flex;
  align-items: center;
  gap: 8px;
  min-height: 48px;
  padding: 12px 24px;
  font-size: 16px;
  font-weight: 600;
  border-radius: 8px;
  border: none;
  cursor: pointer;
  transition: all 0.2s;
}


.async-button.primary {
  background: #635BFF; /* Stripe purple */
  color: #FFFFFF;
}


.async-button.danger {
  background: #FF5252;
  color: #FFFFFF;
}


.async-button:disabled {
  opacity: 0.6;
  cursor: not-allowed;
}


.async-button.loading {
  opacity: 0.8;
}


.async-button.success {
  background: #0ACF83;
}


.async-button.error {
  background: #FF5252;
}


.button-spinner {
  animation: spin 1s linear infinite;
}


@keyframes spin {
  to { transform: rotate(360deg); }
}


/* Status badges */
.status-badge {
  display: inline-flex;
  align-items: center;
  gap: 6px;
  padding: 4px 12px;
  border-radius: 12px;
  font-size: 13px;
  font-weight: 600;
}


.status-badge.status-success {
  background: #D4F4E7; /* Light green */
  color: #0A6E3F;
}


.status-badge.status-error {
  background: #FFE5E5; /* Light red */
  color: #C62828;
}


.status-badge.status-pending {
  background: #FFF3E0; /* Light orange */
  color: #E65100;
}


.status-badge.status-warning {
  background: #FFF9C4; /* Light yellow */
  color: #F57F17;
}


/* Skeleton loader */
.skeleton-loader {
  padding: 20px;
}


.skeleton-line {
  height: 16px;
  background: linear-gradient(
    90deg,
    #E0E0E0 25%,
    #F5F5F5 50%,
    #E0E0E0 75%
  );
  background-size: 200% 100%;
  animation: shimmer 1.5s infinite;
  border-radius: 4px;
  margin-bottom: 12px;
}


.skeleton-line-full { width: 100%; }
.skeleton-line-75 { width: 75%; }
.skeleton-line-50 { width: 50%; }


@keyframes shimmer {
  0% { background-position: 200% 0; }
  100% { background-position: -200% 0; }
}


/* Confirmation dialog */
.dialog-backdrop {
  position: fixed;
  inset: 0;
  background: rgba(0, 0, 0, 0.5);
  display: flex;
  align-items: center;
  justify-content: center;
  z-index: 9999;
}


.confirmation-dialog {
  background: #FFFFFF;
  padding: 24px;
  border-radius: 12px;
  max-width: 500px;
  width: 90%;
  box-shadow: 0 8px 32px rgba(0, 0, 0, 0.2);
}


.confirmation-dialog h2 {
  margin: 0 0 12px 0;
  font-size: 20px;
}


.confirmation-dialog p {
  margin: 0 0 24px 0;
  color: #757575;
  line-height: 1.6;
}


.dialog-actions {
  display: flex;
  gap: 12px;
  justify-content: flex-end;
}

Feedback Timing Guidelines

Section titled “Feedback Timing Guidelines”
TimingUse CasePattern
<0.1sInstant actions (button press, typing)Visual state change only
0.1-1sFast operations (save draft, simple validation)Loading indicator + success toast
1-3sMedium operations (API calls, calculations)Loading overlay + progress indicator
3-10sSlow operations (file uploads, batch processing)Progress bar with percentage + time estimate
>10sLong operations (reports, exports)Background task + email notification when done

Feedback Patterns by Action Type

Section titled “Feedback Patterns by Action Type”
Action TypeFeedback PatternExample
CreateSuccess toast + show created item”Payment created successfully”
UpdateOptimistic UI + success toast”Customer updated” (changes visible immediately)
DeleteConfirmation dialog + success toast + undo option”Customer deleted” with 5s undo window
ErrorSpecific error message + recovery action”Card declined. Ask customer to try another card.”
BackgroundProgress notification + completion alert”Export started. We’ll email you when it’s ready.”

Product Evidence Checks

Section titled “Product Evidence Checks”
QuestionDocumented Stripe evidence
Can an operator see an object’s current state?Transactions list payments and status
Does a failure expose usable detail?Dashboard and API expose available decline information and codes
Is a consequential action scoped?Refund flow starts from a payment and captures amount and reason
Can developers trace asynchronous failures?Workbench and webhook delivery views retain request and delivery status
Can operations data leave the UI?Reports and transaction data can be filtered and exported

These checks establish feature coverage, not outcome improvements. Support-ticket reduction, task speed, confidence, and duplicate-action rates require account-level research.

Section titled “Related Examples”

Human Standards Integration: Analysis updated against cited primary documentation, August 2026

Maintained by AK Lodhi