📓
Please use the following paymentMethodName value when creating the Intent and when completing the payment object.
"paymentMethodName": "MOBILE_MONEY_RU"

📘
DCB (Direct Carrier Billing) is a carrier-billed payment method for Russia. You create an Intent with the payer's phone number and receive no QR or redirect URL — there is nothing to display. The mobile operator sends the payer an SMS, the payer confirms the charge by replying to it, and the amount is deducted from their mobile account balance. We notify you of the final status via a webhook.

Payment Method Features

Feature	Value
Country	Russia
Processing Currencies	RUB
Payments	Yes
*-- Min per transaction amount*	Vary, depends on your contract
*-- Max per transaction amount*	Vary, depends on your contract
Refunds	Yes (Full amount & MTS subscribers only)
Chargebacks	No

Workflow: Payment

Download in high resolution

Possible Payment Scenarios

📘
DCB has a single integration flow: you create an Intent with the payer's phone number, then wait for the final status via webhook. There is nothing to render — the payer confirms the charge by replying to an SMS from their mobile network operator. The payment resolves to one of two terminal outcomes — Successful Payment (CAPTURED) or Declined Payment (DECLINED).

Name	Steps
Operator Check (optional)	[1.1] The payer enters their phone number on your side. [1.2] You send an operator lookup request (`POST /api/v1/mobile-operators/searches`). [1.3–1.4] Our platform requests the operator details for that number from the mobile network. [1.5] Our platform returns the operator details in the synchronous response. [1.6] You display the operator name and whether mobile commerce is available for this number.
Payment Initiation	[2.1] The payer initiates a mobile commerce payment on your side. [2.2] You send an Intent creation request (`POST /processing/api/v1/intents`), including a Payment transaction for DCB and the payer's phone number. [2.3] Our platform validates the incoming data, creates the `Intent` (`CREATED`) and a separate `Payment` (`ACCEPTED`). [2.4–2.5] Our platform submits the order to the payer's mobile network operator and receives an acknowledgement. [2.6] Our platform changes the payment status to `AUTHORIZATION_REQUESTED`. [2.7] Our platform returns the payment creation status in the synchronous response. [2.8] The operator sends the payer an SMS asking to confirm the charge.
Successful Payment	[3.1] The payer replies to the SMS with the confirmation code. [3.2] The operator sends the final payment status to our platform. [3.3: SP] Our platform changes the payment status to `CAPTURED` and finalises the `Intent`. [3.4: SP] Our platform sends a webhook with the latest status update.
Declined Payment	[3.1] The payer does not reply to the SMS, replies incorrectly, or the operator rejects the charge — for example, due to insufficient balance on the mobile account. [3.2] The operator sends the final payment status to our platform. [3.3: DP] Our platform changes the payment status to `DECLINED` and finalises the `Intent`. [3.4: DP] Our platform sends a webhook with the latest status update.

⚠️
Confirmation happens outside your interface
The payer confirms the charge with their mobile network operator, so there is no intermediate state you can poll between Intent creation and the webhook. Confirmation is expected within 30 minutes. After a DECLINED payment, a retry requires a new Intent — repeating the original request will not trigger a new SMS.

⚠️
Declines are not itemised
The operator does not distinguish between a payment the payer refused, a payment that failed for lack of funds, and a payment that expired without a reply. All of them arrive as a single DECLINED status with no specific reason.

List of used API Requests

Request	Endpoint	Description
Operator Check (optional)	`POST /api/v1/mobile-operators/searches`	• Returns the mobile network operator for a phone number. • Use it before creating the `Intent` to show the payer their operator and to avoid initiating a payment that cannot be processed.
Intent Creation	`POST /processing/api/v1/intents`	• Creates a new `Intent` with a MobileMoneyRU `Payment` transaction. • The platform validates the request, creates the internal payment record, and submits the order to the payer's mobile network operator. • The synchronous response contains no QR and no redirect URL — there is nothing to render.
Payment Status	`GET /processing/api/v1/intents/{id}`	• Returns the current state of the `Intent` and its payments. • Use it as a fallback if a webhook was not delivered — not as a substitute for webhooks.

🔗
The final transaction status (CAPTURED or DECLINED) is always delivered asynchronously via a webhook. The payer confirms the charge by replying to an SMS from their mobile network operator, which is expected within 30 minutes. More on the dedicated page.

Intent Creation Request/Response

📓
Request specifics

Endpoint: POST /processing/api/v1/intents

Purpose: Creates an Intent and a Payment for the MobileMoneyRU 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 MOBILE_MONEY_RU

authCurrencyCode must be set to RUB

incomingDetails.payerPhoneNumber must contain the payer's mobile number — the account the payment is charged to

Intent Request: Example

    {
      "clientReferenceId": "070826-1",
      "useCheckoutForm": false,
      "payments": [
        {
          "payer": {
            "merchantPayerReference": "user-42"
          },
          "paymentInstrument": {
            "paymentMethodName": "MOBILE_MONEY_RU",
            "incomingDetails": {
              "payerPhoneNumber": "9105615567"
            }
          },
          "submittedAmount": {
            "value": 200.00,
            "currency": "RUB"
          },
          "authCurrencyCode": "RUB",
          "description": "Order 070826-1",
          "webhookUrl": "https://merchant.example.com/webhooks/payments"
        }
      ]
    }

Intent Request: Fields Description

Top-Level Request Parameters

Parameter	Type	Required	Description
`clientReferenceId`	String	`Required`	Order number in the merchant system.
`useCheckoutForm`	Boolean	`Required`	Whether the intent uses a hosted checkout form. Always `false` for H2H.
`payments`	Array of Objects	`Required`	List of payment objects to be created within the `Intent`.

payment

Parameter	Type	Required	Description
`payer`	Object	`Required`	Payer details. The object is required, but all fields inside it are optional.
`paymentInstrument`	Object	`Required`	Payment method and payment instrument details used to process the payment.
`submittedAmount`	Object	`Required`	Amount and currency submitted for the payment.
`authCurrencyCode`	String	`Required`	Authorisation currency code to be used for the payment. Always `RUB` for this method. If FX conversion is not required, it should match `submittedAmount.currency`.
`description`	String	`Optional`	Payment description.
`webhookUrl`	String	`Required`	URL to which payment status change webhooks will be sent. This method has no synchronous outcome, so the webhook is the only source of the final status.

payer

Parameter	Type	Required	Description
`merchantPayerReference`	String	`Optional`	Your own identifier of the payer. Returned as-is in the response and in webhooks.

paymentInstrument

Parameter	Type	Required	Description
`paymentMethodName`	String	`Required`	Payment method name. For this scenario, use `MOBILE_MONEY_RU`.
`incomingDetails`	Object	`Required`	Payment method-specific data required to initiate the payment.

incomingDetails

Parameter	Type	Required	Description
`payerPhoneNumber`	String	`Required`	Payer's mobile number — the mobile account the payment is charged to. Russian national format without the country code, 10 digits: `9105615567`. Prefixes `+7`, `8` and `7` are also accepted; formatting characters (spaces, brackets, hyphens) are stripped.

submittedAmount

Parameter	Type	Required	Description
`value`	Number	`Required`	Submitted order amount in major units (roubles), e.g. `200.00`. May differ from the authorised amount if FX conversion is applied.
`currency`	String	`Required`	Submitted order currency in ISO 4217 alpha-3 format. May differ from the authorised currency if FX conversion is applied.

📓
Response specifics

The Intent creation response is generally consistent across all supported payment methods.

Common fields describe the Intent, the Payment, and the current transaction status.

This method returns no additionalData. There is no QR and no redirect URL — nothing to render. The mobile network operator sends the payer an SMS, and the final status arrives via webhook.

The payer's number is echoed back in payments[].paymentInstrument.storedDetails.payerPhoneNumber.

Intent Response: Example

    {
      "intentId": "344115072451633152",
      "payments": [
        {
          "id": "344115072812343296",
          "paymentMethodId": "PM199507277233246209",
          "paymentMethodName": "MOBILE_MONEY_RU",
          "submittedAmount": {
            "value": 200.00,
            "currency": "RUB"
          },
          "authAmount": {
            "value": 200.00,
            "currency": "RUB"
          },
          "payer": {
            "id": "PR344115072787177000",
            "merchantPayerReference": "user-42"
          },
          "paymentInstrument": {
            "id": "344115072787177472",
            "paymentMethodId": "PM199507277233246209",
            "paymentMethodName": "MOBILE_MONEY_RU",
            "storedDetails": {
              "payerPhoneNumber": "9105615567"
            }
          },
          "createdAt": 1786110626.692046000,
          "status": "AUTHORIZATION_REQUESTED",
          "clientReferenceId": "070826-1"
        }
      ],
      "disbursements": [],
      "clientReferenceIntentId": "070826-1",
      "paymentCreationErrors": [],
      "disbursementCreationErrors": [],
      "intentStatus": "CREATED"
    }

Response Description

Top-Level Response Parameters

Parameter	Type	Required	Description
`intentId`	String	`Required`	Unique identifier of the `Intent` in our platform.
`payments`	Array of Objects	`Required`	List of `Payment` objects created within the `Intent`.
`disbursements`	Array	`Optional`	List of disbursement objects created within the `Intent`. Empty for this method.
`clientReferenceIntentId`	String	`Required`	Order number in the merchant system. Returned from the request.
`paymentCreationErrors`	Array	`Required`	List of payment creation errors, if any. Empty if no errors occurred.
`disbursementCreationErrors`	Array	`Required`	List of disbursement creation errors, if any. Empty if no errors occurred.
`intentStatus`	String	`Required`	Current `Intent` status. See the dedicated section of this API guide for possible values and the status model.

payment

Parameter	Type	Required	Description
`id`	String	`Required`	Unique identifier of the `Payment` in our platform.
`paymentMethodId`	String	`Optional`	Unique identifier of the payment method in our platform.
`paymentMethodName`	String	`Optional`	Payment method name. Returned from the request.
`submittedAmount`	Object	`Required`	Submitted payment amount and currency. Returned from the request.
`authAmount`	Object	`Required`	Authorised amount and currency used for the payment.
`payer`	Object	`Optional`	Payer details stored on the payment.
`paymentInstrument`	Object	`Required`	Payment method information associated with the payment.
`createdAt`	Number	`Optional`	Payment creation time, Unix epoch seconds with a fractional part.
`status`	String	`Required`	Current payment status. See the dedicated section of this API guide for possible values and the status model.
`clientReferenceId`	String	`Optional`	Order number in the merchant system. Returned from the request.

submittedAmount

Parameter	Type	Required	Description
`value`	Number	`Required`	Submitted order amount. Returned from the request. May differ from the authorised amount if FX conversion is applied.
`currency`	String	`Required`	Submitted order currency. Returned from the request. May differ from the authorised currency if FX conversion is applied.

authAmount

Parameter	Type	Required	Description
`value`	Number	`Required`	Authorised amount used for the payment. May differ from the submitted amount if FX conversion is applied.
`currency`	String	`Required`	Authorisation currency used for the payment. Always `RUB` for this method.

payer

Parameter	Type	Required	Description
`id`	String	`Optional`	Unique identifier of the payer in our platform.
`merchantPayerReference`	String	`Optional`	Your own identifier of the payer. Returned from the request.

paymentInstrument

Parameter	Type	Required	Description
`id`	String	`Optional`	Unique identifier of the payment instrument in our platform.
`paymentMethodId`	String	`Optional`	Unique identifier of the payment method in our platform.
`paymentMethodName`	String	`Optional`	Payment method name. Returned from the request.
`storedDetails`	Object	`Optional`	Stored payment instrument details. Returned when applicable.

storedDetails

Parameter	Type	Required	Description
`payerPhoneNumber`	String	`Optional`	Payer's mobile number the payment is charged to. Returned from the request.

Webhooks

🔗
More about Payment Webhooks on the dedicated page.
You will receive a webhook on each status change of any transaction you created.

After the transaction is processed and reaches its final status (CAPTURED or DECLINED), the platform notifies you of the latest status change via the webhook.
In some cases the acquirer may return extra information about the transaction. In that case we include additional data in the webhook.

Refunds

📘
Refunds are supported, with limitations

Full refunds only. A partial refund request is rejected — see below.

Same settlement day only. A refund can be requested only for a payment made within the current settlement day. Once the day is closed, the payment can no longer be refunded.

MTS subscribers only. For numbers on other operators the refund is declined by the processor.

Refund availability depends on your contract terms.

When a refund is not possible, money can still be returned to the payer using the disbursement functionality — see RU Mobile Balance Disbursements.

Workflow: Refunds

Download in high resolution

How it works

Step	What happens
1	You create a refund request via `POST /processing/api/v1/refunds`, referencing the original `paymentId`.
2	The platform validates the request. A partial refund is rejected immediately with an error.
3	The platform creates a refund transaction with status `ACCEPTED` and returns it in the synchronous response.
4	The platform submits the refund to the processor. If the processor rejects it, the status becomes `DECLINED`.
5	Once the processor accepts the request, the status becomes `REFUND_REQUESTED`. The final result arrives asynchronously.
6	On success the status becomes `REFUNDED`; on failure, `DECLINED`. You are notified of the status change via a webhook.

Refund Request/Response

📓
Request specifics

Endpoint: POST /processing/api/v1/refunds

Purpose: Creates a Refund for an existing Payment within an Intent.

For this method: partial must be false or omitted. paymentSubmittedAmount and paymentAuthAmount are not used, because the refund is always for the full amount of the original payment.

Refund Request: Example

    {
      "paymentId": 344115072812343296,
      "reason": "Customer requested a refund",
      "clientReferenceId": "070826-1-refund",
      "webhookUrl": "https://merchant.example.com/webhooks/refunds"
    }

Refund Request: Fields Description

Top-Level Request Parameters

Parameter	Type	Required	Description
`paymentId`	Integer	`Required`	Identifier of the original payment to be refunded.
`partial`	Boolean	`Optional`	Whether this is a partial refund. Defaults to `false`. Partial refunds are not supported for this method — `true` is rejected.
`reason`	String	`Optional`	Reason for the refund.
`clientReferenceId`	String	`Optional`	Your own unique reference for the refund.
`webhookUrl`	String	`Optional`	URL that will receive refund status update notifications. The final refund status is delivered only via webhook.

📓
Response specifics

The synchronous response confirms that the refund request has been accepted for processing, not that the money has been returned.

status is ACCEPTED at this point. The final status arrives via webhook.

Refund Response: Example

    {
      "id": "344115098234117632",
      "intentId": "344115072451633152",
      "paymentId": "344115072812343296",
      "refundSubmittedAmount": {
        "value": 200.00,
        "currency": "RUB"
      },
      "refundAuthAmount": {
        "value": 200.00,
        "currency": "RUB"
      },
      "reason": "Customer requested a refund",
      "status": "ACCEPTED",
      "createdAt": "2026-08-07T15:41:12.318Z",
      "clientReferenceTransactionId": "070826-1-refund"
    }

Response Description

Top-Level Response Parameters

Parameter	Type	Required	Description
`id`	String	`Required`	Unique identifier of the `Refund` in our platform.
`intentId`	String	`Required`	Identifier of the `Intent` the original payment belongs to.
`paymentId`	String	`Required`	Identifier of the refunded payment. Returned from the request.
`refundSubmittedAmount`	Object	`Required`	Submitted refund amount and currency. Always equal to the original payment.
`refundAuthAmount`	Object	`Required`	Authorised refund amount and currency.
`reason`	String	`Optional`	Reason for the refund. Returned from the request.
`status`	String	`Required`	Current refund status. See the status table below.
`createdAt`	String	`Required`	Refund creation time.
`clientReferenceTransactionId`	String	`Optional`	Your own reference for the refund. Returned from the request.

Refund Statuses

Status	Meaning
`ACCEPTED`	The refund request has been accepted by the platform and is about to be sent to the processor.
`REFUND_REQUESTED`	The processor has accepted the request. The result is not final yet.
`REFUNDED`	The funds have been returned to the payer's mobile account. Final status.
`DECLINED`	The refund was rejected — by validation, by the processor, or by the operator. Final status.

Other values of RefundStatusEnum are not used for this payment method.

⚠️
What gets rejected
A refund is declined when it is requested for a part of the amount, when the original payment was made before the current settlement day, or when the payer's number belongs to an operator other than MTS.
In all three cases the money can still be returned to the payer using the disbursement functionality — see RU Mobile Balance Disbursements.

🔗
The final refund status (REFUNDED or DECLINED) is always delivered asynchronously via a webhook. More on the dedicated page.

Testing in Sandbox

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

📘
No real SMS is sent in the sandbox. Sending the confirmation message and the payer's reply are both emulated on our side — you do not need a working phone number to run these scenarios.

MobileMoneyRU Payment Test flow

Download in high resolution

List of Supported Cases

Case	Scenario Keyword (intent.description)	Final Payment Status
Successful payment	--	CAPTURED
Payment declined	DeclinedPayment	DECLINED
Failure	PaymentCreationError	ERROR

Case "Successful payment"

Emulates a payer who confirms the charge by SMS.
Steps:

The client creates an intent via POST /processing/api/v1/intents with paymentMethodName = MOBILE_MONEY_RU, without the intent.description parameter.
A synchronous response is returned with paymentStatus = AUTHORIZATION_REQUESTED. Sending the SMS to the payer is emulated.
After approximately 5 seconds the confirmation is emulated automatically — no action is required on your side.
A callback is received with paymentStatus = CAPTURED.

RU: Mobile Money (DCB) - Payments

Payment Method Features

Workflow: Payment

Possible Payment Scenarios

List of used API Requests

Intent Creation Request/Response

Intent Request: Example

Intent Request: Fields Description

Intent Response: Example

Response Description

Webhooks

Refunds

Workflow: Refunds

How it works

Refund Request/Response

Refund Request: Example

Refund Request: Fields Description

Refund Response: Example

Response Description

Refund Statuses

Testing in Sandbox

MobileMoneyRU Payment Test flow

List of Supported Cases

Case "Successful payment"

Case "Payment declined"

Case "Failure"