Added a Standing Instructions section that includes use cases.
22.02
Updated OTP Resend section.
22.01
Added Seamless Flow section to manual.
Added a REST version.
19.01
Initial release.
About This Guide
Audience and Purpose
This guide is written for application developers who want to use the
REST
API to integrate Payer Authentication services into their order management system to
process RuPay payments.
It describes the tasks you must perform in order to complete this integration. Implementing Payer Authentication services requires
software development skills. You must write code that uses the API request and response fields to integrate payer authentication
services into your existing order management system.
Scope
This guide describes how to use the
REST
API
to integrate payer authentication services with your order management system. It does not describe how to get started using the
REST
API nor does it explain how to use
services other than payer authentication. For that information, see the following
Related Documents
section.
Conventions
The following special statements are used in this document:
IMPORTANT
An
Important
statement contains information essential to successfully completing a task or learning a
concept.
WARNING
A
Warning
contains information or instructions, which, if not heeded, can result in a security risk,
irreversible loss of data, or significant cost in time or revenue or both.
Customer Support
For support information about any service, visit the Support Center:
VISA Platform Connect: Specifications and Conditions for Resellers/Partners
The following are specifications and conditions that apply to a Reseller/Partner
enabling its merchants through
Cybersource for Visa Platform Connect
(“VPC”) processing
. Failure to meet any of the specifications and
conditions below is subject to the liability provisions and indemnification
obligations under Reseller/Partner’s contract with Visa/Cybersource.
Before boarding merchants for payment processing on a VPC acquirer’s connection,
Reseller/Partner and the VPC acquirer must have a contract or other legal
agreement that permits Reseller/Partner to enable its merchants to process
payments with the acquirer through the dedicated VPC connection and/or
traditional connection with such VPC acquirer.
Reseller/Partner is responsible for boarding and enabling its merchants in
accordance with the terms of the contract or other legal agreement with the
relevant VPC acquirer.
Reseller/Partner acknowledges and agrees that all considerations and fees
associated with chargebacks, interchange downgrades, settlement issues, funding
delays, and other processing related activities are strictly between Reseller
and the relevant VPC acquirer.
Reseller/Partner acknowledges and agrees that the relevant VPC acquirer is
responsible for payment processing issues, including but not limited to, transaction
declines by network/issuer, decline rates, and interchange qualification, as may be
agreed to or outlined in the contract or other legal agreement between
Reseller/Partner and such VPC acquirer.
DISCLAIMER: NEITHER VISA NOR CYBERSOURCE WILL BE RESPONSIBLE OR LIABLE FOR ANY ERRORS
OR OMISSIONS BY THE VISA PLATFORM CONNECT ACQUIRER IN PROCESSING TRANSACTIONS.
NEITHER VISA NOR CYBERSOURCE WILL BE RESPONSIBLE OR LIABLE FOR RESELLER/PARTNER
BOARDING MERCHANTS OR ENABLING MERCHANT PROCESSING IN VIOLATION OF THE TERMS AND
CONDITIONS IMPOSED BY THE RELEVANT VISA PLATFORM CONNECT ACQUIRER.
Overview of RuPay Payer Authentication
Cybersource
payer authentication services provide
support to your web store for card authentication services for RuPay cards. Payer
authentication for RuPay uses the same API services provided by
Cybersource
for other card brands. If you are currently
using
Cybersource
payer authentication services for
other card brands, you can enhance your existing integration to send the additional
fields in the request that are required for RuPay cards.
Payer authentication provides these services:
Check Enrollment: Determines whether the customer is enrolled in a card
authentication program.
Validate Authentication: Ensures that the authentication that you receive from the
issuing bank is valid.
Unlike Visa and Mastercard cards, authentication is mandatory for RuPay cards. Without
authentication, authorization cannot occur and the transaction is declined by the RuPay
network.
Authentication Modes
RuPay authenticates the cardholder in two ways:
Redirection—This mode of payer authentication has the issuer hosting the password
entry page. When a cardholder is being authenticated during a transaction, the
issuer sends a one-time password to the cardholder's phone so that the cardholder
can enter the password into a displayed entry form. If the entered password matches
the password that was sent, the cardholder is authenticated and the transaction
proceeds. In the Redirection mode, the password authentication is redirected away
from the merchant to a URL that the issuer sends. The issuer hosts the password
entry form at this URL. This redirection from the merchant to the issuer can cause
lag time during the transaction processing due to network traffic.
Seamless Server to Server—This mode of payer authentication has the merchant hosting
the password entry page. This is an improved method of authenticating with a
one-time password. The process of password authenticating is much the same as the
redirection but this method keeps the hosting of the password entry page with the
merchant. The cardholder does not leave the merchant's web site during
authentication. When the merchant hosts the password entry page, timeouts are
reduced and transactions process faster.
The first section of this guide describes the Redirection Flow of payer authentication
while the following section describes the Seamless Flow mode.
Redirection Mode Payer Authentication
When using Redirection Mode, during a transaction, the cardholder is redirected to the
issuer's authentication page. Once redirected, a one-time password is sent to the
cardholder's previously set email or phone number. When the cardholder re-enters the
one-time password successfully, the cardholder is authenticated and returned to the
merchant site to complete the transaction.
Network processing can introduce lag time into the purchase transaction.
Check Enrollment Service
When the customer places an online order, the the customer information is sent to the
Verify Enrollment Response service (VERes) to verify that the card is enrolled in a
payer authentication program.
If the card is enrolled, the VERes reply field indicates enrollment. The reply
also contains the URL of the Access Control Server and the PAReq.
If the card is not enrolled, decline the payment and ask the customer for
another form of payment.
Check Enrollment Request
For RuPay, the Check Enrollment service verifies that the card is enrolled in a card
authentication program.
This request must include the following fields:
deviceInformation.ipAddress
The IP address must be the IP address of the customer who is making the purchase on your website.
It must not be hard-coded or contain the address of the merchant’s servers.
RuPay needs the correct IP address to manage any potential disputes.
deviceInformation.httpAcceptBrowserValue
This field contains the value of the Accept header sent by the customer’s web browser.
deviceInformation.userAgentBrowserValue
This field contains the value of the User-Agent header sent by the customer’s web browser.
{
"clientReferenceInformation": {
"code": "cybs_test"
},
"consumerAuthenticationInformation": {
"acsUrl": "https://pnrstage.ic3.com:9448/cybersource/payerAuthentication/paySecure/initiate?binType=S",
"xid": "MTM0MjE0MjYzODEzMTIwODE3NTA=",
"authenticationTransactionId": "MTM0MjE0MjYzODEzMTIwODE3NTA=",
"pareq": "e0NCQ2l2fWs3SVplQTVsZytraXBrOEFSNldKQVJBQUVDVmFhQlI2cC9DNVAzRGMrcFl6T3N1L09RZjF3UEhRU2NYWDZ4Y0wyVjhMalhiT0xtZW5zRVJ6Zi9ONEhyN1JXQ2NzbVFSbkZrZUYySDBNOGFxODUyYnJiRG1FTnBqMHZ2Z1NObFo1dHdEYjFlVlAwdnd5NDZSamttUzFiclZKZ2dkbkJPZWVmMlpnajVMWjVSaHhBZUhPN2VBM3lLNm5lTUZJQ3g0K1pkcVU4NWJRZW9vZVNTZFFnOGhBL3ZzNlZ3S0FWMHhJZUdaanJwREVQZ1RXM1ZDNnlqdS8xLzhVTWxIUGV1QjhOb3B3YnA2Y1UwZDl0aU9IVUJEQ0J2NFYyM0F1ZXFZQVFMNi9ramdvSFJWSjdkdVBGSHllWXc5endnc2VidVkxeTBYTmRMSFpEYXdkSjJVcFJlaGFwOC9kVHNNNmVFbGQ4N2k1UXBBdE82STFOY0xERkZRbmNUY2VOSFU5b2JYWkdrMThGN29MeXBUeTZTZjJHSlZsb2ZhTUl6U1N4OXAzNmM0bjhqK2RSN3ZCazdteXBrSVBINW1zR25zNjROeExSNnRYTCswd216RHIzaHZrUFNnK3ZsK1dyU2Z1c0F1TjR6dmtLVitQcEpZQUdtOWJsODhrbjMvYzVXN2FCbWFYcjZaVg==",
"veresEnrolled": "Y",
"authenticationPath": "ENROLLED",
"specificationVersion": "rupay",
"token": "AxjzbwSTWmCT4JORCOKv/989TSoG953CyDpxAU+Xb2/+xcVYlDjA6AAA+AGE"
},
"errorInformation": {
"reason": "CONSUMER_AUTHENTICATION_REQUIRED",
"message": "The cardholder is enrolled in Payer Authentication. Please authenticate the cardholder before continuing with the transaction."
},
"id": "6389532602277120500399",
"status": "PENDING_AUTHENTICATION",
"submitTimeUtc": "2021-12-08T08:47:52Z"
}
Authenticating Cards Using Redirection
After verifying that a customer’s card is enrolled in a card authentication program, you
must redirect the customer to the URL of the card-issuing bank’s Access Control Server
(ACS URL).
The HTTP POST request web form must contain the following:
PAReq data
Termination URL (TermURL)
merchant data (MD)
The MD value must be posted for RuPay. If necessary, you can include it for other card
brands as well.
HTML Frame Requirements
When your customers are redirected to the ACS URL, their browsers display the frame
containing the password authentication page of the card-issuing bank or the option to
sign up for the program (activation form).
On the page that contains the in-line frame for the ACS URL:
Ensure that the HTML frame is large enough to accommodate the card-issuer’s
authentication or activation form, and the text that describes the process to the
customer.
Provide a brief message outside the HTML frame to guide customers through the
process. For example, “We are processing your request. Do not click the Back button
or refresh the page or this transaction may be interrupted.”
HTTP Post Form
The page typically includes JavaScript that automatically posts the form. This code provides:
A page that receives the reply fields for the enrollment check service.
A form that contains the required data for the card-issuing bank.
The card-issuing bank sends a PARes message to your TermURL in response to the PAReq data
that was sent with the web form. The PARes message is sent by using an HTTP POST request
and contains the result of the requested authentication.
The signed PaRes field contains a base64-encoded string with this information:
PARes—Digitally signed payer authentication response message that contains the
authentication result. (Note that while the field name has a lowercase “a”
(PaRes), the message name has an uppercase “A” (PARes)).
MD—Merchant data, which must be submitted for RuPay.
Authorization Service
The authorization service format that you send for RuPay is the same used for other card
types. Send the CAVV and XID in the authorization service request with the card details
for
Cybersource
to process this request with the
RuPay card network.
For RuPay, the e-commerce indicator returned in the validation service response must be
set to
rpy
or the authorization results in an error.
For an SMS type of card, send the authorization service and capture service requests at
the same time. Sending just the authorization service request for an SMS type of card
causes an error.
For enrolled cards, the next step is to request the validation service to verify the
authentication message (PARes) returned by the card-issuing bank.
Validation Service Request
When you make the validation request, you must:
Extract the PARes message from the form received from the card-issuing
bank.
Remove any spaces created by tabs, spaces, or line breaks from the
PaRes
field. Do not modify any other part of the
PaRes
field.
Send the
PaRes
value in the signed
PaRes
field of the validation service to
Cybersource
. The response contains the validation result.
You can use the validation and card authorization services in the same
request or in separate requests:
Same request—
Cybersource
automatically attempts to authorize your customer’s
card if validation succeeds. The values of the required fields are added
automatically to the authorization service. Do not pass any fields that
Cybersource
derives from the
PaRes
value into the request
because that data could be overwritten.
Separate requests—You must manually include the validation result values
(Payer Authentication response fields) in the authorization service request
(Card Authorization request fields), which are listed in this table:
Identifier
Payer Authentication Response Field
Card Authorization Request Field
XID
consumerAuthenticationInformation.
xid
consumerAuthenticationInformation.
xid
E-commerce indicator
consumerAuthenticationInformation.
indicator
processingInformation.commerce
Indicator
CAVV
consumerAuthenticationInformation.
cavv
consumerAuthenticationInformation.
cavv
If you are currently passing additional card-specific values in the Payer
Authentication Validate response for Visa and Mastercard, you can continue to pass
them for RuPay.
Pass or Fail Message Page
After authentication is complete, redirect the customer to a page containing a success or
failure message. Ensure that all messages that display to customers are accurate,
complete, and that they address all possible scenarios for enrolled and non-enrolled
cards. When authentication fails, a message such as this example, should be displayed to
the customer:
Authentication Failed
Your card issuer cannot authenticate this card.
Please select another card or form of payment to complete your purchase.
In Rupay Redirection Flow, the card issuer hosts an entry page on the payment terminal
where the cardholder enters a one-time password (OTP). Redirecting the OTP process from
the merchant to the issuer results in extra processing time and timeouts. In RuPay
Seamless Flow, the merchant, who must be PCI DSS compliant, hosts the OTP entry page,
providing a more seamless experience and reducing transaction timeouts. You might have
to use tokenization to ensure PCI DSS compliance.
Figure:
Example of an OTP Page
To use the RuPay Seamless workflow, contact the merchant reseller or customer support to
have the account configured with this service.
The OTP entry page is part of the two-factor authentication used in payer authentication
for the transaction. If you are PCI DSS compliant and can host the OTP entry page, use
this workflow:
When payer authentication is initiated, it checks if the transaction is with RuPay.
When the transaction is not with RuPay, Cardinal Direct does the payer
authentication.
When it is a RuPay transaction, the BIN of the issuer is checked to determine
whether to use the Redirection Flow or the Seamless Flow.
If the Seamless Flow is used, the Payer Authentication Enrollment service sends a
call to the issuer to create and send an OTP to the cardholder.
Payer Authentication prompts the merchant to display a page on the payment terminal
for the cardholder to enter the OTP that is received on their phone.
The OTP entered by the cardholder is authenticated with the Payer Authentication
Validation service using the ID associated with the OTP that was sent to the
cardholder.
After the OTP is validated, the validation response returns a validation transaction
context ID. Send this ID in the authorization request.
Possible Authentication Results
The following table lists the expected results based on the parameters included in
your authorization request.
XID
CAVV
Authentication Value
Installment Identifier
ECI
Expected Result
Y
Y
N
N
ANY
redirection flow
N
N
Y
N
ANY
s2s flow
N
N
IGNORE
Y
R
s2s flow
IGNORE
IGNORE
IGNORE
N
R
identifier error
Y
N
Y
IGNORE
IGNORE
conflict error
N
Y
Y
IGNORE
IGNORE
conflict error
s2s flow(default)
Y
Y
N
Y
R
Y
Y
N
Y
rpy
Y
N
N
N
rpy
N
Y
N
N
rpy
One-Time Password Generation
When the cardholder is being authenticated, the Payer Authentication Enrollment service
is called sending a one-time password (OTP) to the cardholder. The merchant is notified
to display a merchant-branded page on the terminal where the cardholder can enter the
OTP they received. This OTP is returned to the issuer for validation. This section lists
the API fields used to generate and send the OTP to the cardholder, explains how to call
this service, and provides samples of calling the service.
Required for the request that resends the OTP entered by the cardholder.
Without this ID, the request is treated as a request to generate a new OTP.
Also used in the Payer Authentication Validation request.
{
"clientReferenceInformation": {
"code": "test"
},
"consumerAuthenticationInformation": {
"validityPeriod": "05",
"authenticationTransactionContext": "100000000000000000000000025253",
"authenticationTransactionId": "00000012345330104948258905",
"veresEnrolled": "Y",
"authenticationPath": "ENROLLED",
"authenticationType": "20",
"specificationVersion": "rupay",
"token": "AxjzbwSTWc72QPm3yK4i/989TSoGbqdyyDpxAUxXb2/+xcVYlDjA/AAAXgKG"
},
"errorInformation": {
"reason": "CONSUMER_AUTHENTICATION_REQUIRED",
"message": "The cardholder is enrolled in Payer Authentication. Please authenticate the cardholder before continuing with the transaction."
},
"id": "6379039884087153700386",
"status": "PENDING_AUTHENTICATION",
"submitTimeUtc": "2021-11-26T05:19:48Z"
}
}
One-Time Password Resend
After the cardholder receives the OTP on their mobile phone, they enter it into the form
that is displayed on the merchant terminal. After entering the password, the cardholder
presses
Enter
and the password is returned to the issuer to
verify that the OTP matches what was sent to the cardholder. When the response from the
issuer is an invalid or incorrect OTP, resend OTP can be triggered. The request includes
the original
that was returned in the Payer Authentication Enrollment response. The transaction ID
enables the matching of the original OTP that was sent to the cardholder with the OTP
that the cardholder entered into the terminal. After the OTP match is made, the
cardholder is authenticated and can then be validated.
The process for running this service is the same one used to generate the original OTP
except for including the ID generated by the response. Refer to the One-Time Password Generation section for a
list of required and optional fields used in Payer Authentication Enrollment when
resending the password to the issuer.
Required Field for Resending a One-Time Password in RuPay
This field is required for RuPay when returning the one-time password to the issuer:
{
"clientReferenceInformation": {
"code": "test"
},
"consumerAuthenticationInformation": {
"validityPeriod": "05",
"authenticationTransactionContext": "100000000000000000000000025253",
"authenticationTransactionId": "00000012345330094331258803",
"veresEnrolled": "Y",
"authenticationPath": "ENROLLED",
"authenticationType": "20",
"specificationVersion": "rupay",
"token": "AxjzbwSTWc8FjykV5njC/989TSoGbqd6yDpxAUxXb2/+xcVYlDjA/AAAVgJm"
},
"errorInformation": {
"reason": "CONSUMER_AUTHENTICATION_REQUIRED",
"message": "The cardholder is enrolled in Payer Authentication. Please authenticate the cardholder before continuing with the transaction."
},
"id": "6379044192177153800386",
"status": "PENDING_AUTHENTICATION",
"submitTimeUtc": "2021-11-26T05:26:59Z"
}
One-Time Password Validation
If the OTP entered by the cardholder matches the OTP that was sent, the cardholder is
authenticated and is ready to be validated so the transaction can be authorized. The
field that is used during payer authentication is also used during validation to
associate the validation with the proper Payer Authentication Enrollment call.
Note that no token or card number is necessary during validation of an OTP so no example
with token is provided in this section.
Required Fields for Validating a One-Time Password in RuPay
These fields are required for RuPay when validating the one-time password the customer
sends:
This token is returned in the Payer Authentication Validation OTP response.
While required for customer initiated transactions, do not include this
field during merchant initiated Standing Instructions transactions that
use the
A Standing Instruction (SI) is an agreement between the customer, the merchant, and the
acquirer. The merchant sets up a fixed payment to automatically charge the customer's
card account at regular intervals and notifies the acquirer of the billing arrangement.
The cardholder enters their card information and configures when the payments should
occur. The payment interval can be specified as a day of the week or a date during the
month. A notice of the amount and the date of the transaction is sent to the customer
and the issuer before the transaction happens so that the customer retains the
opportunity to decline the transaction. This process of alerting the customer to an
impending transaction is called
intimation
. The customer can cancel a SI
transaction by contacting the merchant or the issuer.
There are three aspects to a SI transaction:
Registration: The customer registers their payment information and configures the
parameters of the SI transactions so that the payments can be automatically
processed at the stipulated time. By configuring the payment parameters for the
first SI transaction, subsequent SI transactions do not require the cardholder to
enter any payment information. With intimation, the cardholder must approve of each
transaction before it occurs.
Modification: The cardholder information and payment parameters configured for the
SI transactions can be modified at any time. Before any cardholder information or
the existing parameters configured for the SI transaction can be modified, two
factor authentication is used to verify the cardholder's identity .
Deregistration: Cardholder information and payment parameters for SI transactions
can be deregistered (or cancelled) at any time. To end the future payments
scheduled with a SI transaction, deregister the cardholder.
For each aspect of a SI transaction, the cardholder goes through payer authentication to
verify that the cardholder is enrolled in a payer authentication program and then the
cardholder's identity is validated using two factor authentication. After the SI
transaction is initially set up, payer authentication is not required for subsequent
installments unless the SI is modified.
Standing Instruction Registration
During registration, the merchant uses the information provided by the cardholder to
register with the issuer for SI transactions through RuPay. During registration, the
cardholder is authenticated. Once the cardholder is authenticated, subsequent
transactions do not require authentication. After registration, authentication is only
required again when the billing agreement is modified or cancelled (deregistered). The
registration can occur at two different times:
Before any SI transactions start: Cardholder sets up the SI transaction to start
at a future time, often 30 days later. The customer can be sent a payment link
or go to a payment portal to initiate the first payment. The customer must
verify their identity with two factor authentication.
At the time of the first SI transaction: Cardholder makes the first payment when
setting up the SI transactions. Parameters for future payments are configured
and the customer provides consent for the first payment. Payer authentication is
only done for the first SI transaction. Subsequent SI transactions do not
require payer authentication unless the original SI agreement is modified.
When registering a customer for SI transactions, the merchant collects information to
configure the parameters of the transactions. The cardholder is assigned a SI
registration ID that links to the information provided by the cardholder. This
information includes:
Number of SI transactions
Mode of communication with the customer (email or text)
Frequency
Minimum and maximum amount limits for a transaction
Transaction amount
Preferred date for transaction
While the specific amount and date of the transaction might be unavailable at the time of
registration, the merchant always intimates the amount and date to the customer by text
or email before each SI transaction occurs.
After the SI transaction is set up, each SI transactions is charged by the merchant on
the preferred date. Twenty-four hours before each SI transaction occurs, the merchant
intimates to the customer, the amount and date of the pending transaction. The amount
charged must be within the minimum and maximum amount values configured by the
cardholder during registration. If no maximum value was specified, 5,000 rupees is the
maximum value.
Required Fields for Standing Instruction Registration
These fields are required when registering for a SI transaction:
installmentInformation.alertPreference
Only used with RuPay for the payer authentication seamless flow.
{
"clientReferenceInformation": {
"code": "test"
},
"consumerAuthenticationInformation": {
"validityPeriod": "05",
"authenticationTransactionContext": "100000000000000000000000025253",
"authenticationTransactionId": "00000012345334130405260122",
"veresEnrolled": "Y",
"authenticationPath": "ENROLLED",
"authenticationType": "20",
"specificationVersion": "rupay",
"token": "AxjzbwSTWgAKsBvnFT5i/989TSoGg2p6yDpxAU1Xb2/+xcVYlDjA/AAABgHI"
},
"errorInformation": {
"reason": "CONSUMER_AUTHENTICATION_REQUIRED",
"message": "The cardholder is enrolled in Payer Authentication. Please authenticate the cardholder before continuing with the transaction."
},
"id": "6382576457887159500386",
"status": "PENDING_AUTHENTICATION",
"submitTimeUtc": "2022-11-30T07:34:06Z"
}
Standing Instruction Modification
During SI registration, customer information and payment parameters are set up for
subsequent transactions. This transaction configuration remains in effect until the
customer modifies the payment parameters or until the specified number of payments is
reached. Two factor authentication is used to verify the cardholder's identity before
any cardholder information or the parameters of a SI transaction are modified.
Required Fields for Standing Instruction Modification
These fields are required when modifying a SI agreement:
Cardholder information and payment parameters for SI transactions can be deregistered (or
cancelled) at any time. Deregister the cardholder when the cardholder wants to end
subsequent SI transactions. After the last scheduled transaction, any associated tokens
expire.
Required Fields for Deregistering a Standing Instruction
These fields are required when deregistering a SI transaction:
{
"clientReferenceInformation": {
"code": "cybs_test"
},
"consumerAuthenticationInformation": {
"validityPeriod": "05",
"authenticationTransactionContext": "100000000000000000000000025253",
"authenticationTransactionId": "00000012345342141537264106",
"veresEnrolled": "Y",
"authenticationPath": "ENROLLED",
"authenticationType": "20",
"specificationVersion": "rupay",
"token": "AxjzbwSTWmCPKLjUiOgP/989TSoG9526yDpxAU+Xb2/+xcVYlDjA/AAAXwKK"
},
"errorInformation": {
"reason": "CONSUMER_AUTHENTICATION_REQUIRED",
"message": "The cardholder is enrolled in Payer Authentication. Please authenticate the cardholder before continuing with the transaction."
},
"id": "6389531274227120400399",
"status": "PENDING_AUTHENTICATION",
"submitTimeUtc": "2022-12-08T08:45:37Z"
}
Completion of Standing Instructions
Completion of the SI occurs when all of the transactions that were scheduled during the
interval of time specified in the agreement process successfully. The completion is
handled like previous SI transactions except it is the last transaction. No more
transactions will occur because the time period scheduled for the payments to occur has
ended. If the customer wants to continue receiving the service covered by the SI, the SI
agreement should be modified to extend the payment interval.
Required Fields for Standing Instruction Completion
The following fields are required when completing registration for a SI transaction:
You must intimate the customer and the issuer of the pending SI transaction 24 hours
before the transaction occurs. Notification to the customer is by email, text, or both,
as specified during registration. In the notification, you must provide the amount and
date of the transaction. The amount must be within the minimum and maximum ranges of
value that were configured during registration. The transaction cannot exceed the
maximum value of 5,000 rupees that is mandated by the Reserve Bank of India (RBI).
Intimation does not require any type of payer authentication since the customer was
authenticated during registration and the card information is already on file.
Required Fields
These fields are required when intimating a pending SI
transaction:
