Test a bill fetch and paying exactly what was fetched

The checks that matter

The fetched bill carries five values and each one is a chance for the integration to return something stale or mismatched.

The consumer name is the assertion that catches the worst failure. A bill fetched for the wrong consumer number returns a real bill for a real person, and the customer pays a stranger's electricity without anything appearing wrong.

The flow as a test file

The pay button is referenced with the amount in its label, so a button that renders a different figure than the fetched bill fails at the click rather than at the confirmation.

---
mode: testing
url: https://my-testing-repo-main.vercel.app/paytm-clone-app/bills?reset=true
max_steps: 40
tags: [paytm, fintech, bills]
---

# Paytem 20.3: Electricity bill

Catalog objective: fetch an electricity bill by consumer number and pay it.
Key assertion: the fetched amount matches the amount paid.

## Fetch the bill
Select "Tata Power" in "Electricity board", type "100200300" into "Consumer number", and click "Fetch bill".

## Verify the fetched bill
Verify the bill details show "Consumer name" of "Priya Nair", "Billing period" of "Aug 2026", "Units consumed" of "284", "Due date" of "2026-09-22" and "Amount due" of "₹1,842.50".

## Pay it
Click "Pay ₹1,842.50" and verify a green banner titled "Bill paid" appears.

## Verify the amount paid matches the amount fetched
Verify the banner says "₹1,842.50" was paid to Tata Power for consumer "100200300", with transaction "PTM9095900".

The final assertion names the amount, the biller and the consumer number together, which ties the payment to the bill it was supposed to settle.

Step by step coverage

A fetch, a verification, a payment and a reconciliation.

Asserting the units consumed is unusual and worth keeping. It is the value a customer checks against their own meter, and a bill with a plausible amount and impossible usage is a biller integration problem.

Adding it to a suite

kane-cli testmd run tests/paytm/electricity-bill_test.md

Add a variant with an unknown consumer number, since a fetch that silently returns nothing is a worse experience than one that says so.

Third party integrations drift without a release on your side. Running Kane CLI in CI covers scheduled checks, and calling an API in the same run covers comparing the rendered bill against the biller response.