API Overview

Recent Revisions to This Document

About This Guide

VISA Platform Connect: Specifications and Conditions for Resellers/Partners

Overview of RuPay Payer Authentication
- Authentication Modes

Redirection Mode Payer Authentication
- Check Enrollment Service
  - Check Enrollment Request
  - pa-rupay-int-redir-enroll-overview-resp
  - REST Example: Enrollment Service
- Authenticating Cards Using Redirection
  - HTML Frame Requirements
  - HTTP Post Form
  - PARes Message from the RuPay Card-Issuing Bank
- Authorization Service
  - REST Example: Authorization
- Validating Authentication
  - Validation Service Request
  - Pass or Fail Message Page
  - REST Example: Validate Authentication Service

Seamless Flow Payer Authentication
- Possible Authentication Results
- One-Time Password Generation
  - Required Fields for Generating a One-Time Password in RuPay
  - REST Example: One-Time Password Generation
  - REST Example: One-Time Password Generation (with Token)
- One-Time Password Resend
  - Required Field for Resending a One-Time Password in RuPay
  - Response Field for Checking Enrollment in Payer Authentication
  - REST Example: One-Time Password Resend
  - REST Example: One-Time Password Resend (with Token)
- One-Time Password Validation
  - Required Fields for Validating a One-Time Password in RuPay
  - Response Fields for Payer Authentication Validation in RuPay
  - Example: One-Time Password Validation (No Token)

Standing Instructions
- Standing Instruction Registration
  - Required Fields for Standing Instruction Registration
  - Optional Fields for Standing Instruction Registration
  - REST Example: Registering a Standing Instruction
  - REST Example: Registering a Standing Instruction (with Token)
- Standing Instruction Modification
  - Required Fields for Standing Instruction Modification
  - Optional Fields for Standing Instruction Modification
  - REST Example: Modifying a Standing Instruction
  - REST Example: Modifying a Standing Instruction (with Token)
- Standing Instruction Deregistration (Cancellation)
  - Required Fields for Deregistering a Standing Instruction
  - REST Example: Deregistering a Standing Instruction
  - REST Example: Deregistering a Standing Instruction (with Token)
- Completion of Standing Instructions
  - Required Fields for Standing Instruction Completion
  - REST Example: Completing a Standing Instruction
- Standing Instructions Intimation
  - Required Fields
  - REST Example: Intimating a Standing Instruction
- One-Time Password Generation
  - Required Fields for Generating a One-Time Password in RuPay
  - Optional Fields for Generating a One-Time Password
  - REST Example: One-Time Password Generation
  - REST Example: One-Time Password Generation (with Token)
- One-Time Password Resend
  - REST Example: One-Time Password Resend
  - REST Example: One-Time Password Resend (with Token)
- One-Time Password Validation
  - Required Fields for Validating a One-Time Password in RuPay
  - Response Fields for Payer Authentication Validation in RuPay
  - Example: One-Time Password Validation (No Token)
- Standing Instruction Authorization
  - Required Fields for SI Authorizations
  - Optional Fields for Standing Instruction Authorization
  - REST Example: Authorizing a Standing Instruction
  - REST Example: Authorization of a Standing Instruction Transaction (with Token)

On This Page

Standing Instructions

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.

Back to top