Test EMI plan display and the eligibility that gates it

The flow under test

The first step is the one most EMI tests leave out, and it is a negative assertion.

• Eligibility is enforced - the high value order carries an EMI badge and the low value one does not.
• The modal reflects the order - the dialog title carries the correct amount and lists EMI as a method.
• The provider is named - the plans belong to a specific bank rather than appearing unattributed.
• Every plan is correct - four tenures, each with its own interest rate and monthly amount.

Checking that EMI is absent on the cheaper item is what proves the eligibility rule exists. Without it, a page that offers EMI on everything passes every other assertion in the file.

The test file

The fourth step asserts twelve values at once, three per plan across four plans, which is the right way to cover a table where any single wrong cell is a problem.

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

# Razorpie 11.3: EMI options

Catalog objective: open payment options on a high value order and verify the EMI plans list.
Key assertion: the EMI tenures are shown with the correct interest.

## Verify EMI is offered only on the high value order
Verify the "Nexa 12 Pro 5G (256 GB)" card at "₹48,999.00" carries an "EMI available" badge and the "Cotton kurta set" card does not.

## Open the checkout for the high value order
Click "Pay now" on "Nexa 12 Pro 5G (256 GB)" and verify the dialog title reads "Razorpie · ₹48,999.00" and an "EMI" method is listed.

## Open the EMI panel
Choose "EMI" and verify the bank is "HDFB Bank" with a plans table.

## Verify the tenures and monthly amounts
Verify the plans table lists 3 months at "13% p.a." with a monthly of "₹16,688.00", 6 months at "14% p.a." with "₹8,503.00", 9 months at "15% p.a." with "₹5,790.00" and 12 months at "16% p.a." with "₹4,446.00".

Tenure, rate and monthly amount are asserted together for each plan rather than separately, because a correct rate against the wrong monthly figure is the error that actually reaches a customer.

Step by step coverage

The four steps move from the rule, to the surface, to the provider, to the figures.

Testing a rule in both directions, present where it should be and absent where it should not, is the difference between verifying a threshold and verifying a badge.

Running it

kane-cli testmd run tests/razorpay/emi-options_test.md

The result is coverage on a table of numbers that a customer is entitled to rely on, plus the rule that decides who sees it.

Financing terms change more often than the page around them, which makes the assertions the volatile part. Deriving assertions from a requirements document covers keeping them aligned with the source, and running flows in CI covers catching drift automatically.