authenticatePayer()
Authentication method for authenticating payer using Rupay that was initiated using initiateAuthentication
call.
This method will call AUTHENTICATE_PAYER REST API and returns the raw response
in data.restApiResponse
field.
Usage Copied to clipboard
Rupay.authenticatePayer(orderId, transactionId, callback, optionalParams)
Example Copied to clipboard
var optionalParams = { fullScreenRedirect: true, billing: { address: { city: "London", country: "GBR" } } }; Rupay.authenticatePayer("5678", "ABC", function (data) { if (!data.error) { //data.response will contain all the response payload from the AUTHENTICATE_PAYER call. console.log("REST API response ", data.restApiResponse); console.log("HTML redirect code ", data.htmlRedirectCode); } }, optionalParams);
Arguments Copied to clipboard
Order Id of the transaction.
Transaction Id of the transaction.
The callback function.
Any additional REST API `request` params
Indicates whether or not the user wants to automatically get redirected using htmlRedirectCode
property provided by callback.
fullScreenRedirect
is set to 'false', content of htmlRedirectCode
received from
callback needs to be manually inserted into an empty <DIV> element, this being the last element in the
<BODY> of your payment page.
If fullScreenRedirect
is set to 'true' it will be handled automatically.
Details of the payer's billing address.
The payer's billing address.
This data may be used to qualify for better interchange rates on corporate purchase card transactions.
The city portion of the address.
The name of the company associated with this address.
The 3 letter ISO standard alpha country code of the address.
The post code or zip code of the address.
The state or province of the address.
The first line of the address.
For example, this may be the street name and number, or the Post Office Box details.
The second line of the address (if provided).
A transient identifier for the request, that can be used to match the response to the request.
The value provided is not validated, does not persist in the gateway, and is returned as provided in the response to the request.
Information about the device used by the payer for this transaction.
The User-Agent header of the browser the customer used to place the order. For example, MOZILLA/4.0 (COMPATIBLE; MSIE 5.0; WINDOWS 95)
You must provide a value in this field if you are performing 3-D Secure authentication of the payer and set authentication.channel = PAYER_BROWSER.
Detailed information about the payer's browser.
If you are using 3-D Secure authentication to authenticate the payer, then this information is used by the issuer's Access Control Server (ACS) to identify the capabilities of the payers browser so that it can render content appropriately when authenticating the payer.
You must provide values for fields in this parameter group if you are performing 3-D Secure authentication of the payer and set authentication.channel = PAYER_BROWSER.
The content of the Accept request-header field as sent from the payer's browser.
This is used to determine which content types are supported by the browser.
The bit depth (in bits per pixel) of the color palette for displaying images.
You obtain this value from the screen.colorDepth property of the payer's browser.
Indicates whether or not the payer's browser supports Java.
You obtain this value from the navigator.javaEnabled property of the payer's browser.
The language supported for the payer's browser as defined in IETF BCP47.
You obtain this value from the navigator.language property of the payer's browser.
The total height of the payer's browser screen in pixels.
You obtain this value from the screen.height property of the payer's browser.
The total width of the payer's browser screen in pixels.
You obtain this value from the screen.width property of the payer's browser.
Time difference between UTC time and the Cardholder browser local time, in minutes.
The time zone offset is the difference, in minutes, between UTC and local time. Note that this means that the offset is positive if the local time zone is behind UTC and negative if it is ahead. For example, for time zone UTC+10:00 (Australian Eastern Standard Time, Vladivostok Time, Chamorro Standard Time), -600 would be presented.
The IP address of the device used by the payer, in nnn.nnn.nnn.nnn format.
Information about the order associated with this transaction.
The wallet provider used to collect the customer's payment details used for this transaction.
AMEX_EXPRESS_CHECKOUT
Amex Express Checkout wallet provider.
ANDROID_PAY
Android Pay mobile wallet provider.
APPLE_PAY
Apple Pay mobile wallet provider.
CHASE_PAY
Chase Pay wallet provider.
GOOGLE_PAY
Google Pay mobile wallet provider.
MASTERPASS_ONLINE
MasterPass Online wallet provider.
SAMSUNG_PAY
Samsung Pay mobile wallet provider.
VISA_CHECKOUT
Visa Checkout wallet provider.
Use this field to implement optimistic locking of the session content.
Do this if you make business decisions based on data from the session and wish to ensure that the same data is being used for the request operation.
To use optimistic locking, record session.version when you make your decisions, and then pass that value in session.version when you submit your request operation to the gateway.
If session.version provided by you does not match that stored against the session, the gateway will reject the operation with error.cause=INVALID_REQUEST.
See Making Business Decisions Based on Session Content.
The details describing the source of the funds to be used.
For card payments these may be represented by combining one or more of the following: explicitly provided card details, a session identifier which the gateway will use to look up the card details and/or a card token. Precedence rules will be applied in that explicitly provided card details will override session card details which will override card token details. Each of these may represent partial card details, however the combination must result in a full and complete set of card details. See Using Multiple Sources of Card Details for examples.
Information about the source of funds when it is directly provided (as opposed to via a token or session).
For browser payments, the source of funds details are usually collected from the payer on the payment provider's website and provided to you when you retrieve the transaction details (for a successful transaction). However, for some payment types (such as giropay), you must collect the information from the payer and supply it here.
Details about the card.
Use this parameter group when you have sourced payment details using:
- Cards: the card details entered directly or collected using a Point of Sale (POS) terminal.
- Device payment methods such as Apple Pay, Android Pay, Samsung Pay or Google Pay.
- Digital wallets such as Masterpass, Visa Checkout or Amex Express Checkout.
- Card scheme tokens where the card was tokenized using a card scheme tokenization service such as Mastercard Digital Enablement Service (MDES).
If the payer chose to pay using a device you must provide payment details in this parameter group. Use this parameter group when accepting payments using device payment methods such as Apple Pay, Android Pay or Samsung Pay.
This is the payment token that you received from the device's payment SDK.
For example:
For Apple Pay - this is the PKPaymentToken.paymentData value.
For Google - this is PaymentMethodToken.getToken().
Note 1: The gateway API considers this value to be a string, NOT JSON itself. Therefore, when using the JSON gateway API, this field will typically look like:
"sourceOfFunds": {
"provided": {
"card": {
"devicePayment": {
"paymentToken": "{\"data\":\"869ss19ew ....
Note 2: The gateway will ignore the currency and amount information in the payment token, and will instead use the values passed on the amount and currency fields. For normal usage, you should populate those fields with the exact same values as you got from the SDK.
Expiry date, as shown on the card.
Month, as shown on the card.
If using a scheme
token this is the token expiry month.
Months are numbered January=1,
through to December=12.
Year, as shown on the card.
If using a scheme
token this is the token expiry year.
The Common Era year is 2000
plus this value.
Credit card number as printed on the card.
Card verification code, as printed on the back or front of the card or as provided for a card scheme token.
Callback data Copied to clipboard
The REST API response.
The last correlation id that was used for making the REST API call.
The gateway recommendation based on the cumulative risk score as determined by the ACS and the gateway.
Code to create the authentication UI.
Return Value Copied to clipboard
None