Test a mobile recharge and the plan it actually applies

Failure modes in this flow

A recharge that charges the right amount against the wrong plan is the defect worth building this test around, because the price looks perfect.

• The number and operator - both set, since a plan is only valid for one network.
• The selected plan - 299 rupees for 28 days, restated after selection.
• The charge - the recharge confirmed against that number and that amount.
• The receipt - operator, plan, validity and the benefits the plan includes.

The benefits line is the one that separates this from a payment test. A customer who paid for unlimited calls and a hundred texts a day has bought that, not a price, and the receipt is where the promise is recorded.

Writing the objective

The plan is chosen by its price and data allowance together, because a plan list often contains several entries at the same price with different validity.

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

# Paytem 20.2: Mobile recharge

Catalog objective: recharge a prepaid number, choosing a plan.
Key assertion: the plan amount is charged and a receipt is shown.

## Enter the number and operator
Type "9876543210" into "Mobile number" and select "Jiofy" in "Operator".

## Choose a plan
Choose the "₹299.00 · 2 GB/day" plan and verify "Selected plan" reads "₹299.00 · 28 days".

## Recharge
Click the recharge button and verify a green banner titled "Recharge successful" says "9876543210" was recharged with the "₹299.00" plan.

## Verify the receipt
Verify the receipt shows "Transaction ID" of "PTM9095900", "Operator" of "Jiofy", "Plan" of "₹299.00 · 2 GB/day · 28 days" and "Benefits" of "Unlimited calls + 100 SMS/day".

The selected plan is asserted immediately after selection and again on the receipt, which catches a selection that displays correctly and submits something else.

The assertions in detail

Entry, selection, payment and the record.

Asserting the operator on the receipt matters more than it looks. A recharge submitted against the wrong network fails at the telecom rather than in the app, long after the money has gone.

Running it locally

kane-cli testmd run tests/paytm/mobile-recharge_test.md

Add a variant where the number and the operator do not match, since that mismatch is the most common real world recharge failure.

Plan catalogues change constantly while the flow around them does not. Generating plan variants covers keeping up, and running in CI covers catching a catalogue change early.