Test a payment link and that it cannot be paid twice

The flow under test

Single use is a property that only fails after it has already worked once, which is why it survives most testing.

• The unpaid state is explicit - an awaiting payment badge, not merely a form with no result yet.
• Payment succeeds - a banner confirming the link has been paid.
• The record is complete - a paid badge, a payment id, a date and the amount.
• Reuse is blocked - the pay button is replaced by a disabled one stating the link is already paid.

The fourth assertion checks for a disabled control rather than for a missing one, which is the better behaviour and the harder thing to get right. A link that simply removes its button leaves the visitor wondering whether the page is broken.

The test file

The unpaid badge is asserted before payment, which gives the final paid assertion something to be a change from rather than a state that might always have been there.

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

# Razorpie 11.4: Payment link

Catalog objective: open a payment link, complete a test payment and verify the paid state.
Key assertion: the link shows as paid and cannot be reused.

## Verify the unpaid link
Verify the page shows "Design consultation - 1 hour" at "₹3,500.00" with a badge reading "Awaiting payment".

## Pay the link
Type "4111 1111 1111 1111" into "Card number", click "Pay ₹3,500.00", and verify a green banner titled "This link has been paid" appears.

## Verify the paid state
Verify the badge now reads "Paid", the banner names payment "pay_R701kLm8Xq" on "2026-09-15" and "Amount paid" reads "₹3,500.00".

## Verify it cannot be reused
Verify the pay button is replaced by a disabled button reading "Link already paid", with the note that a payment link can only be used once.

The step ceiling is 40 rather than the 45 used on the checkout flows, matching a shorter single-page journey.

Step by step coverage

Each step establishes one end of the transition the link makes, and the last one checks it cannot be made again.

Asserting the starting state before the change is what makes the final assertion meaningful. Without it, a link permanently marked paid would satisfy step three.

Running it

kane-cli testmd run tests/razorpay/payment-link_test.md

What you get is coverage on the property that makes a payment link safe to share, which is the property a happy path test never reaches.

Links shared outside your control are also worth checking from a second browser session. The three Kane CLI modes covers running with a clean profile, and the test.md format covers keeping both cases as separate files.