Test a standard checkout modal with UPI

The flow under test

The interesting assertion in a UPI flow is the verification step, because the payment request goes to an address that has to be confirmed before anything is sent.

• The modal offers the right methods - UPI and Card, listed under a title carrying the amount.
• The address is verified before use - a badge confirming the request will go to the entered UPI ID.
• The payment succeeds - a success banner rather than a modal that closes silently.
• The receipt is complete - payment id, amount, method and the address it was captured against.

Asserting the UPI ID inside the success message is what ties the captured payment to the address the customer confirmed. A payment captured against a different address is a reconciliation problem on both sides.

The test file

The modal title is asserted with the amount in it, which is a cheap way to confirm the dialog opened for the right order rather than for a default or a cached one.

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

# Razorpie 11.1: Checkout modal

Catalog objective: trigger the Razorpie checkout and pay with the UPI success flow.
Key assertion: the payment succeeds and a receipt is shown.

## Open the checkout
Click "Pay now" on "Cotton kurta set" and verify a dialog titled "Razorpie · ₹1,899.00" opens listing the "UPI" and "Card" methods.

## Enter a UPI ID
With "UPI" selected, type "priya@okhdfb" into "UPI ID" and click "Verify UPI ID", then verify a badge reads "UPI ID verified - request will be sent to priya@okhdfb".

## Pay
Click "Pay ₹1,899.00" and verify a green banner titled "Payment successful" appears.

## Verify the receipt
Verify the banner shows payment "pay_R701kLm8Xq" captured for "₹1,899.00" via UPI (priya@okhdfb), and the Payments card lists that payment at "₹1,899.00".

The final step checks both the banner and the payments list, so a payment that confirms on screen and never reaches the merchant record fails.

Step by step coverage

The four steps follow a customer through the modal, with an assertion at each point where the flow could silently diverge.

Checking the payments list as well as the banner is the difference between a confirmation the customer saw and a payment the merchant has.

Running it

kane-cli testmd run tests/razorpay/checkout-modal_test.md

The result is coverage on an embedded payment surface you do not own, driven entirely through what it renders.

Method-specific paths diverge enough to deserve their own files. Generating a file per method keeps that cheap, and the Kane CLI introduction covers the basics of running them.