Server Side

Server Side

Generate Hash

• What is Hash?
  Every transaction (payment or non-payment) needs a hash by the merchant before sending the transaction details to PayU. This is required for PayU to validate the authenticity of the transaction. This should be done on your server.

• Generating Hash

• Payment Hash

     sha512(key|txnid|amount|productinfo|firstname|email|udf1|udf2|udf3|udf4|udf5||||||salt)
  

• Webservice Hash - sample

     sha512(key|command|var1|salt) 
  

Note: Please refer the web integration document for more details

• Some pre-programmed scripts to generate hash.
  • JAVA Hash Generation Code
  • PHP Hash Generation Code

Return Url - (SURL / FURL)

• Return URL is where PayU redirects the user after the transaction is completed. PayU sends the data related to transactions while redirecting so that you can check the status of the transaction.

• How to create surl/furl page?
  The surl/furl page is hosted on your server to communicate back to client application when the transaction is completed. You may check the status of the transaction and take actions accordingly. Inside mobile applications, it is important that the user is redirected back to app whenever a transaction is completed. After the transaction is complete, Payu posts the response to the surl / furl.

• Sample code (For Android):

• JAVA(.jsp)

• PHP

• Sample code (For iOS):

• PHP (FURL)

• PHP (SURL)

• Some links for reference (Notice the difference in scripts for Android and iOS)

• android surl and furl
  https://payu.herokuapp.com/success
  https://payu.herokuapp.com/failure

• iOS surl and furl
  https://payu.herokuapp.com/ios_success
  https://payu.herokuapp.com/ios_failure

Response (comes with surl/furl)

Sample success response

Array
(
    [mihpayid] => 316717697
    [mode] => CC
    [status] => success
    [unmappedstatus] => captured
    [key] => smsplus
    [txnid] => 74e9a70d171df41f7c6a
    [amount] => 2.00
    [cardCategory] => domestic
    [discount] => 0.00
    [net_amount_debit] => 2
    [addedon] => 2015-04-13 18:10:58
    [productinfo] => Product Info
    [firstname] => Payu-Admin
    [lastname] => 
    [address1] => 
    [address2] => 
    [city] => 
    [state] => 
    [country] => 
    [zipcode] => 
    [email] => [email protected]
    [phone] => 1234567890
    [udf1] => 
    [udf2] => 
    [udf3] => 
    [udf4] => 
    [udf5] => 
    [udf6] => 
    [udf7] => 
    [udf8] => 
    [udf9] => 
    [udf10] => 
    [hash] => 0e92de4a135724da69011f0b39093c20431fe07d1f17f6ca3baa7fdcf4b0e5af333e4fb49a52544e65a110dfa4db2f27cff5d587bdafa67ef3baafc2f8928e46
    [field1] => 510370167829
    [field2] => 047751
    [field3] => 4602057101851030
    [field4] => 4602057101851030
    [field5] => 
    [field6] => 
    [field7] => 
    [field8] => 
    [field9] => SUCCESS
    [payment_source] => payu
    [PG_TYPE] => HDFCPG
    [bank_ref_num] => 4602057101851030
    [bankcode] => CC
    [error] => E000
    [error_Message] => No Error
    [name_on_card] => benjamin franklin
    [cardnum] => 438628XXXXXX2452
    [cardhash] => This field is no longer supported in postback params.
}  

Note: The possible error codes and messages Transaction Error Code.pdf

Post-Transaction hash sequence:( Mandatory )

Merchant needs to form the below hash sequence and verify it with the hash sent by PayU in the Post Response(without additional charges):

sha512(SALT|status||||||udf5|udf4|udf3|udf2|udf1|email|firstname|productinfo|amount|txnid|key) 

Merchant needs to form the below hash sequence and verify it with the hash sent by PayU in the Post Response(with additional charges):

sha512(additionalCharges|SALT|status||||||udf5|udf4|udf3|udf2|udf1|email|firstname|productinfo|amount|txnid|key) 

Where, additionalCharges value must be same as the value Posted from PayU to the merchant in the response.

IMPORTANT: This hash value must be compared with the hash value posted by PayU to the merchant. If both match, then only the order should be processed. If they don’t match, then the transaction has been tampered with by the user and hence should not be processed further.

If you do not calculate reverse hash from your end, the transaction can be tampered or hacked.

• Sample code For Reverse Hash Generation (iOS & Android)

• reverseHash.php

payment_related_details_for_mobile_sdk API

This API is used to get all payment option and its URLs are :

Test URL : https://mobiletest.payu.in/merchant/postservice?form=2

Production URL : https://info.payu.in/merchant/postservice.php?form=2

To call any PayU API, you need to generate hash from your server using following pattern :

sha512(key|command|var1|salt)

  key=YOUR KEY
  command=payment_related_details_for_mobile_sdk
  salt= YOUR SALT
  var1= default(if you want stored cards use var1 as user_credentials else default)

for user_credentilas see p53

• To call API, you need to pass following parameters with test/prod URLs :

key=gtKFFx(YOUR KEY)
hash=e43ede14c88c70e27f47001b4207a......(generated using sha512(key|command|var1|salt) from your server)
command=payment_related_details_for_mobile_sdk
var1= default(if you want stored cards use var1 as user_credentials else default)

Note: Please refer the web integration document for more details

Updates In Surl-Furl Implementation.

NOTE : This updation will only work for latest SDK and CB

Surl(success url), Furl(failure url) are two urls (https POST) should be given by merchant as post param while making payment. As soon as the transaction completes payu post the data back to surl/furl depends on the transaction status.

Current implementation

SURL/FURL - should implement a javascript interface function named

PayU.onSuccess(“data”) or PayU.onFailure(“data”); 

example

<html>
<body>
<script>
	var data = “Data to send back to app from surl/furl”;
	PayU.onSuccess(data); // in case of success (surl);
	PayU.onFailure(data); // in case of failure (furl);
</script>
</body>
</html>

As soon as this surl/furl makes interface call to sdk/custombrowesr, you can get the data from

data.getStringExtra("result")

New implementation. (Optional)

SURL / FURL - Javascript interface is no longer mandatory. - lets say if a merchant wants to send custom data to app from surl/furl, then he can make use of the PayU.onSuccess() or PayU.onFailure() function.

After the transaction in app’s onActinvityResult function

For Return data from Surl/furl (if any)

data.getStringExtra("result")

• For PayU’s Default data (recommended way)

    @Override
       protected void onActivityResult(int requestCode, int resultCode, final Intent data) {
       if (requestCode == PayuConstants.PAYU_REQUEST_CODE) {
       if(data != null ) {
  
    String merchantData = data.getStringExtra("result"); // Data received from surl/furl
    String payuData = data.getStringExtra("payu_response"); // Response received from payu
          }
    }
    }