**What is Dynamic QR? **Dynamic QR solution enables our partners to generate unique QR codes for each payment request. This QR code then can be scanned by the customer in order to complete the transaction. For scanning and paying, the customer can use any app.

**Can we scan the Dynamic QR twice? ** If payment has been initiated by the customer then this QR code can not be scanned again even if the transaction was unsuccessful during the first attempt. So, the cashier needs to generate a new QR code and has to ask the customer to try again. Also, the customer needs to respond within the time limit passed in the expiresIn parameter.

**What is the difference between Dynamic QR and Static QR? **

Dynamic QRStatic QR
A unique QR code is generated for every transactionSame QR code is scanned by customers for different transactions
On scanning, the amount is pre-populated on the screen and the customer only needs to complete the transactionAfter scanning, the customer needs to enter the amount and then he needs to complete the transaction
Bill closure can be done via API callsBill closure is done manually by cashiers

**What is the transactionId parameter? **A unique value is passed in this parameter in order to track the transaction at the later stages. Values should be alpha-numeric and without any spaces and should contain less than 38 characters. If a value is passed which is already stored in the PhonePe server then the server will give you a 417-expectation error response code (INVALID_TRANSACTION_ID, msg: duplicate transaction id).

**What is Check Payment Status API? **It is used to get the current state of any transaction with the help of transactionId

**Do we need to use Check Payment Status API to get the status of the transaction if we have already passed x-callback-URL to get the callback from the PhonePe server? **Yes. It is used as a fallback option and it gives the current status of the transaction even if it is in a non-final state (ex. PAYMENT_PENDING).

**What is the difference between PAYMENT_ERROR and INTERNAL_SERVER_ERROR? ****PAYMENT_ERROR** - It is the final state of the transaction. It simply means that payment is failed and the cashier can initiate a new transaction and ask the customer to try again. No waiting period to mark the transaction as failed **INTERNAL_SERVER_ERROR ** It is a non-final state of the transaction. In this scenario, the cashier needs to wait until he gets any final state of the transaction (i.e. PAYMENT_SUCCESS or PAYMENT_ERROR). The Cashier can use Check-Payment-Status API in order to get the current status.

**What is the use of X-Provider ID and who will generate it? ** If you are a POS provider or Technical Service Provider or an aggregator, you can call APIs without using SAT Keys and Index of individual Merchant IDs, you can use the SALT Key and Index of the X-Provider ID. All the Merchant IDs will be mapped to the X-Provider-ID. X-Provider-ID will be provided by PhonePe at the time of onboarding

**Can my customer pay via any other UPI app using the collect flow?** Yes, customer can pay via any UPI app