Integration test overview (RPP)
Test credentials for PayU staging environment can be found on the test credential page.
- Staging test cases
The staging environment is typically used to develop to the customer's payment sequence. This environment is also not linked to any bank and all transactions will be marked as test transactions. The recommended test cases for your staging environment integration phase are below:
- Successful transaction
Once a customer has been redirected from the merchant's website to the PayU Payment Page, the customer will use the test credit cards details to simulate a successful test payment. The customer's browser will be redirected back to the merchant website from where a getTransaction API call will be issued. This API call response should reflect the successful payment state of the transaction.
- Cancelled transaction
Once a customer has been redirected from the merchant's website to the PayU Payment Page, then a cancelled transaction can be simulated when the customer clicks on the cancel link on the PayU interface. The customer's browser will be redirected back to the merchant website from where a getTransaction API call will be issued. This API call response should reflect the cancelled state of the transaction.
- Failed transaction
PayU transactions can have a maximum amount of up to 5 Million Rand. To simulated an error or failed response use amounts larger than this amount as the transaction amount for payment. A user will create a shopping basket greater than 5 Million Rand and wanting to pay get redirected to the merchant's website to the PayU Payment Page. The customer will use one of the test credit cards to pay on the payment page. The customer's browser will be redirected back to the merchant website after payment from where a getTransaction API call will be issued. This API call response should reflect the failed state of the transaction. - Production test cases
Once you have completed a successful staging testing you can request your production detail from PayU which will replace the staging details.Once the production details are entered, it is recommended to do a couple of transactions with a real credit card. These transaction should be reflected in the transaction report within PayU's SafeShop.These transaction amounts can be refunded using PayU's SafeShop, but unfortunately the transaction fees not. Test recommendations
- Put merchant order in a 'pending payment' state before redirect to PayU
After doing a setTransaction and prior to redirecting a customer's browsers browser to PayU it is a good idea to put the order in a 'pending payment' status on the merchant side. By knowing which transactions on the merchant's website went to PayU for payment and was never successful or declined, the merchant can issue a getTransaction call against those orders and see what the outcome of the customers payment were on PayU and then update the order's status accordingly..
- Unable to issue a successful getTransaction call after doing a redirect from PayU
Once a customer pays on PayU and it gets redirected to the merchant's website a getTransaction should be issued to finfd out the result of the payment.When building this it is best to make provision if this call can't be successfully executed. By implementing the 'pending payment' order state (as specified in 4.5.1) a merchant should be able to request the result of those payment using the getTransaction call afterwards.
- Customer closes browser after payment
Once a customer pays on PayU and the customer in error might close the browser window after payment while still on PayU site but before getting redirected back to the merchant site.It is best to make provision for this scenario by implementing the 'pending payment' order state (as specified in 4.5.1) a merchant should be able to request the result of those payment using the getTransaction call afterwards.