PayU India

PayU India has some special integration requirements. Follow the standard PaymentsOS integration procedure, and then apply the relevant extra specifications described below.

Specifications for Card-based Transactions

The following table lists the integration specifications for PayU India.

Configurations

The following table lists the configurations that are specific to PayU India.

Sample Requests

Use the bodybuilder to create a sample request body for each request type.

Implementing a Recurring Transaction Flow

A recurring transaction flow allows you to charge your customers a specific amount for goods or services, on a pre-arranged, recurring schedule. Examples include regular payments such as vehicle insurance, janitorial services, and subscriptions or dues.

In a recurring transaction flow, a customer's card information is saved, so that it can be reused for each transaction. Customers must provide their consent to having their card information stored and authenticate themselves only once, when initiating their first transaction (no authentication is required for subsequent transactions).

Step 1: Save a Customer's Card Information

Start by implementing logic for saving a reusing a customer's card information with PaymentsOS, as explained in Saving the Token.

Step 2: Create a Consent Transaction (Initial Charge Request)

The very first Create Charge request is also known as a Consent Transaction. When initiating this transaction, customers agree to having their card information stored and authenticate themselves either by entering an SMS authentication code that was sent to them, or through an authentication page.

To trigger an SMS-based (zero-redirect) authentication step, pass in "zeroRedirect":"1" in the provider_specific_data object. Simply omit this parameter to redirect a customer to an authentication page instead. Also pass in "si":"1" in the provider_specific_data object to issue a Standing Instruction (SI), which instructs PayU India to setup a recurring transaction flow.

Here's an example of the attributes you need to pass in the first Create Charge request to trigger a recurring, SMS-based (zero-redirect), transaction flow:

{
  "provider_specific_data": {
    "payu_india": {
      "additional_details": {
        "si": "1",
        "zeroRedirect": "1" // Omit to redirect customers to an authentication page
      }
    }
  }
}

If you initiated an SMS-based (zero-redirect) authentication request, then you will need to send us the SMS code entered by the customer in order to proceed with the transaction flow. See Handling Zero-redirect Authentication Responses.

For a flow in which you redirect customers to an authentication page (which is triggered if you did not initiate an SMS-based authentication request), implement the flow as explained in Redirecting Customers to an Authentication Page.

Step 3: Implement the Recurring Transactions (Subsequent Charge Requests)

On subsequent Create Charge requests, pass in "recurring":"1" in the provider_specific_data object. You do not need to pass in any of the attributes sent in the initial Consent Transaction.

{
  "provider_specific_data": {
    "payu_india": {
      "additional_details": {
        "recurring": "1"
      }
    }
  }
}

Implementing a Non-recurring Transaction Flow

Non-recurring flows are used for single, one-time, transactions. Customers must authenticate themselves per transaction, either through an authentication page or by entering an SMS authentication code.

To redirect customers to an authentication page, simply omit the provider_specific_data object when invoking a Create Charge request. Make sure to setup the redirection flow, as explained in Redirecting Customers to an Authentication Page.

For SMS-based (zero-redirect) authentication, pass in "zeroRedirect":"1" in the provider_specific_data object when invoking a Create Charge request.

{
  "provider_specific_data": {
    "payu_india": {
      "additional_details": {
        "zeroRedirect": "1" // Omit to redirect customers to an authentication page
      }
    }
  }
}

If you initiated an SMS-based (zero-redirect) authentication request, then you will need to send us the SMS code entered by the customer in order to proceed with the transaction flow. See Handling Zero-redirect Authentication Responses.

Handling Zero-redirect Authentication Responses

If you initiated an SMS-based (zero-redirect) authentication request, then the response of the Create Charge request will include an sms_submission_url, sms_resend_url and sms_cancel_url URL:

{
  "provider_data": {
    "provider_name": "payu_india",
    "raw_response": "raVVKdDcrcWMrOHJKdVRDN2xpZnRpL0cycUt0QU5",
    "external_id": "403993715517799596",
    "additional_information": {
      "transaction_status": "sms_confirmation_pending",
      "sms_submission_url": "https://api.paymentsos.com/payments/0269f212-bd23-48ae-a944-be9a8e926ada/charges/3716e0a3-1139-441c-af16-bebbb19ca0f7/callbacks?q=NmNiMDU4YTMtMTgxMy00N2UzLTlhYmEtNjAzOTBmODNiNzk2Y3Z2X2RlbGltaXRlcnZhdWx0OnYx2jR2R1FWeUMrbnNPdTZ6dG1KWEpCRmgweHMyZml0czFxSm5KRTlxWUJWMlot",
      "sms_resend_url": "https://api.paymentsos.com/payments/0269f212-bd23-48ae-a944-be9a8e926ada/charges/3716e0a3-1139-441c-af16-bebbb19ca0f7/callbacks?q=NmNiMDU4YTMtMTgxMy00N2UzLTlhYmEtNjAzOTBmODNiNzk2Y3Z2X2RlbGltaXRlcnZhdWx0OnYx2jR2R1FWeUMrbnNPdTZ6dG1KWEpCRmgweHMyZml0czFxSm5KRTlxWUJWMlot",
      "sms_cancel_url": "https://api.paymentsos.com/payments/0269f212-bd23-48ae-a944-be9a8e926ada/charges/3716e0a3-1139-441c-af16-bebbb19ca0f7/callbacks?q=NmNiMDU4YTMtMTgxMy00N2UzLTlhYmEtNjAzOTBmODNiNzk2Y3Z2X2RlbGltaXRlcnZhdWx0OnYx2jR2R1FWeUMrbnNPdTZ6dG1KWEpCRmgweHMyZml0czFxSm5KRTlxWUJWMlot"
    }
  }
}

Invoke a POST request to the sms_submission_url to send us the SMS code entered by the customer. In the request body, pass in the sms_confirmation_code:

{
  "sms_confirmation_code": "123456"
}

Invoke a POST request with an empty body to the sms_resend_url URL to resend an SMS code to the customer, if sending the SMS code to the sms_submission_url URL failed. To invalidate the SMS code sent to the customer, invoke a POST request with an empty body to the sms_cancel_url.

SMS (Zero-redirect) POST Request Responses

When creating a successful POST request to the sms_submission_url or sms_cancel_url, the response body will always be empty.

A request sent successfully to the sms_resend_url URL will return the number of resend attempts left:

{
    "resendOtpAttemptLeft":"1"
}

If any of the POST requests failed, then PaymentsOS returns an error object with more information about the error that occurred.

Redirecting Customers to an Authentication Page

Both a recurring and non-recurring payment flow require that customers authenticate themselves. In a recurring flow, this is required only once (during the first transaction); in a non-recurring flow this is required for each transaction.

If you require customers to authenticate themselves on an external authentication page, then implement a redirection flow to redirect customers to that page.

Testing

You can use the following PayU India test card for testing:

To test both an SMS-based (zero-redirect) authentication request and an authentication step through an external authentication page, use the following codes:

For an SMS-based (zero-redirect) authentication request, pass one of the test codes when invoking the POST request to the sms_submission_url to which you send the SMS code.

To test an authentication step when using an external authentication page, grab the redirect URL from the Charge Request response body. This URL will redirect you to an authentication page created for testing purposes by PayU India, in which you can enter one of the test codes. Bear in mind that you will only be redirected to the test authentication page when initiating a test using test credentials.