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.

SpecificationsDetails
Minimum PaymentsOS API Version1.2.0
Requests
  • Charge
  • Refund (including multiple/partial)
CurrenciesUSD, EUR, JPY, GBP, CHF, SEK, DKK, NOK, SGD, AUD, CAD, AED, HKD, QAR, SAR, OMR, ZAR, MYR, KWD, MUR, LKR, KES, PHP, NZD, THB, BDT, CNY, NPR, BHD, INR
Payment Methods
  • AMEX
  • DINERS
  • JCB
  • MAESTRO
  • MASTERCARD
  • RUPAY
  • VISA
3DS RedirectionSupported

Configurations

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

ConfigurationRequired/Optional
In the PaymentsOS Control Center, configure the following credentials:
  • Live credentials: In your PayU India account, , enter the merchantKey and salt keys you received from PayU India. You can also login to your PayU India merchant dashboard and grab the credentials from My Account -> System Settings..
  • Test credentials: Contact PayU India support to request test credentials.
Required
In your PayU India account, enable the Standing Instructions payment method. Contact PayU India support for assistance.Optional
In your PayU India account, enable payment methods. Contact PayU India support for assistance.Optional

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.

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.

Note

The response of the Create Charge request will also include a redirection object with a url attribute. This enables you to direct your customers to an external authentication page, as an alternative authentication option for customers who do not want to enter an SMS authentication code on your web page. The url is always returned by the Create Charge request, also if you set "zeroRedirect":"1".

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:

Card number Expiration date CVV Card Type
4854 4601 9876 5435 May 20 2020 123 Debit/Credit Card

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

Code Simulates
123456 Success
000000 Failure

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.

results matching ""

    No results matching ""