Static snapshot. A frozen copy of the operator dashboard, safe to open anywhere. The buttons below are drawn but inert — recording a verification and being refused the release is a state change, so it runs on the live app: python src/demo.py --serve.
Released
Routine payment — nothing was being changedR2a_no_change_confirmed
Semantic layer read this as a payment follow-up, and the payout destination is confirmed unchanged against the vendor master. 017561053720 (payout fund account) is a known account for this vendor
Verification — what would release this
Ask the supplier to send Rs 1 from this account, and no other:
237977812271
chosen because 237977812271: 5 settled payout(s), added 2024-06-05 via portal, verified by onboarding_kyc
Two people, not one. Whoever records the verification outcome must not be whoever releases the payment. A compromised or complicit AP clerk who can do both approves their own request, and the control is theatre. This is enforced when the button is pressed, not only drawn on the screen.
What was checked
- Supplier
- VEND0092
- Destination account
- 017561053720
- Destination came from
- The payout itself — the payout's own fund account, never the email [razorpay_fund_account]
- Fund account
- fa_0018
- Amount
- Rs 45,000.00
- Change request
- doc_bab57e91e7cbd583
- Correlated by
- Named on the payout [explicit_note]
- Evidence source
- Replayed perfect extraction [replayed_perfect_extraction]
- Semantic reading
- PAYMENT_FOLLOWUP / NONE / NONE
Accounts on file for this supplier
| Account | Added | Verified | Settled | |
|---|
| 017561053720 UTIB0610215 · active | At onboarding 2024-12-16 | Verified at onboarding (KYC) | 34 payouts | This paymentPrimary |
| 237977812271 KKBK0205993 · active | Added through the supplier portal 2024-06-05 | Verified at onboarding (KYC) | 5 payouts | |
| 902966815101 KKBK0086090 · active | Added because of an email request 2026-05-26 | Never verified outside email | 0 payouts | Never established |
An account is established once something outside email has confirmed it — onboarding checks, a rupee from the account, a callback — or once it has actually carried a payout. Being on file is not the same thing: an account can be on file because one email asked for it and nobody checked. The engine treats those as unconfirmed rather than as wrong, so they hold rather than reject.
Identity checks — against your supplier records
result
check
finding
OK
Destination account account_continuity
017561053720 (payout fund account) is a known account for this vendor
from Payout, against our records
What this maps to at RazorpayX
POST /v1/payouts/pout_0018/approve
payout released from pending
Action plans. Nothing in this repository calls Razorpay.