Test UPI intent validation with two rejection cases

The flow under test

A malformed address and an unresolvable one are different failures, and collapsing them into one error message is itself the bug.

• Malformed - "priya" has no bank handle, which is a format problem the page can detect locally.
• Unknown - "nobody@okhdfb" is well formed but resolves to no account, which requires a lookup.
• Valid - "priya@ybl" verifies and produces a confirmation naming the address.

The two errors are asserted by their exact text because they tell the customer different things to do. A format error means fix the typing; an unknown address means check with the recipient. One generic message for both leaves the customer guessing.

The test file

The field is cleared and replaced between attempts rather than appended to, which is what a customer correcting a mistake actually does and what a stale-state bug depends on.

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

# Razorpie 11.2: UPI intent

Catalog objective: choose UPI and verify the intent screen with VPA entry works.
Key assertion: VPA validation and the success state both render.

## Open the UPI intent screen
Click "Pay now" on "Cotton kurta set", make sure "UPI" is selected, and verify a "UPI ID" field with a "Verify UPI ID" button is shown.

## Verify a malformed VPA is rejected
Type "priya" into "UPI ID", click "Verify UPI ID", and verify an inline error reads "Enter a valid UPI ID, for example name@bank."

## Verify an unknown VPA is rejected
Replace the UPI ID with "nobody@okhdfb", click "Verify UPI ID", and verify an inline error reads "No account found for that UPI ID."

## Verify a good VPA succeeds
Replace the UPI ID with "priya@ybl", click "Verify UPI ID", verify a badge reads "UPI ID verified - request will be sent to priya@ybl", then click "Pay ₹1,899.00" and verify a green banner titled "Payment successful" appears.

The final step chains verification and payment together, since by that point the flow is known to be working and the remaining question is whether a verified address completes.

Step by step coverage

Three of the four steps are negative or boundary cases, which is the right balance for a test about a validation rule.

Replacing the value between attempts also tests something the file does not state explicitly: that a previous error clears when the input changes.

Running it

kane-cli testmd run tests/razorpay/upi-intent_test.md

What you end up with is a validation test that distinguishes between failures instead of treating them as one red state.

Validation rules are the most mechanical thing to generate a suite for, and the most tedious to write by hand. Generating validation cases covers that, and exact string assertions covers pinning each message.