# UPI Payments Verification > Motivations for This Exploration UPI (Unified Payments Interface) is widely used around the world. This exploration looks into how it works and how we can improve its privacy and verification methods 1. Understanding and possibly improving its signature verification system. 2. Exploring ways to create privacy-focused verification methods. **TL;DR:** This writeup is an exploration of UPI, but we couldn't verify UPI payments through the existing endpoints. However, these endpoints are "interesting," and that's why we are discussing them here. ## Open Problem Statements 1. How can we verify whether a specific UPI transaction occurred? 2. How can we prove that a particular individual received a specific amount? 3. What mechanisms can verify UPI payments while preserving user privacy? ## Current Solutions 1. One way we can verify UPI payments using ZKPs is through emails, a method already implemented and shipped by the [ZKP2P](https://zkp2p.xyz/) team. However, the problem lies in frequent changes to email templates, and only a few banks provide content-rich information for verifying the payment. 2. With the rise of web proofs, we can verify bank statements using existing technology in the web proofs ecosystem. 3. Another interesting approach to explore is the possibility of bank statement PDFs being digitally signed. I'm collecting most of the bank statement PDFs to check whether they have a digital signature. If they do, we can extract the signature and selective content from these PDFs and create a ZK proof of payment using something like [ASN.1 Parser Circom](https://github.com/zkemail/asn1-parser-circom). > You can check if a bank statement PDF is digitally signed using the demo at [ASN.1 Parser Circom](https://asn1-parser-circom.onrender.com/). The demo does not store any PDF content and is open source. ### What is UPI? Unified Payment Interface is a middleware system connecting multiple banks, enabling seamless bank payments. It provides a user-friendly experience for fund transfers. ### UPI Modes - P2P (Peer-to-Peer) - P2M (Peer-to-Merchant) - VPA (Virtual Payment Address): Masks user account details, enhancing privacy. ### Transaction Types: - PUSH (initiated by the sender) - PULL (initiated by the receiver) ## Payment Verification API's The UPI system uses multiple layers of signatures to verify payments at different stages, usually 3-4. These signatures are not publicly accessible, which makes direct verification difficult. A key challenge is how to extract transaction details and signatures for verification. > Payment gateways follow NPCI guidelines and use AES encryption with TLS protocols. ### Merchant API Payment Verification Payment gateways like Razorpay, PayU, and Paytm Business provide secure systems for transactions. They use encryption methods like AES and TLS and follow NPCI rules. Some of these systems have endpoints to check UPI payments, which return a signature. This signature, encrypted using AES, includes a checksum to ensure the request or response hasn’t been changed. Verifying the checksum and signature is enough to confirm that a payment happened, like confirming person A sent money to person B’s VPA address. NPCI-partnered gateways, like Paytm, also provide tools like the Paytm Business SDK for payment verification. ### Example: Paytm Business SDK API The Paytm SDK lets you check payment status by creating a signature with a merchant key. This signature ensures the payment verification request hasn’t been tampered with. However, only the admin or someone with the merchant key can verify payments, as the key is needed to create and check signatures. This means the system depends on centralized control—without the key, verification isn’t possible. For example, if you run a payment portal or website, only the admin can verify payments because they hold the key. problem with this approach we can only verify payment only with merchant sk key because we are signature interally with KEY as secret in paychecksum ### Paytm SDK Signature Generation: [algorithm](https://github.com/paytm/Paytm_Node_Checksum/blob/master/PaytmChecksum.js#L32) ```javascript class PaytmChecksum { static generateSignature(params, key) { // Key is merchant's secret key // Without this key, signature can't be generated if (typeof params !== "string"){ params = PaytmChecksum.getStringByParams(params); } return PaytmChecksum.generateSignatureByString(params, key); } static async generateSignatureByString(params, key) { var salt = await PaytmChecksum.generateRandomString(4); return PaytmChecksum.calculateChecksum(params, key, salt); } } ``` ### Sample Response for payment verification API. ```json { "head": { "responseTimestamp": "1553496322922", "version": "v1", "clientId": "C11", "signature": "xxxxx" }, "body": { "resultInfo": { "resultStatus": "TXN_SUCCESS", "resultCode": "01", "resultMsg": "Txn Success" }, "txnId": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", "bankTxnId": "xxxxxxxxxxxxxxx", "orderId": "xxxxxxx", "txnAmount": "100.00", "txnType": "SALE", "gatewayName": "HDFC", "bankName": "HSBC", "mid": "xxxxxxxxxxxxxxxxxxxx", "paymentMode": "CC", "refundAmt": "100.00", "txnDate": "2019-02-20 12:35:20.0", "authRefId": "50112883" } } ``` ### TPV (Third Party Validation) for UPI - TPV is **NOT** a general UPI payment verification mechanism - It's a **mandatory requirement specifically for BFSI sector** (Banking, Financial Services, Insurance) - Required by SEBI for specific use cases like securities, broking, mutual funds - Main purpose: Ensure payments come only from registered bank accounts #### Who Uses TPV? Stock Brokers & Mutual Fund Companies - To verify client trades come from registered bank accounts - Example: When client buys stocks worth ₹10,000, broker must verify payment source > Most of the sdk which offer TPV are follow similar mechnaism because of this strict regulations. ##### Why TPV Cannot Be Used for General UPI Verification TPV (Third Party Verification) has several limitations that make it unsuitable for general UPI verification. First, its scope is limited as it only works for registered bank accounts, and it is specifically intended for use within the BFSI (Banking, Financial Services, and Insurance) sector. Additionally, TPV requires prior bank account registration, which restricts its usage. Secondly, there are regulatory requirements that mandate the use of TPV, such as SEBI regulations. It is not designed to be a general-purpose verification tool and is specifically tailored for financial institutions. These constraints prevent TPV from being a viable solution for broader UPI verification needs. In TLV, since we are generating signature we can validate this signature Generating Signature ![image](https://hackmd.io/_uploads/SJNVvKA8Jx.png) Validating Signature ![image](https://hackmd.io/_uploads/H1C5UKAUye.png) ### Conclusion In both cases we explored, only admins can verify the payment due to the use of symmetric signatures and a secret on the server side. The signature generation process relies on the merchant's secret key, which is required to validate the payment. This means that without access to the merchant's secret, third parties cannot perform payment verification. **Third-party validation** refers to the process of verifying the authenticity of a payment transaction by an external entity, separate from the transaction's origin or destination parties. This can help confirm the integrity of the transaction and prevent fraud. Many payment SDKs, like those provided by Razorpay, offer endpoints for third-party validation as it is approved by NPCI. These endpoints help verify the payment status by using signatures and predefined guidelines. Razorpay's API review can be found here: [Razorpay API Review - Third-Party Validation](https://razorpay.com/docs/payments/third-party-validation/standard-integration/). ### Personal Thoughts There seems to be a need for a solution where, upon completion of a payment, we can retrieve the payment parameters and signature to independently verify the transaction through a third-party service. However, most UPI payment gateways follow NPCI guidelines, and third-party verification of payments raises privacy concerns. This could be why such specific endpoints are not publicly available, and even if they exist, they are likely restricted or private.