Payment Method Features

Card Eligibility

Only RuPay debit cards issued in India are accepted. The card type is checked by its BIN (first digits of the card number) when the Intent is created. For any other card (RuPay credit or prepaid, Visa, Mastercard, etc.) the payment is not created and the error is returned in paymentCreationErrors.

Compliance Data (LRS)

For merchants in the air travel and travel segments, payments fall under the Liberalised Remittance Scheme (LRS) of the Reserve Bank of India. For these merchants the request must additionally contain the payer's PAN (Indian tax identifier) in payer.taxIdentification, the postal code (PIN code) in billingAddress.postcode, and the date of birth and LRS declarations in incomingDetails — see the tables below. You must display the LRS declarations, Terms & Conditions and the Tax Collected at Source (TCS) notice to the payer and pass their answers.

Whether LRS applies to your account is agreed during onboarding and configured by our integration team — it is not passed in the request.

Workflow: Payment & Refund

Download in high resolution

Possible Payment Scenarios:

List of used API Requests:

Intent Creation Request/Response

{
  "clientReferenceId": "1234",
  "payments": [
    {
      "payer": {
        "firstname": "Jake",
        "lastname": "Yellow",
        "phone": "+919876543210",
        "taxIdentification": "AAAPZ1234C"
      },
      "billingAddress": {
        "countryIsoCode": "IN",
        "postcode": "110001"
      },
      "paymentInstrument": {
        "paymentMethodName": "BankCardRuPay",
        "incomingDetails": {
          "number": "6080010000000017",
          "expiryMonth": "12",
          "expiryYear": "2028",
          "cvv": "123",
          "holderName": "JAKE YELLOW",
          "redirectUrl": "https://merchant.example.com/payment/success",
          "failureUrl": "https://merchant.example.com/payment/failure",
          "dateOfBirth": "1993-09-15",
          "lrsMandatoryLimitDeclaration": true,
          "lrsTnc": true,
          "lrsTcsDeclarationUnderLimit": false
        }
      },
      "submittedAmount": {
        "value": 100.05,
        "currency": "USD"
      },
      "authCurrencyCode": "INR",
      "description": "Vertex - INTENT 1234",
      "webhookUrl": "webhookUrl"
    }
  ],
  "description": "Vertex - INTENT 1234",
  "merchant": {
    "name": "Mustermann",
    "website": "website.io"
  },
  "extensionAttributes": {
    "attributeName1": "attributeValue1",
    "attributeName2": "attributeValue2"
  }
}

{
  "intentId": "232510340021612544",
  "payments": [
    {
      "id": "232510340646563840",
      "payer": {
        "phone": "+XXXXXXXXXXX"
      },
      "submittedAmount": {
        "value": 100.05,
        "currency": "USD"
      },
      "authAmount": {
        "value": 8350.00,
        "currency": "INR"
      },
      "paymentInstrument": {
        "id": "PI204264628196626432",
        "paymentMethodId": "PM199507277233246209",
        "paymentMethodName": "BankCardRuPay",
        "storedDetails": {
          "maskedNumber": "608001******0017",
          "bin": "608001",
          "lastFour": "0017",
          "token": "string",
          "expiryMonth": "12",
          "expiryYear": "2028",
          "holderName": "JAKE YELLOW",
          "redirectUrl": "https://merchant.example.com/payment/success",
          "failureUrl": "https://merchant.example.com/payment/failure"
        }
      },
      "processingStatusCode": "CODE_PT0000",
      "statusMessage": "string",
      "status": "ACCEPTED",
      "additionalData": {
        "details": {
          "url": "3DS Session url"
        }
      }
    }
  ],
  "disbursements": [],
  "clientReferenceIntentId": "123456789",
  "paymentCreationErrors": [],
  "disbursementCreationErrors": [],
  "intentStatus": "IN_PROGRESS"
}

Refunds

To initiate the refund (full or partial) to the payer's original payment instrument, you must send a separate Refund request.
Use the following endpoint: Create Refund and specify the following parameters:

{
  "paymentId": 204264682781298700,
  "partial": false,
  "reason": "Customer requested a refund",
  "webhookUrl": "webhookUrl"
}

{
  "paymentId": 204264682781298700,
  "partial": true,
  // For a partial refund, specify ONLY ONE of the following:
  // - paymentSubmittedAmount (original/submitted currency)
  // - paymentAuthAmount (authorised/settlement currency)

  // This is required when FX conversion was involved in the payment
  // (e.g. USD -> INR). The refund will be calculated using the SAME
  // exchange rate as the original payment.
  //
  // Choose the object based on the currency in which you want to
  // define the refund amount, and populate only that object.

  // Option 1: Submitted currency (inactive example)
  //  "paymentSubmittedAmount": {
  //    "value": 100.05,
  //    "currency": "USD"
  //  },

  // Option 2: Authorised currency (active example)
  "paymentAuthAmount": {
    "value": 100.05,
    "currency": "INR"
  },
  "reason": "Customer requested a refund",
  "webhookUrl": "webhookUrl"
}

After the creation of the refund request you must wait for the callback, that will provide you with the latest transaction status

Webhooks

Testing in Sandbox

The bank card emulator simulates the full H2H payment lifecycle in the sandbox environment. Use the test cards below to reproduce specific authorisation and completion outcomes.

What the H2H emulator covers

• Available in the sandbox environment only.
• The outcome is determined by the card number and the OTP value; the LRS scenario — by the Intent description and payer.taxIdentification (see LRS merchants). Expiry date, CVV, and cardholder name do not affect emulator logic — any values that pass validation are accepted.
• Amount and currency do not affect emulator behaviour.
• Completion behaviour (capture or cancellation, and the delay) depends on the Settlement Account + payment method configuration. See Completion below.

Authorisation flow

RuPay payments always require OTP authentication (Challenge flow). The payer must briefly land on a page hosted by our platform so we can collect device metadata for fraud checks. The client redirects the payer to the URL returned in the Intent creation response. After metadata collection, the payer is presented with an OTP form before being redirected back to the merchant.

Download in high resolution

Test cards and OTP values

Ineligible cards

LRS merchants

In the sandbox, the LRS scenario is selected by the Intent description:

For the LRS scenario, use payer.taxIdentification = ABCDE1234Z. Any other value fails PAN validation: the payment is not created and the error is returned in paymentCreationErrors.

Completion: capture or cancellation

After a successful authorisation, the payment is completed automatically — either captured (funds taken) or cancelled (authorisation released). The action and the delay are configured per Settlement Account and payment method. Manual completion via API is not available for this payment method.

Emulator behaviour

The completion outcome is determined by the same PAN used for authorisation. The emulator returns the same outcome regardless of the configured action (capture or cancellation).