📘
"paymentMethodName": "BankCardRU"

Payment Method Features

Payment Method	BankCardRU
Country	Russia
Processing Currencies	RUS
Payments	Yes
-- Min per transaction amount	Vary, depends on your contract
-- Max per transaction amount	Vary, depends on your contract
Refunds	Full & Partial
-- Full Refund	Yes
-- Partial Refund	Yes
-- Multiple Partial Refunds	Yes
Chargebacks	No

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

Our API will provide you with all the necessary information to execute on of the following scenarios:

Name	Steps
Funds Authorisation without 3DS	You send an Intent creation request via the API, including a Payment transaction. Our platform validates the incoming data and checks with the issuing bank whether 3DS verification is required. [3DS verification is not required] Our platform attempts to authorise the funds immediately. Our platform returns the authorisation result (success or failure) in the synchronous response to the Intent creation request.
Funds Authorisation with 3DS	You send an Intent creation request via the API, including a Payment transaction. Our platform validates the incoming data and checks with the issuing bank whether 3DS verification is required. [3DS verification is required] Our platform prepares a redirect URL to handle the 3DS authentication flow (both 3DS v1 and v2) You open the redirect URL in the payer’s browser or in-app web view, initiating the 3DS authentication. The payer completes (or fails) the 3DS authentication with the issuing bank. Our platform processes the 3DS result and attempts to authorise the funds. Our platform notifies you of the final payment status via a webhook (success or failure).
Manual Capture / Cancellation	Payment transaction must be* in status "AUTHORIZED", to initiate this scenario* You send a payment status update request, setting the payment status to CAPTURED or CANCELLED. Our platform validates the request and returns a synchronous acceptance response (accepted or rejected). Our platform initiates the corresponding operation with the issuing bank / processor. Our platform updates the payment status to: CAPTURED / CANCELLED or DECLINED. Our platform sends a webhook notification with the latest payment status.
Automatic Capture / Cancellation	Payment transaction must be* in status "AUTHORIZED", to initiate this scenario* An automatic trigger initiates a payment status update to CAPTURED or CANCELLED when a predefined timer expires. The automatic trigger is configured in advance by our integration team, based on your request and the agreed timer. Our platform validates the update and initiates the corresponding operation with the issuing bank / processor. Our platform updates the payment status to: CAPTURED / CANCELLED or DECLINED. Our platform sends a webhook notification with the latest payment status.
Refund	You send a Refund creation request via the dedicated request, specifying the payment identifier and the refund amount (full or partial). Our platform validates the request and returns a synchronous acceptance response (accepted or rejected). A separate refund transaction is created, while the original payment remains in CAPTURED status. Upon acceptance, our platform initiates the refund operation with the issuing bank / processor. Our platform updates the refund status to: REFUNDED or DECLINED Our platform sends a callback / webhook notification with the latest refund status.

List of used API Requests:

Request	Endpoint	Description
Create Intent	`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.
Capture Payment	`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.
Cancel Payment	`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.
Create Refund	`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.

Create Intent Request

Intent Creation - Request

📘
Intent Creation – Request
We use one unified Intent creation request for all supported payment methods.
The overall structure is the same, but some fields change depending on the payment method.

payments[].paymentInstrument.paymentMethodName tells the platform which payment method to use.

payments[].paymentInstrument.incomingDetails contains payment method–specific data needed to start the payment (for example, card details, wallet numbers, or QR parameters).

The required fields depend on the selected method, so this section must be completed carefully.

Use the following API method to create an intent: POST /processing/api/v1/intents.
When creating the intent, complete the Payment object.
Most fields are common across all payment methods and are thoroughly described in the API Reference section.
Method-specific parameters ( please make sure you provided them correctly):
- "paymentMethodName": "BankCardRU" ← always ”BankCardRU”
- "incomingDetails":must contain at lease the following information: Card Number, Expiry Month, Expiry Year
Ensure these all the required fields are completed accurately so that we can process your request correctly.

Request Example

{
  "clientReferenceId": "1234",
  "payments": [
    {
      "paymentInstrument": {
        "paymentMethodName": "SberPay",
        "incomingDetails": {
          "number": "4111111111111111",
          "expiryMonth": "12",
          "expiryYear": "2028",
          "cvv": "123",
          "holderName": "JOHN DOE",
          "successUrl": "https://merchant.example.com/payment/success",
          "failureUrl": "https://merchant.example.com/payment/failure"
        }
      },
      "description": "Purchase description",
      "webhookUrl": "webhookUrl",
      "submittedAmount": {
        "value": 100.05,
        "currency": "RUB"
      },
      "authCurrencyCode": "RUB"
    }
  ]
}

