Test a partial refund and the balance it changes

Failure modes in this flow

A partial refund updates three separate numbers, and a dashboard can update one of them without the others.

• The refunded amount on the row - moving from $0.00 to $60.00.
• The net on that payment - $190.00, which is the original $250.00 less the refund.
• The status badge - Partially refunded rather than Completed or Refunded.
• The account total - net sales after refunds falling from $250.00 to $190.00.

The badge matters as much as the figures. A partially refunded payment marked fully refunded blocks any further refund against it, and a payment marked completed invites a second refund that should not be possible.

Writing the objective

The first step establishes the baseline, including the fact that nothing has been refunded yet, so the refund the test issues is demonstrably the one being measured.

---
mode: testing
url: https://my-testing-repo-main.vercel.app/square-clone-app/dashboard?reset=true
max_steps: 45
tags: [square, payments, refunds]
---

# Squair 12.4: Refund from the dashboard

Catalog objective: refund the latest payment partially from the dashboard.
Key assertion: the refund is recorded and the balance updates.

## Verify the starting balance
Verify "Net sales after refunds" reads "$250.00" and the "pay_8812" row shows a refunded amount of "$0.00" with a "Completed" badge.

## Open the refund dialog
Click the refund button on the "pay_8812" row and verify a dialog titled "Refund pay_8812" opens showing "Original amount" of "$250.00".

## Refund part of it
Type "60" into "Refund amount", click "Issue refund", and verify a green banner reads "Refunded $60.00 on pay_8812."

## Verify the refund and the balance
Verify the "pay_8812" row now shows refunded of "$60.00", a net of "$190.00" and a "Partially refunded" badge, and "Net sales after refunds" reads "$190.00".

The dialog is identified by its title carrying the payment id, so a refund dialog opened against a neighbouring row fails before any amount is entered.

The assertions in detail

Each assertion covers one surface the refund is supposed to reach.

Four figures asserted against one action is the right ratio for a money-moving operation. Any one of them updating alone is a defect that reconciles incorrectly at the end of the month.

Running it locally

kane-cli testmd run tests/square/refund-dashboard_test.md

Point it at a sandbox rather than a live account. The flow moves real money in a real dashboard, and a test that issues refunds against production data is a different kind of problem.

Refund logic is also a common place for an agent-written change to land without review. Verifying agent-written code in a browser covers that loop, and running Kane CLI in CI covers gating it on every merge.