PayU India

Follow the standard PaymentsOS integration procedure, and then apply the relevant extra specifications described below.

• API Version
• Payment Methods
• Currencies
• Features
• Requests
• Setup Procedures
• Integration Procedures
• Testing

API Version

Minimum required API version: 1.2.0

Payment Methods

The following table lists all supported payment methods.

Currencies

AED,AUD,CAD,EUR,GBP,HKD,INR,OMR,QAR,SGD,USD

Features

The following table provides an overview of all supported and non-supported features.

Feature	Supported
3DS 1.0 External	No
3DS 1.0 Internal	Yes
3DS 2.0 External	No
3DS 2.0 Internal	No
Installments	Yes
Level 2 and 3 Data	No
Retrieve Supported Payment Methods	Yes
Retrieve Supported Plans	Yes
Statement Soft Descriptor	No
Stored Credentials Flag	No
Transaction Processing without CVV	No

Requests

The following table lists all supported requests for card-based transactions. Use the bodybuilder to create a sample request body for each request type.

Setup Procedures

The following table lists the setup procedures that are specific to this provider.

Integration Procedures

The following sections list the integration procedures that are specific to this provider.

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.

Implementing a Payment Flow with Installments

If you allow your customers to pay with installments, simply pass an installments object in the Create Charge request and include all required installment information.

{
  ...
  "installments": {
      "number_of_installments": 3
  },
  ...
}

Showing Customers Available Installment Options during Checkout

If you configured different installment plans in your PayU India account, then you can fetch those plans and display the various installment options in your checkout page when a customer initiates the payment. To do so, call the Retrieve Supported Plans request. Make sure to pass the transaction amount and currency for which to fetch the available plans as query parameters.

The response of the Retrieve Supported Plans request will include for each plan, a place code representing the number of allowed installments for the specific plan. You should pass this code in the provider_specific_data.payu_india.additional_details.code field in the request body of the Create Charge request , like so:

...
"provider_specific_data": {
    "payu_india": {
      "additional_details": {
        "code": "EMIA12",
        ...
      }
    }
  }
...

Also make sure that the value you pass for installments.number_of_installments matches the number of installments allowed by the plan selected by the customer. For example, a plan code of EMIA12 (as in the example above) indicates that 12 installments are allowed, so you should pass installments.number_of_installments accordingly:

{
  ...
  "installments": {
      "number_of_installments": 12
  },
  ...
}

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.