Integration Steps
The Android Native OTP Assist SDK integration involves the following steps:
Step 1. SDK Integration
Before you start with the integration, enable the payment methods that you want to offer to your customers from Dashboard > Settings > Payment methods. Cards, UPI, and other payment methods are enabled by default, and PayU recommends you to enable other payment methods that are relevant to you.
Step 1: Create a PayU account
First, create a PayU account. For more information, refer to Register for a Merchant Account.
Step 2: Include the SDK in your application
Include the SDK in your application’s build.gradle:
implementation 'in.payu:native-otp-assist:1.6.2'
Step 3: Set up payment hash and post data
Generate payment hash
For more information on the generation of Payment Hash, refer to Generate Static Hash.
RememberEvery transaction (payment or non-payment) needs a hash set up by you before sending the transaction details to PayU. Hash is required for PayU to validate the authenticity of the transaction. This hashing should be done on your server.
Payment post data
Use the Core SDK library to generate payment post data.
Step 4: Initiate payment
Initialize Native OTP SDK
Initialize the Native OTP Assist SDK by providing the PayUOtpAssistConfig object having post data and reference to PayUOtpAssistCallback to listen to the SDK events similar to the following code block:
PayUOtpAssistConfig payUOtpAssistConfig = PayUOtpAssistConfig();
payUOtpAssistConfig.setPostData("POST_DATA_FOR_TRANSACTION");
PayUOtpAssist.open(
Context context,
PayUOtpAssistCallback payUOtpAssistCallback,
PayUOtpAssistConfig payUOtpAssistConfig);
val payUOtpAssistConfig = PayUOtpAssistConfig()
payUOtpAssistConfig.postData = "POST_DATA_FOR_TRANSACTION"
PayUOtpAssist.open(
context: Context,
payUOtpAssistCallback: PayUOtpAssistCallback,
payUOtpAssistConfig: PayUOtpAssistConfig
)
Remember: This SDK will work only if the customer or the user provides consent for the app to read the SMS on their device.
PayU fetches the OTP through RECEIVE_SMS if the RECEIVE_SMS permission is granted. Otherwise, fetch the OTP using the Google Consent API. To understand the flow, refer to PayU OTP Parser.
Callbacks
The following is a list of callback functions provided by PayUOtpAssistCallback class:
fun onPaymentSuccess(merchantResponse: String?, payUResponse: String?)
: Called when payment succeeds. merchantResponse:fun onPaymentFailure(merchantResponse: String?, payUResponse: String?)
: Called when a payment fails.fun onError(errorCode: String?, errorMessage: String?)
: Called when we got some error, where:errorCode
: Error CodeerrorMessage
: Error Description
fun shouldHandleFallback(payUAcsRequest: PayUAcsRequest)
: Boolean – It’s an optional callback, override when you want to handle the Bank page redirection flow. You just need to change the return value to false. You can also open CustomBrowser in fallback scenarios. The following code snippet is to launch the CustomBrowser.
boolean shouldHandleFallback(PayUAcsRequest payUAcsRequest) {
CustomBrowserConfig customBrowserConfig = new CustomBrowserConfig(merchantKey, txnId);
//Set the issuerUrl and issuerPostData to open in WebView for otp assist redirection to bank page
if (payUAcsRequest.getIssuerUrl() != null && payUAcsRequest.getIssuerPostData() != null) {
customBrowserConfig.setPostURL(payUAcsRequest.getIssuerUrl());
customBrowserConfig.setPayuPostData(payUAcsRequest.getIssuerPostData());
} else if (payUAcsRequest.getAcsTemplate() != null) {
customBrowserConfig.setHtmlData(payUAcsRequest.getAcsTemplate());
} else {
//Set the first url to open in WebView
customBrowserConfig.setPostURL(url);
customBrowserConfig.setPayuPostData(payuConfig.getData);
}
return false;
}
fun shouldHandleFallback(payUAcsRequest: PayUAcsRequest): Boolean {
val customBrowserConfig = CustomBrowserConfig(merchantKey, txnId)
//Set the issuerUrl and issuerPostData to open in WebView for otp assist redirection to bank page
if (!payUAcsRequest?.issuerUrl.isNullOrEmpty() && !payUAcsRequest?.issuerPostData.isNullOrEmpty()) {
customBrowserConfig.postURL = payUAcsRequest?.issuerUrl
customBrowserConfig.payuPostData = payUAcsRequest?.issuerPostData
} else if (!payUAcsRequest?.acsTemplate.isNullOrEmpty()) {
customBrowserConfig.htmlData = payUAcsRequest?.acsTemplate
} else {
//Set the first url to open in WebView
customBrowserConfig.postURL = url
customBrowserConfig.payuPostData = payuConfig.data
}
return false
}
You will get PayUAcsRequest on shouldHandleFallback()
callback. Whether you will get issuerUrl
and issuerPostData
or acsTemplate on PayUAcsRequest.acsTemplate
is the HTML string that you need to load to the Web view.
PayUAcsRequest field | Description |
---|---|
issuerUrl | It’s the Bank/ACS page Url. |
issuerPostData | You need to load issuerUrl to the Webview along with this issuerPostdata string. Ex: webView.postUrl(issuerUrl, issuerPostData.toByteArray()) |
acsTemplate | If the issuerUrl is empty, you need to load acsTemplate to the Webview. Ex: webView.loadData(acsTemplate, “text/html”, “UTF-8”); |
The following table lists error codes and their description:
Error Code | Description |
---|---|
1001 | |
1002 | Network timeout, please verify with your server. |
1003 | Gateway timeout, please verify with your server. |
1004 | User canceled it, please verify with your server. |
1005 | Something went wrong, please verify with your server. |
1006 | The bank page timed out, please verify with your server. |
Remember: After you get the response from SDK, make sure to confirm it with the PayU server. It is recommended to implement the PayU Webhook or backend verify call from your backend.
Step 5: Verify the transaction using webhook
After you get the response from SDK, make sure to confirm it with the PayU server.
Note: It is recommended to implement the PayU Webhook or backend verifies calls from your backend.
Webhook is a server-to-server callback. Once this feature is activated for merchants, PayU would send an S2S response, in addition to an SDK callback, to the merchant. It is recommended for the merchant process the transaction order status – based on the S2S response and not via the Browser Redirection/SDK callback response to ensure optimum translation outcomes. For more information on the Webhook implementation, refer to Web Checkout Integration Documentation > Webhooks,
Also, you can verify payment through polling, the transaction status after the SDK callback from your backend. For more information, refer to Verify Payment API.
Step 2. Test the Integration and Go-Live
Test the Integration
After the integration is complete, you must test the integration before you go live and start collecting payment. You can start accepting actual payments from your customers once the test is successful.
You can make test payments using one of the payment methods configured at the Checkout.
Testing checklistThings to remember while testing an integration:
- To test the integration make sure that you are making a transaction call to the test endpoint.
- Use your test key and salt for the transaction requests. For more information, refer to Access Test Key and Salt.
- Set the value of the
environment
parameters to1
.
Test cards only for Test environmentThese test cards, UPI, and Wallet credentials must only be used in the sandbox environment. Using these test cards in production environment may cause validation error.
Test credentials for supported payment methods
Following are the payment methods supported in PayU Test mode.
Test credentials for Net Banking
Use the following credentials to test the Net Banking integration:
- user name: payu
- password: payu
- OTP: 123456
Test VPA for UPI
You can use either of the following VPAs to test your UPI-related integration:
CalloutThe UPI in-app and UPI intent flow is not available in the Test mode.
Test cards for EMI
You can use the following Debit and Credit cards to test Emi integration.
Kotak DC EMI |
|
AXIS DC EMI |
|
HDFC CC EMI |
|
ICICI CC EMI |
|
Test wallets
You can use the following wallets and their corresponding credentials to test wallet integration.
Wallet | Mobile Number | OTP |
---|---|---|
PayTM | 7777777777 | 888888 |
PhonePe | Use the Phonepe Pre-Prod app for testing purposes as described in the following PhonePe doc. location: https://developer.phonepe.com/v1/docs/setting-up-test-account Download the app and register your mobile number and follow the instructions as described in the above PhonePe docs. | NA |
AmazonPay | You can test using your original Amazon account details. |
Go-live Checklist
Ensure these steps before you deploy the integration in a live environment.
Collect Live Payments
After testing the integration end-to-end, once you are confident that the integration is working as expected, you can switch to live mode to start accepting payments from your customers.
Watch Out!Ensure that you are using the production merchant key and salt generated in the live mode.
Checklist 2: Configure environment() parameter
Set the value of the environment()
to 0
in the payment integration code. This enables the integration to accept live payments.
Checklist 4:- Remove/comment meta -data code from manifest file :-
For Android
You must be comment/remove the below metadata code from the manifest file to use the UPI Collect flow on Production env:-
<application>
<meta-data android:name="payu_debug_mode_enabled" android:value="true" /> // set the value to false for production environment
<meta-data android:name="payu_web_service_url" android:value="https://test.payu.in" /> //Comment in case of Production-->
<meta-data android:name="payu_post_url" android:value="https://test.payu.in"/> //Comment in case of Production-->
</appliction>
Checklist 5: Configure verify payment method
Configure the Verify payment method to fetch the payment status. We strongly recommend that you use this as a back up method to handle scenarios where the payment callback is failed due to technical error.
Checklist 6: Configure Webhook
We recommend that you configure Webhook to receive payment responses on your server. For more information, refer to Webhooks.
Updated about 2 hours ago