Fileds Description

`Field Path`	Type	Required	Description
`clientReferenceId`	String	`Required`
`payments`	Array_of_objects	`Required`
`payments[].``payer`	Object	`Optional`
`payments[].``paymentInstrument`	Object	`Required`
`payments[].paymentInstrument.``paymentMethodName`		`Required`	Always "BankCardRU" for this method
`payments[].paymentInstrument.``incomingDetails`	Object	`Required`	Configuration details that are required for the selected Payment Method
`payments[].paymentInstrument.incomingDetails.``number`	String	`Required`	Card number of the payer
`payments[].paymentInstrument.incomingDetails.``expiryMonth`	String	`Required`	Card expiration month (MM)
`payments[].paymentInstrument.incomingDetails.``expiryYear`	String	`Required`	Card expiration year (YYYY)
`payments[].paymentInstrument.incomingDetails.``cvv`	String	`Optional`	Card security code (CVV/CVC)
`payments[].paymentInstrument.incomingDetails.``holderName`	String	`Optional`	Name of the cardholder as printed on the card
`payments[].paymentInstrument.incomingDetails.``successUrl`	String	`Optional`	URL to which the payer is redirected after a successful payment attempt
`payments[].paymentInstrument.incomingDetails.``failureUrl`	String	`Optional`	URL to which the payer is redirected after a failed or cancelled payment attempt
`payments[].``submittedAmount`	Object	`Required`
`payments[].submittedAmount.``value`	Number	`Required`
`payments[].submittedAmount.``currency`	String	`Required`
`payments[].``authCurrencyCode`	String	`Required`
`payments[].``webhookUrl`	String	`Required`
`description`	String	`Optional`

Intent Creation - Response

📘
Intent Creation - Response
The Intent creation response is mostly consistent across all payment methods.
Common fields describe the Intent, Payment, and the current transaction status.
When required, the response includes method-specific data in:

payments[].additionalData – information the payer needs to complete the payment, such as a redirect URL, payment link, or QR data.

This allows the platform to support different payment flows while keeping the API response structure consistent.

The response might vary depending on the necessity of 3DS verification flow

3ds is not required (Frictionless) - No additional 3DS-specific parameters are returned. The platform attempts to authorise the funds immediately and returns the authorisation status in the response.
3DS is required (Challenge) - a 3DS-specific parameter is returned in payments.additionalData, containing a field url - redirect URL where the payer must be sent to complete the 3DS challenge.

Response Examples

{
  "intentId": "232510340021612544",
  "payments": [
    {
      "id": "232510340646563840",
      "submittedAmount": {
        "value": 100.05,
        "currency": "RUB"
      },
      "authAmount": {
	      "value": 100.05,
        "currency": "RUB"
      },
      "paymentInstrument": {
        "id": "PI204264628196626432",
        "paymentMethodId": "PM199507277233246209",
        "paymentMethodName": "BankCardRU"
      },
      "status": "AUTHORIZED"
    }
  ],
  "disbursements": [],
  "clientReferenceIntentId": "123456789",
  "paymentCreationErrors": [],
  "disbursementCreationErrors": [],
  "intentStatus": "IN_PROGRESS"
}

{
  "intentId": "232510340021612544",
  "payments": [
    {
      "id": "232510340646563840",
      "submittedAmount": {
        "value": 100.05,
        "currency": "RUB"
      },
      "authAmount": {
	      "value": 100.05,
        "currency": "RUB"
      },
      "paymentInstrument": {
        "id": "PI204264628196626432",
        "paymentMethodId": "PM199507277233246209",
        "paymentMethodName": "BankCardRU"
      },
      "status": "AUTHORIZATION_REQUESTED",
      "additionalData": {
        "url": "string",
      }
    }
  ],
  "disbursements": [],
  "clientReferenceIntentId": "123456789",
  "paymentCreationErrors": [],
  "disbursementCreationErrors": [],
  "intentStatus": "IN_PROGRESS"
}

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 inside existing Intent 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"
}

