Инструменты страницы



Recurrent payments and autopayments by binding

Terms and definitions

Initial payment – payment with additional parameters, on the basis of which recurrent payments and auto payments are created.

Recurring payment, auto payment – debiting funds from the payer's bank card account, which does not require the payer's confirmation.

To enable the functionality of both types of payments, the merchant must have certain permissions.

Description of the functionality of recurrent and auto payments by binding

To connect such payments, the Client needs to make an initial payment using a bank card, which will later be used to debit funds.

In the scenario of auto payments, payment occurs through the method paymentOrderBinding and consists of two series of requests:

  • initial request;
  • request for auto payment.

In the scenario of recurring payments, payment occurs through the method recurrentPayment and consists of two series of requests:

  • initial request;
  • request for making a recurring payment.

For recurring payments via SberPay, only one-phase payment can be used. At the same time, for ordinary bindings, a two-phase payment is possible.

Scenario of executing an initial payment

1. The user selects a product or service on the merchant's resource and chooses a payment method with a bank card.
2.

An order registration request is sent to the payment gateway with the obligatory transfer of the Client's identifier in the store's system. The recurring payment parameters are passed in the additional parameters block, params.

If the request contains only one parameter or at least one parameter does not match the format, the request will fail.

  • recurringFrequency – the period of recurrent payments in days (an integer from 1 to 28).
  • recurringExpiry – the expiration date for recurrent payments (in the format YYYYMMDD).


Requests for order registration for one-phase and two-phase payments:

3. In response, the payment gateway returns a unique order ID in the payment system and the URL of the payment form.
4. The store redirects the Client to the payment form, where the Client chooses to pay by means of SBOL.
5. The client makes a payment within SBOL.
6. After the payment is carried out, the Payment Gateway redirects the Customer to the return URL (the return URL that is passed by the Store in request for order registration).
7.

The merchant requests from payment gateway the order payment status by passing a unique order identifier that was received upon order registration in orderId parameter:

8. As a result of the successful execution of the initial payment, a bindingId binding will be created in the payment gateway, i.e., details of the card used for payment will be saved and linked to the Client's identifier.

Scenario of executing an auto-payment

1.

An order registration request is sent to the payment gateway with the obligatory transfer of the Client's identifier in the store's system. Auto payment option, AUTO_PAYMENT, passed in features block.

Requests for order registration:

2. In response, the payment gateway, among other things, returns a unique order identifier in the payment system
3.

In the direction of the payment gateway, a request for payment by binding is sent:

4. The Payment Gateway debits money from the Client's account.
5.

The merchant requests from payment gateway the order payment status by passing a unique order identifier that was received upon order registration in orderId parameter:

6. The payment gateway returns the payment status.

Recurring payment scenario

1.

An order registration request is sent to the payment gateway recurrentPayment, in which it is mandatory to pass the Client's identifier in the store system, as well as the payment amount.

2. The payment gateway sends a request to the bank's services, which deduct money from the payer's account.
3. The payment gateway returns the payment status.