๐Ÿ‡ท๐Ÿ‡บ RU: Bank Cards - Payments

๐Ÿ“˜

This payment method is supported in two integration scenarios: Host-to-Host and Hosted Checkout.

  • For Hosted Checkout, please refer to the dedicated page.
  • For Host-to-Host integration, please follow the guide below.
๐Ÿ““

Please use the following paymentMethodName value when creating the Intent and when completing the payment object.

"paymentMethodName": "BankCardRU"

Payment Method Features

Payment MethodBankCardRU
CountryRussia
Processing CurrenciesRUS
PaymentsYes
-- Min per transaction amountVary, depends on your contract
-- Max per transaction amountVary, depends on your contract
RefundsFull & Partial
-- Full RefundYes
-- Partial RefundYes
-- Multiple Partial RefundsYes
ChargebacksNo

Workflow: Payment & Refund

Download in high resolution


Possible Payment Scenarios:

๐Ÿ“˜

Auto-Capture or Cancellation

To enable automatic capture or cancellation, you must inform our integration team in advance so they can configure the auto-trigger and define the required timer on their side


Name

Steps

Funds Authorisation without 3DS

  1. You send an Intent creation request via the API, including a Payment transaction.
  2. Our platform validates the incoming data and checks with the issuing bank whether 3DS verification is required.
  3. [3DS verification is not required] Our platform attempts to authorise the funds immediately.
  4. Our platform returns the authorisation result (success or failure) in the synchronous response to the Intent creation request.

Funds Authorisation with 3DS

  1. You send an Intent creation request via the API, including a Payment transaction.
  2. Our platform validates the incoming data and checks with the issuing bank whether 3DS verification is required.
  3. [3DS verification is required] Our platform prepares a redirect URL to handle the 3DS authentication flow (both 3DS v1 and v2)
  4. You open the redirect URL in the payerโ€™s browser or in-app web view, initiating the 3DS authentication.
  5. The payer completes (or fails) the 3DS authentication with the issuing bank.
  6. Our platform processes the 3DS result and attempts to authorise the funds.
  7. Our platform notifies you of the final payment status via a webhook (success or failure).

List of used API Requests:

Request

Endpoint

Description

Intent Creation

POST /processing/api/v1/intents

  • Creates a new Intent with one or more Payment transactions.
  • The platform validates the request, creates internal payment records, and checks whether 3DS authentication is required.

Manual Payment Capture

PATCH /processing/api/v1/payments/{paymentId}

  • Requests capture of previously authorised funds by setting the payment status to CAPTURED.
  • Used for manual capture flows only.

Manual Payment Cancellation

PATCH /processing/api/v1/payments/{paymentId}

  • Requests cancellation (void) of an authorised payment by setting the payment status to CANCELLED.
  • Used for manual cancellation flows only.

Refund Creation

POST /api/v1/refunds

  • Creates a refund request (full or partial) for a previously captured payment.
  • A separate refund transaction is created and processed independently from the original payment.

Intent Creation Request/Response

๐Ÿ““

Request specifics

  • Endpoint: POST /processing/api/v1/intents
  • Purpose: Creates an Intent and a Payment for the selected payment method.
  • Structure: A unified request structure is used for all supported payment methods, but some fields are method-specific.
  • For this method:
    • paymentMethodName must be set to BankCardRU
    • incomingDetails must include: Card Number, Holder Name, Security Code, Expiry Month, and Expiry Year

Intent Request: Example

{
  "clientReferenceId": "1234",
  "payments": [
    {
      "payer": {
        "phone": "+XXXXXXXXXXX"
      },
      "paymentInstrument": {
        "paymentMethodName": "BankCardRU",
        "incomingDetails": {
          "number": "4111111111111111",
          "expiryMonth": "12",
          "expiryYear": "2028",
          "cvv": "123",
          "holderName": "JOHN DOE",
          "redirectUrl": "https://merchant.example.com/payment/success",
          "failureUrl": "https://merchant.example.com/payment/failure",
          "account": "string"
        }
      },
      "submittedAmount": {
        "value": 100.05,
        "currency": "USD"
      },
      "authCurrencyCode": "RUB",
      "description": "Vertex - INTENT 1234",
      "webhookUrl": "webhookUrl"
    }
  ],
  "description": "Vertex - INTENT 1234",
  "merchant": {
    "name": "Mustermann",
    "website": "website.io"
  }
}

Intent Request: Fields Description

Top-Level Request Parameters

ParameterTypeRequiredDescription
clientReferenceIdStringRequiredOrder number in the merchant system.
paymentsArray of ObjectsRequiredList of payment objects to be created within the Intent.
descriptionStringOptionalIntent description.
merchantObjectOptionalMerchant information to be associated with the request.


payment

ParameterTypeRequiredDescription
payerObjectConditionalPayer details. Optional in general, but may be required for specific merchant MCC codes.
paymentInstrumentObjectRequiredPayment method and payment instrument details used to process the payment.
submittedAmountObjectRequiredAmount and currency submitted for the payment.
authCurrencyCodeStringRequiredAuthorisation currency code to be used for the payment.
It may differ from the submitted currency if FX conversion is applied.
If FX conversion is not required, it should match submittedAmount.currency.
descriptionStringOptionalPayment description.
webhookUrlStringRequiredURL to which payment status change webhooks will be sent.


payer

ParameterTypeRequiredDescription
firstnameStringOptionalPayer's first name.
lastnameStringOptionalPayer's last name.
phoneStringConditionalPayer's phone number.
Required for merchants with MCC 4814.
Must be provided in international format: +XXXXXXXXXXX.
emailStringOptionalPayer's email address.
countryIsoCodeStringOptionalPayer's country of residence in ISO 3166-1 alpha-2 format.
localeStringOptionalPayer's preferred language locale.
taxIdentificationStringOptionalConsumer tax identification number.
merchantPayerReferenceStringOptionalMerchant-provided payer reference.


paymentInstrument

ParameterTypeRequiredDescription
paymentMethodNameStringRequiredPayment method name.
For this scenario, use BankCardRU.
incomingDetailsObjectRequiredPayment method-specific data required to initiate the payment.


incomingDetails

ParameterTypeRequiredDescription
numberStringRequiredCard number.
expiryMonthStringRequiredCard expiry month in MM format.
expiryYearStringRequiredCard expiry year in YYYY format.
cvvStringRequiredCard security code (CVV/CVC).
holderNameStringOptionalCardholder name as printed on the card.
redirectUrlStringOptionalURL to which the payer may be redirected after a successful/unsuccessful (if failureUrl is empty) payment flow, if applicable.
failureUrlStringOptionalURL to which the payer may be redirected after a failed payment flow, if applicable.
accountStringConditionalAdditional account-related value.
Required for merchants with MCC 6050 or 6051.


submittedAmount

| Parameter | Type | Required | Description |

ParameterTypeRequiredDescription
valueNumberRequiredSubmitted order amount.
May differ from the authorised amount if FX conversion is applied.
currencyStringRequiredSubmitted order currency.
May differ from the authorised amount if FX conversion is applied.


merchant

ParameterTypeRequiredDescription
nameStringOptionalThe name of store, that might be displayed on the checkout form if configured
websiteStringOptionalThe website of the store




Capture / Cancel Payment

๐Ÿ•‘

IMPROTANT

The timeframe between the authorization and capture / cancellation must not exceed 5 days

  • To capture or cancel the payment transaction and release funds on the payerโ€™s account, you must send a Payment Update request.
  • Use the following endpoint: Update Payment status and specify the action you wish to perform:
    • status = CAPTURED - to capture the authorised amount.
    • status = CANCELLED - to cancel the authorisation and release the reserved funds
  • After receiving your request, we will initiate the capture process and send you a standard webhook with the updated transaction status.


Refunds

๐Ÿ“˜

Refunds cannot exceed the total value of confirmed transactions for the current day.

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. KZT -> RUB). 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": "KZT"
//  },
    
    
// Option 2: Authorised currency (active example)
	"paymentAuthAmount": {
    "value": 100.05,
    "currency": "RUB"
  },

  "reason": "Customer requested a refund",
  "webhookUrl": "webhookUrl"
}
Refund amount rules

