Ctrl Prev

History of changes to the Protocols

25 August 2017

  • We added description of 428 error (refund is forbidden for this payment method).
  • You can only transmit email address in HTTP and Email payment form in the cps_email parameter. Otherwise the request will return error.
  • The identification parameter is only returned in response to Transfer crediting when the transfer is addressed to a Yandex.Money e-wallet.

14 August 2017

28 July 2017

We added an explanation for sending details for the receipt when putting an operation on hold. Details for the receipt are transmitted to your online sales register on the first stage: if the authorization was successful. If the amount is adjusted upon the payment confirmation, a return receipt is transmitted, and then a receipt for this new operation is transmitted. If the payment is cancelled on the second stage, a return receipt is transmitted.

11 June 2017

  • We added the environment parameter to the listOrders method, which allows for distinguishing test and real operations.
  • If you transmit parameters for the receipt in the returnPayment method and cannot receive a precise amount (one kopeck less or one kopeck bigger), you need to transmit the amount that is one kopeck bigger.
  • Clarified: the time of a payment in the registers of accepted transfers is the time when this operation was created in Yandex.Checkout.

5 June 2017

We added explanations to the description of parameters for creating the receipt. We also changed examples.

1 June 2017

We added an option of transmitting fiscal data to online sales register adopted by the store. Online sales register transmits these data to the Operator of Fiscal Data; these data is used for creating a receipt for the buyer (this protocol does not include creating a receipt for the buyer).

All changes are gathered in a separate section: Changes in the protocol for working under Federal Law No.54 (54-FZ)

We added the following sections:

The amendments affect the following pages:

12 May 2017

Updated information on:

  • you can only provide deferred payments for paymentType=AC (payment with a bank card)
  • when paying via KupiVkredit ( paymentType =KV), all parameters with the qualifier goods_ are optional. The parameter seller_id is not transmitted. (see Payment form)
  • we changed examples in the section Payment by QR Code.

6 April 2017

Updated information on:

  • customerNumber and orderNumber parameters in all normalizedString cases
  • when paying through KupiVkredit ( paymentType =KV) passing category_code_N and goods_description_N is not mandatory (see Payment form).

14 March 2017

Changed:

  • The qppi.ru (QP) payment method no longer works (service closed)
  • the Yandex.Checkout activation method CMS Module is now called the Payment module.

28 February 2017

Updated information on:

  • The listReturns method should simultaneously specify either the invoiceId and shopID parameters or the from, till and shopID parameters.
  • The reason for the request (planned replacement) was added to the SSL certificate request.
  • If you can do a return on a payment order, then you can also do it automatically.
  • In the createInvoice request, the offline value is passed into the payMethod parameter by default.
  • For payments to bank accounts or bank cards, the recipient's passport information is checked immediately following the makeDeposition request.

26 January 2017

Updated information on:

  • For payments to bank accounts, the recipient's birth date must be indicated (pdr_birthDate).
  • For deferred payment using a bank card, the merchant gets the paymentAviso notification after money is successfully reserved on the payer's card.
  • The processing of a repeat deposit request (makeDeposition) with the same operation ID (clientOrderId) depends on what the values of the mandatory parameters are (clientOrderId, dstAccount and amount). If the values of these parameters in the source and repeat request are the same, then Yandex.Checkout will return the result from processing the request that was sent earlier. If the values differ, then the request will be declined.

14 December 2016

Added documentation for:

  • Requesting a QR code. You can send a request with payment form data for paying for an order, get a response with a QR code in .svg format, and display it for the user (or print it and stick it on the product package).
  • Error codes that are returned in response to the createInvoice request (614 and 615).

Updated information on:

21 October 2016

Updated information on:

20 September 2016

Added documentation for:

14 September 2016

Added a description of the new format for the report on successful payments.

Minor corrections.

4 August 2016

Added a description of paying with a QR code.

21 June 2016

Added documentation for:

17 May 2016

Added documentation for:

29 April 2016

Added documentation for:

12 April 2016

Updated:

2 March 2016

Added documentation for:

Updated:

  • The payment methods section has new information about the invoice expiration when paying via external payment systems.
  • Fixed several minor discrepancies.

25 December 2015

Updated:

23 November 2015

Updated:

  • Details of working with repeatCardPayment (additional parameters for the payment form and the checkOrder and paymentAviso requests).
  • Description of working with test Wallets when testing payment.

1 October 2015

Updated:

1 September 2015

Added documentation for:

Updated: