Post Request (Non-seamless)
Below parameters needs to be posted by Merchant to PayU in Transaction Request
key (Mandatory) :
This parameter is the unique Merchant Key provided by PayU for your merchant account. The Merchant Key acts as the unique identifier (primary key) to identify a particular Merchant Account in our database. While posting the data to us, you need to put this Merchant Key value for you merchant account in this parameter.
txnid (Mandatory):
This parameter is known as Transaction ID (or Order ID). It is the order reference number generated at your (Merchant's) end. It is an identifier which you (merchant) would use to track a particular order. If a transaction using a particular transaction ID has already been successful at PayU, the usage of same Transaction ID again would fail. Hence, it is essential that you post us a unique transaction ID for every new transaction. Data Type -- Varchar Character Limit -- 25 characters Example: fd3e847h2
amount (Mandatory):
This parameter should contain the payment amount of the particular transaction. Note: Please type-cast the amount to float type Example: 10.00
productinfo (Mandatory):
This parameter should contain a brief product description. It should be a string describing the product (The description type is entirely your choice). Data type - Varchar Character Limit -- 100 characters Example: tshirt100
firstname (Mandatory):
Self-Explanatory (Must contain the first name of the customer) Data Type -- Varchar Character Limit -- 60 characters Example: Ankit
email (Mandatory):
Self-explanatory (Must contain the email of the customer) Data type -- Varchar Character Limit -- 50 Example: test@gmail.com
phone (Mandatory):
Self-explanatory (Must contain the phone number of the customer) Data type -- Varchar Character Limit -- 50 (numeric value only) Example: 9999999999
lastname:
Self-Explanatory (only alphabets a-z are allowed) Data Type -- Varchar Character Limit -- 20 characters Example: Verma
address1:
Self-Explanatory Data Type -- Varchar Character Limit -- 100 Characters allowed : A to Z, a to z, 0 to 9, @, - (Minus), _ (Underscore), / (Backslash), (Space), (Dot)
address2:
Self-explanatory Data Type -- Varchar Character Limit -- 100 (Allowed characters are same as for address1 parameter)
city:
Self-explanatory Data type -- Varchar Character Limit -- 50 (Allowed characters are same as for address1 parameter)
state:
Self-explanatory Data type -- Varchar Character Limit -- 50 (Allowed characters are same as in address parameter)
country:
Self-explanatory Data type -- Varchar Character Limit -- 50 (Allowed characters are same as in address parameter)
zipcode:
This parameter would contain the same value of zipcode which was sent in the transaction request from merchant’s end to PayU
udf1:
User defined field 1 – This parameter has been made for you to keep any information corresponding to the transaction, which may be useful for you to keep in the database. UDF1-UDF5 fields are for this purpose only. It’s completely for your usage and you can post any string value in this parameter. udf1-udf5 are optional parameters and you may use them only if needed Data type – Varchar Character Limit – 255
udf2:
User defined field 2 – Same description as UDF1 Data type – Varchar Character Limit – 255
udf3:
User defined field 3 – Same description as UDF1 Data type – Varchar Character Limit – 255
udf4:
User defined field 4 – Same description as UDF1 Data type – Varchar Character Limit – 255
udf5:
User defined field 5 – Same description as UDF1 Data type – Varchar Character Limit – 255
surl(Mandatory):
Success URL - This parameter must contain the URL on which PayU will redirect the final response if the transaction is successful. The response handling can then be done by you after redirection to this URL
furl(Mandatory):
Failure URL - This parameter must contain the URL on which PayU will redirect the final response if the transaction is failed. The response handling can then be done by you after redirection to this URL
curl:
Cancel URL - This parameter should contain the URL on which PayU will redirect the response if the transaction is cancelled by the customer on PayU page. The response handling can then be done by you after redirection to this URL
hash (Checksum) (Mandatory):
Hash is a crucial parameter – used specifically to avoid any tampering during the transaction. There are two different methods to calculate hash. Please follow method 1 only. Method 2 is just there for the documentation and is not to be used.
pg:
This parameter signifies the payment category (tab) that you want the customer to see by default on the PayU page. Hence if PG=’NB’, then after redirection to PayU’s payment page, the Net Banking option would be opened by default. (PG parameter may take different values like : NB for Net Banking tab, CC for Credit Card tab, DC for Debit Card tab, CASH for Cash Card tab and EMI for EMI tab) Note: PG = CC, i.e. Credit Card tab is recommended. If PG is left empty, CC will be taken as default.
codurl:
Cash on delivery URL – This parameter is used when a transaction attempt fails. In this case, if retries have been enabled for you (done by PayU for your merchant account), our PayU page is shown (to provide another attempt to customer to complete the transaction) with the ‘failed transaction message’ to the customer and also ‘Pay by COD’ option. To handle this ‘Pay by COD’ option, you can fill the COD URL parameter with a URL which we will redirect to, when the customer selects this option. This way, you can then provide the customer another attempt at the transaction through this URL.
drop_category:
This parameter is used to customize the payment options for each individual transaction. For example, if we consider the categories Credit Card, Debit Card and Net Banking for a merchant. If there are 30 net banking options available and the merchant wants to drop 2 of those net banking options (i.e. do not display those 2 options on PayU page), then drop_category parameter can be used effectively. Below table denotes example of category and sub-categories at PayU Click here for more details an example.
enforce_paymethod:
This parameter allows you to customize the payment options for each individual transaction. For example, if we consider the categories Credit Card, Debit Card and Net Banking. If the merchant wants to display only 4 debit card options and only 2 Net Banking options for a transaction A and wants to display only 2 debit card option and 5 Net Banking options for another transaction B, the customization is needed and this parameter (enforce_paymethod) provides exactly that feature. Click here for more details an example.
custom_note:
This parameter is useful when you want to display a message string on the PayU Payment page. For example, if for a particular product X, you want your customer to know that an extra amount of Rs 100 would be charged afterwards, you can show the corresponding message on payment page. For this, you need to post that message in this parameter – custom_note. The note would be displayed just below the payment tabs (Credit Card/Debit Cards/Net Banking)
note_category:
This parameter gives you an option of showing the message string passed in customnote parameter for only the selected Payment categories. Hence, this parameter should contain the comma separated list of the payment options for PayU Integration Document - Version 2.5 Page 15 which the customnote will appear. For example: notecategory = CC,NB will show the customnote for Credit Card & Net banking only
api_version:
Please don’t use this parameter while posting the data
shipping_firstname:
This parameter has to used in case of COD (Cash on Delivery) Only Self-Explanatory (Constraints same as firstname parameter). If this parameter is posted, the corresponding value would be filled up automatically in the form under COD tab on PayU payment page
shipping_lastname:
This parameter has to used in case of COD (Cash on Delivery) Only Self-Explanatory (Constraints same as lastname parameter). If this parameter is posted, the corresponding value would be filled up automatically in the form under COD tab on PayU payment page
shipping_address1:
This parameter has to used in case of COD (Cash on Delivery) Only Self-Explanatory (Constraints same as address1 parameter). If this parameter is posted, the corresponding value would be filled up automatically in the form under COD tab on PayU payment page
shipping_address2:
This parameter has to used in case of COD (Cash on Delivery) Only Self-Explanatory (Constraints same as address2 parameter). If this parameter is posted, the corresponding value would be filled up automatically in the form under COD tab on PayU payment page
shipping_city:
This parameter has to used in case of COD (Cash on Delivery) Only Self-Explanatory (Constraints same as city parameter). If this parameter is posted, the corresponding value would be filled up automatically in the form under COD tab on PayU payment page
shipping_state:
This parameter has to used in case of COD (Cash on Delivery) Only Self-Explanatory (Constraints same as state parameter). If this parameter is posted, the corresponding value would be filled up automatically in the form under COD tab on PayU payment page
shipping_country:
This parameter has to used in case of COD (Cash on Delivery) Only Self-Explanatory (constraints same as country parameter). If this parameter is posted, the corresponding value would be filled up automatically in the form under COD tab on PayU payment page
shipping_zipcode:
This parameter has to used in case of COD (Cash on Delivery) Only Self-Explanatory (constraints same as zipcode parameter). If this parameter is posted, the corresponding value would be filled up automatically in the form under COD tab on PayU payment page PayU Integration Document - Version 2.5 Page 16
shipping_phone:
This parameter has to used in case of COD (Cash on Delivery) Only Self-Explanatory (constraints same as phone parameter). If this parameter is posted, the corresponding value would be filled up automatically in the form under COD tab on PayU payment page
offer_key:
This parameter is useful when the merchant wants to give the customer a discount offer on certain transactions based upon a pre-defined combination. This combination can be based upon payment options/bins etc. For each new offer created, a unique offerkey is generated. At the time of a transaction, this offerkey needs to be posted by the merchant.