RuleDescription
Full refundSend paymentId and set partial to false, or omit partial entirely. The full refundable amount will be refunded.
Partial refundSet partial to true and provide exactly one of the following objects: paymentSubmittedAmount or paymentAuthAmount.
Mutually exclusive amount objectsDo not send paymentSubmittedAmount and paymentAuthAmount in the same request.
FX paymentsIf the original payment involved FX conversion, the refund is calculated using the same exchange rate as the original payment.
Currency choiceUse paymentSubmittedAmount if you want to define the refund in the original submitted currency.
Use paymentAuthAmount if you want to define the refund in the authorised or settlement currency.

Top-Level Refund Request Parameters

ParameterTypeRequiredDescription
paymentIdint64RequiredIdentifier of the original payment transaction to which this refund applies.
Use the paymentId returned in the original payment or Intent creation response.
partialBooleanOptionalIndicates whether the refund is partial or full.
true - partial refund.
false - full refund.
If omitted, the platform treats the request as a full refund.
paymentSubmittedAmountObjectConditionalRefund amount in the original submitted currency.
Required when partial = true and the refund amount is defined in the submitted currency.
Do not send together with paymentAuthAmount.
paymentAuthAmountObjectConditionalRefund amount in the authorised or settlement currency.
Required when partial = true and the refund amount is defined in the authorised currency.
Do not send together with paymentSubmittedAmount.
reasonStringOptionalFree-form refund reason.
Used for informational and audit purposes.
webhookUrlStringOptionalURL to which refund status change webhooks will be sent.

paymentSubmittedAmount

ParameterTypeRequiredDescription
valueNumberRequiredRefund amount value in the original submitted currency.
currencyStringRequiredRefund currency in ISO 4217 alpha-3 format.
Must match the original submitted currency.

paymentAuthAmount

ParameterTypeRequiredDescription
valueNumberRequiredRefund amount value in the authorised or settlement currency.
currencyStringRequiredRefund currency in ISO 4217 alpha-3 format.
Must match the original authorised or settlement currency.

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


Webhooks

๐Ÿ”—

More about Payment Webhooks on the dedicated page

You will receive the webhooks on each status change of any transaction you created.


Test Data

Our system allows emulating different test cases in the sandbox environment. To simulate specific scenarios and receive different results, use the intent.description parameter.

Caseintent.description Value
FRICTIONLESS_SUCCESStcard_frictionless_success
FRICTIONLESS_CAPTURE_FAILtcard_frictionless_capture_fail
FRICTIONLESS_CANCEL_SUCCESStcard_frictionless_cancel_success
FRICTIONLESS_CANCEL_FAILtcard_frictionless_cancel_fail
FRICTIONLESS_AUTH_EXPIREDtcard_frictionless_auth_expired
FRICTIONLESS_DECLINEtcard_frictionless_decline
FRICTIONLESS_ERRORtcard_frictionless_error

Caseintent.description Value
CHALLENGE_SUCCESStcard_challenge_success
CHALLENGE_CAPTURE_FAILtcard_challenge_capture_fail
CHALLENGE_CANCEL_SUCCESStcard_challenge_cancel_success
CHALLENGE_CANCEL_FAILtcard_challenge_cancel_fail
CHALLENGE_AUTH_EXPIREDtcard_challenge_auth_expired
CHALLENGE_DECLINEtcard_challenge_decline
CHALLENGE_EXPIREDtcard_challenge_expired
CHALLENGE_ERRORtcard_challenge_error

Finalisation Rules

Case

Applicable for

Final Status

How Errors work

  1. FRICTIONLESS_ERROR("tcard_frictionless_error"),
  2. CHALLENGE_ERROR("tcard_challenge_error")

You will get
ERROR status immediately

How Declines work

  1. FRICTIONLESS_DECLINE("tcard_frictionless_decline"),
  2. CHALLENGE_DECLINE("tcard_challenge_decline"),
  3. CHALLENGE_EXPIRED("tcard_challenge_expired"),

You will get
DECLINED status
in 5 sec

How Cancellations work

  1. FRICTIONLESS_AUTH_EXPIRED("tcard_frictionless_auth_expired"),
  2. CHALLENGE_AUTH_EXPIRED("tcard_challenge_auth_expired"),

You will get
CANCELLED status
in 5 sec