Field	Type	Required	Description
paymentId	int64	Yes	Identifier of the original payment transaction to which this refund applies. Use the paymentId returned during payment / intent creation.
partial	boolean	Optional	Indicates whether the refund is partial or full. true – partial refund; you must specify the refund amount using `paymentSubmittedAmount` or `paymentAuthAmount`. false – full refund; the full available amount will be refunded. If omitted, the platform assumes a full refund.
paymentSubmittedAmount OR paymentAuthAmount	object	Optional	Refund amount definition. Exactly one of these objects must be provided when `partial = true`. paymentSubmittedAmount defines the amount in the original (submitted) currency. paymentAuthAmount defines the amount in the authorised / settlement currency. The refund is calculated using the same FX rate as the original payment.
-- value	number	Optional	Refund amount value. Required when the parent amount object is provided.
-- currency	string	Optional	Currency of the refund amount. If the original payment involved FX, you may specify either the submitted currency or the authorised (settlement) currency. The historical FX rate from the original payment is always applied.
reason	string	Optional	Free-form reason for the refund. Provided for informational and audit purposes only.
webhookUrl	string	Optional	URL that will receive webhook notifications about the refund status.

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.

SBP Payment Test flow

Download in high resolution

FRICTIONLESS FLOW (FF) CASES - No 3DS

List of Test Scenarios

No	Case	intent.description	final paymentStatus
FF_1	Successful Authorization & Capture (Manual or automatic capture)	--	CAPTURED
FF_2	Successful Authorization & Cancellation (Manual or automatic cancellation)	--	CANCELLED
FF_3	Declined authorisation	No3dsFailedAuthorization	DECLINED
FF_4	Successful Authorisation & Unsuccessful Capture (Manual or automatic capture)	No3dsFailedCaptureOrCancellation	DECLINED
FF_5	Successful Authorisation & Unsuccessful Cancellation (Manual or automatic cancellation)	No3dsFailedCaptureOrCancellation	AUTHORIZED
FF_6	Expired authorisation	No3dsExpiredAuthorization	CANCELLED

Frictionless Step-by-Step Scenario Description

No	Case	Steps
FF_1	Successful Authorization & Capture (Manual or automatic capture)	You send a request to create a new Intent. You receive a successful response confirming the Intent and Payment creation, with payment status = AUTHORIZED You receive a webhook notifying you that the payment status has changed into AUTHORIZED. You send a capture request for the authorised payment (or just wait if the auto-capture was configured) You receive a successful response You receive a webhook notifying you that the payment status has changed into CAPTURED
FF_2	Successful Authorization & Cancellation (Manual or automatic cancellation)	You send a request to create a new Intent. You receive a successful response confirming the Intent and Payment creation, with payment status = AUTHORIZED You receive a webhook notifying you that the payment status has changed into AUTHORIZED. You send a cancellation request for the authorised payment (or just wait if the auto-cancellation was configured) You receive a successful response You receive a webhook notifying you that the payment status has changed into CANCELLED
FF_3	Declined authorisation	You send a request to create a new Intent. You receive a successful response confirming the Intent and Payment creation Our platform emulates a unsuccessful payment completion by the payer. You receive a webhook notifying you that the payment status has changed into DECLINED.
FF_4	Successful Authorisation & Unsuccessful Capture (Manual or automatic capture)	You send a request to create a new Intent. You receive a successful response confirming the Intent and Payment creation, with payment status = AUTHORIZED You receive a webhook notifying you that the payment status has changed into AUTHORIZED. You send a capture request for the authorised payment (or just wait if the auto-capture was configured) You receive an unsuccessful response You receive a webhook notifying you that the payment status has changed into DECLINED
FF_5	Successful Authorisation & Unsuccessful Cancellation (Manual or automatic capture)	You send a request to create a new Intent. You receive a successful response confirming the Intent and Payment creation, with payment status = AUTHORIZED You receive a webhook notifying you that the payment status has changed into AUTHORIZED. You send a cancellation request for the authorised payment (or just wait if the auto-cancellation was configured) You receive an unsuccessful response Status won't change, not webhooks will be sent
FF_6	Expired authorisation	You send a request to create a new Intent. You receive a successful response confirming the Intent and Payment creation, with payment status = AUTHORIZED You receive a webhook notifying you that the payment status has changed into AUTHORIZED. Our platform emulates a situation that the authorisation time has expired. The system waits for 5 seconds. You receive a webhook notifying you that the payment status has changed into DECLINED.

