Test a scan to pay flow through the PIN step

Failure modes in this flow

The merchant identity appears at three points in the flow and has to be the same one each time.

• At the scan - the merchant is identified before any amount is entered.
• At the PIN step - restated alongside the amount, which is the last confirmation before authorisation.
• On the receipt - named with their UPI address, so the payment is attributable afterwards.
• The balance - asserted before paying, so the customer knows the payment can clear.

The PIN step assertion is the important one. It is the point where the customer authorises, and a screen that shows one merchant while paying another is the fraud this flow exists to prevent.

Writing the objective

The amount is asserted on the PIN screen alongside the merchant, because those two values together are what the customer is agreeing to when they enter their PIN.

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

# PhonePey 21.1: QR scan to pay

Catalog objective: simulate the scan-to-pay flow with amount entry.
Key assertion: the payment succeeds with the merchant name shown.

## Scan a QR code
Click "Scan" on "Sunrise Chai Corner" and verify an "Enter amount" step appears.

## Enter the amount
Type "120" into "Amount", type "Two cutting chai" into "Note", verify "Available balance" reads "₹12,480.00", then click "Continue".

## Enter the UPI PIN
Verify the PIN step shows "Paying" of "Sunrise Chai Corner · ₹120.00", type "4321" into "UPI PIN", and click "Pay ₹120.00".

## Verify the success screen names the merchant
Verify a green banner titled "Payment successful" says "₹120.00" was paid to "Sunrise Chai Corner", and the receipt shows "Transaction ID" of "T-9501", "Paid to" of "Sunrise Chai Corner · sunrisechai@ybl" and "Amount" of "₹120.00".

The receipt assertion includes the merchant UPI address as well as their name, which is the value that makes a payment traceable if it is later disputed.

The assertions in detail

A scan, an amount, an authorisation and a receipt.

Asserting the available balance in the middle of the flow is a small thing that matters at a counter. A payment attempted against insufficient funds fails in front of the merchant.

Running it locally

kane-cli testmd run tests/phonepe/qr-scan-pay_test.md

Add a variant with an incorrect PIN, since a wrong PIN handled badly is the difference between a retry and an abandoned payment.

Authorisation steps are the usual reason a payment flow is left uncovered. The Kane CLI introduction covers pausing for input, and running in CI covers the headless case.