CHALLENGE FLOW (CF) CASES - with 3DS

List of Test Scenarios

No	Case	intent.description	final paymentStatus
CF_1	Successful Authorization & Capture (Manual or automatic capture)	3dsSuccessfulCaptureOrCancellation	CAPTURED
CF_2	Successful Authorization & Cancellation (Manual or automatic cancellation)	3dsSuccessfulCaptureOrCancellation	CANCELLED
CF_3	Declined authorisation	3dsFailedAuthorization	DECLINED
CF_4		3dsExpiredLink
CF_5	Successful Authorisation & Unsuccessful Capture (Manual or automatic capture)	3dsFailedCaptureOrCancellation	DECLINED
CF_6	Successful Authorisation & Unsuccessful Cancellation (Manual or automatic cancellation)	3dsFailedCaptureOrCancellation	AUTHORIZED
CF_7	Expired authorisation	3dsExpiredAuthorization	CANCELLED

Challenge Step-by-Step Scenario Description

No	Case	Steps
CF_1	Successful Authorization & Capture (Manual or automatic capture)	You send a request to create a new Intent. You receive a successful response confirming the Intent and Payment creation, with 3ds challenge link & payment status = AUTHORIZATION_REQUESTED You receive a webhook notifying you that the payment status has changed into AUTHORIZATION_REQUESTED. Platform emulates the challenge flow is conducted by a payer You receive a webhook notifying you that the payment status has changed into AUTHORIZED. You send a capture request for the authorised payment (or just wait if the auto-capture was configured) You receive a successful response You receive a webhook notifying you that the payment status has changed into CAPTURED
FF_2	Successful Authorization & Cancellation (Manual or automatic cancellation)	You send a request to create a new Intent. You receive a successful response confirming the Intent and Payment creation, with 3ds challenge link & payment status = AUTHORIZATION_REQUESTED You receive a webhook notifying you that the payment status has changed into AUTHORIZATION_REQUESTED. Platform emulates the challenge flow is conducted by a payer You receive a webhook notifying you that the payment status has changed into AUTHORIZED. You send a cancellation request for the authorised payment (or just wait if the auto-cancellation was configured) You receive a successful response You receive a webhook notifying you that the payment status has changed into CANCELLED
FF_3	Declined authorisation	You send a request to create a new Intent. You receive a successful response confirming the Intent and Payment creation, with 3ds challenge link & payment status = AUTHORIZATION_REQUESTED You receive a webhook notifying you that the payment status has changed into AUTHORIZATION_REQUESTED. Our platform emulates an unsuccessful challenge completion by the payer. You receive a webhook notifying you that the payment status has changed into DECLINED.
FF_4	Successful Authorisation & Unsuccessful Capture (Manual or automatic capture)	You send a request to create a new Intent. You receive a successful response confirming the Intent and Payment creation, with 3ds challenge link & payment status = AUTHORIZATION_REQUESTED You receive a webhook notifying you that the payment status has changed into AUTHORIZATION_REQUESTED. Platform emulates the challenge flow is conducted by a payer You receive a webhook notifying you that the payment status has changed into AUTHORIZED. You send a capture request for the authorised payment (or just wait if the auto-capture was configured) You receive an unsuccessful response You receive a webhook notifying you that the payment status has changed into DECLINED
FF_5	Successful Authorisation & Unsuccessful Cancellation (Manual or automatic capture)	You send a request to create a new Intent. You receive a successful response confirming the Intent and Payment creation, with 3ds challenge link & payment status = AUTHORIZATION_REQUESTED You receive a webhook notifying you that the payment status has changed into AUTHORIZATION_REQUESTED. Platform emulates the challenge flow is conducted by a payer You receive a webhook notifying you that the payment status has changed into AUTHORIZED. You send a cancellation request for the authorised payment (or just wait if the auto-cancellation was configured) You receive an unsuccessful response Status won't change, not webhooks will be sent
FF_6	Expired authorisation	You send a request to create a new Intent. You receive a successful response confirming the Intent and Payment creation, with 3ds challenge link & payment status = AUTHORIZATION_REQUESTED You receive a webhook notifying you that the payment status has changed into AUTHORIZATION_REQUESTED. Our platform emulates a situation that the authorisation time has expired. The system waits for 5 seconds. You receive a webhook notifying you that the payment status has changed into DECLINED.