YooMoney
Legal Information
General Terms and Conditions of the YooMoney Service

Annex No. 1. Electronic Document Flow Agreement

1. Compliance of this Agreement with the law

1.1. This agreement has been developed in accordance with the requirements of Federal Law No. 63-FZ "On Electronic Signatures" dated April 6, 2011 and No. 149-FZ "On Information, Information Technologies and Information Protection" dated July 27, 2006.

1.2. The notions and definitions of this Agreement are also correlated with international practices and standards for the use of electronic signatures, in particular, with X.509 PKI (Public Key Infrastructure) standard. The operation of PKI is described in RFC 1422, and the X.509 certificates format is described in RFC 5280.

2. Notions used in this Agreement

2.1. Electronic document flow (hereinafter — "EDF") is a system processing the electronic documents, in which all electronic documents are created, transmitted and stored using information and communication technologies on computers integrated into a network structure.

2.2. Electronic document (hereinafter — "ED") is a documented information presented in an electronic form, i.e. in the form suitable for a human perception using computers as well as for the transmission via information and telecommunication networks or the processing in information systems.

2.3. Electronic signature (hereinafter — ES) is information in an electronic form attached to other information in an electronic form (to the information to be signed) or otherwise associated with such information and which is used to identify the person signing the information (electronic document).

2.4. Electronic signature key (hereinafter — ES private key) is a unique sequence of symbols intended for creating the ES. Also called a private key.

2.5. Electronic signature verification key (hereinafter — ES public key) is a unique sequence of symbols uniquely associated with the signatures private key and intended to verify the authenticity of the ES (hereinafter — ES verification). Also called a public key. The content of the ES public key is contained in the certificate.

2.6. Hash is a result of a hash function that converts an input data array of a random length into a fixed-length output bit string. The hash function should not allow to get the original input array based on the hash and pick up another incoming array, the hash of which will match the hash of the first one.

2.7. Secret ES code is a secret password (no less than 20 random characters), generated by the Counterparty and used in the calculation of the cryptographic hash sum (which is used as a simple ES) or used independently as an ES.

2.8. Electronic signature verification key certificate (hereinafter — Certificate) is an electronic document or a paper-based document issued by the Certifying Center or Certifying Center’s trusted person and confirming that the ES public key belongs to the owner of the Certificate. Also called a public key certificate. The Certificate contains a serial number, information about the owner, cryptographic algorithm used, usage restrictions, ES public key and other information. The Certificate has its own ES created by the Certifying Center.

2.9. Means of electronic signature (hereinafter — ES means) are encryption (cryptographic) means used to implement at least one of the following functions: creation of the ES, verification of the ES, creation of the Electronic signature key and Electronic signature verification key.

2.10. Encryption means are hardware, software or soft- and hardware encryption (cryptographic) means used for the implementation of algorithms of the cryptographic information transformation to restrict the access to it, including the access during its storage, processing and transmission.

2.11. Creation of the ES is a result of the work of the ES mean during the ES creation which results in a sequence of fixed-length data bits after the cryptographic conversion of the electronic document into a hash, and encrypting the hash with an ES private key. The length and the names of algorithms of hashing and encryption are specified in the Certificate.

2.12. ES authenticity confirmation is a positive result of the work of the ES tool during the ES verification. The order of confirmation for each type of the ES is described in the Agreement.

2.13. Compromise of the ES private key is a violation of the confidentiality of the ES private key, when the content of the ES private key has become known to the person who is not the owner of the Certificate.

2.14. Main Contract is the Contract concluded between the Operator and the Counterparty in accordance with the General Terms and Conditions.

2.15. EDF system, the System is a common name for a set of tools that allow to perform the Electronic document flow between the Operator and the Counterparty. The EDF system includes ES tools and provides for the preparation of the ES, generation of the ES, verification of the ES, reception, transmission and processing of the signed ED using computer means of each of the parties. The System is completed by the Operator and the Counterparty on their own.

2.16. Information Exchange Protocol for Money Transfers is a protocol defined by the Operator and containing a technical description of the procedure for the exchange of information on payments between the Operator and the Counterparty.

2.17. CC (hereinafter — Certifying Center) is the Operator’s certifying center.

2.18. Payout API is the Information Exchange Protocol between the Operator and the Sender when processing Deposits.

2.19. Replenishment API is the Information Exchange Protocol between the Operator and the Bank/BPA upon the Money Transfers processing and the acceptance of cash.

3. Subject of this Agreement

3.1. The present Agreement establishes the procedure for the organization and performance of Electronic document flow using an Electronic signature between the parties for the fulfillment of the Main Contract.

3.2. The parties acknowledge the legal validity of the Electronic documents signed with the Electronic signature to be equal to the legal validity of documents on paper, signed with a handwritten signature and affixes with the parties’ seals (if required), under the following conditions:

  • the ES is created according to this Agreement;

  • the ES has been verified in accordance with this Agreement and found valid.

3.3. This Agreement provides for two types of the ES:

  • Simple ES;

  • Enhanced Unqualified ES (EUES).

3.4. Simple ES is an electronic signature which confirms that the Electronic signature has been created by a certain individual through the use of codes, passwords or other means.

3.5. EUES is an electronic signature which:

  • Has been created as a result of a cryptographic transformation of the information using the ES private key;

  • Allows to identify a person who signed the Electronic document;

  • Allows to identify the changes made to the Electronic document since its signing;

  • Is created using the Electronic signature means.

3.6. The parties identify the cases under which different types of the ES are to be used based on the Main Contract and annexes thereto. In particular, if the Secret ES codes or hashes of these Secret ES odes are used, the ES is a simple ES, and if ES cryptographic keys are used, the ES is an EUES.

3.7. The list of Electronic documents signed with the ES:

From the Operator’s side:

  • HTTP protocol: checkOrder request (simple ES);

  • HTTP protocol: paymentAviso request (simple ES or EUES depending on the integration);

  • HTTP protocol: email-notification of money transfers (EUES);

  • HTTP protocol: registers of money transfers accepted (EUES);

  • Replenishment API: answers to all requests (EUES);

  • YooMoney API: answers to GET/POST requests and notifications (EUES);

  • Payout API: register of successful payouts (EUES);

  • Payout API: answers to GET/POST requests (EUES);

  • Sberbank PI (API): simple ES or EUES depending on the integration.


From the Counterparty’s side:

  • MWS: returnPayment (EUES);

  • MWS: confirmPayment (EUES);

  • MWS: cancelPayment (EUES);

  • MWS: repeatCardPayment (EUES);

  • YooMoney API: payment, including repetitions, clearings, confirmations (simple ES);

  • YooMoney API: refunds (simple ES);

  • Merchant Profile: orders for payment refunds (simple ES);

  • Replenishment API: all requests (EUES);

  • Offer Program API: all methods (simple ES);

  • YooMoney API: payouts (simple ES);

  • YooMoney API: me (simple ES);

  • YooMoney API: self-employed;

  • YooMoney API: sbp/banks;

  • Payout API: makeDeposition (EUES);

  • Payout API: testDeposition (EUES);

  • Payout API: balance (EUES);

  • Merchant Profile: payout order (simple ES);

  • Merchant Profile: application for the conclusion of the Master Contract (simple ES).

3.8. The Parties acknowledge that:

  • the use of the ES ensures the irrevocability of the authorship of information in the ED signed;

  • the use of EUES ensures the integrity and irrevocability of the authorship of information in the ED signed.

3.9. Information protection requirements (including the cases of its transmission over the Internet) that are not related to the use of the ES are fulfilled by the parties on their own on the basis of the provisions of the Main Contract, technical documentation on the integration of the protocols used, the current legislation and (or) requirements of the internal regulatory documents of the parties, if any.

4. General provisions of the electronic document flow

4.1. The parties acknowledge that when using the EUES and simple ES in the form of a calculated Hash:

  • Making amendments to the signed ED gives a negative result of the ES verification;

  • Forging the ES is impossible without using the owner's ES private key or a Secret ES code.

4.2. The parties also acknowledge that:

  • Each party is responsible for the safety of its ES key/Secret ES code and for the actions of its personnel that uses the ES tools;

  • The ED signed by the ES comes into force the moment when this signed ED is received through the System by the receiving party and logged in the journal.

4.3. Transfer of the ED between the Parties is carried out by means of data transfer via the Internet. The connection of the parties to the Internet shall be organized by them independently and not form the subject matter of this Agreement.

4.4. Before using the EDF, the Parties exchange the necessary keys and (or) Secret ES codes. The Operator’s Certificate and/or ES public key may be placed on the Internet in the public domain. After the exchange, the Parties conduct a test exchange of the signed ED and conduct an ES check in the test ED.

4.5. The type of ES used for signing Electronic documents by the Parties is defined in Clause 3.7. hereof.

5. The order of use of the Simple ES

5.1. The parties have agreed to consider that it is enough to know the Secret ES code to generate and verify a simple ES. The parties have agreed not to inform third parties of the value of the Secret ES code, and independently take all necessary measures to ensure its confidentiality.

5.2. The algorithm of the cryptographic hash and parameters set are determined by the Operator in the Information Exchange Protocol for Money Transfers.

6. The order of use of the enhanced unqualified ES

6.1. To create and verify the EUES it’s necessary to have two keys: the ES private key and the ES public key.

6.2. In order to create the EUES, the Party uses the ES means which:

  • Forms a hash from the source Electronic document according to the certain algorithm;

  • Encrypts the received hash using the ES private key according to the certain algorithm;

  • The resulted value represents an ES and is added to the source Electronic document.

6.3. In order to verify the EUES, the Party uses the ES means which:

  • Forms a hash from the source Electronic document according to the certain algorithm;

  • Transforms the received ES using the ES public key;

  • Compares the resulted values — if they match, then the ES is considered genuine; if they do not match, then the ES is considered not verified, and the party verifying the ES must report to the sending party about it.

6.4. The parameters and cryptographic algorithms used in the formation and verification of the EUES are determined by the technical documentation and standards to which it refers, or by the ES public key certificates.

6.5. In order to protect against the counterfeiting of the ES public keys when they are transmitted between the Parties, a corresponding ES public key certificate can be created for the ES public key in the CC of the Operator. The parties use the CC to obtain the Certificates of the ES public keys. The necessity to use the Operator’s CC is determined on the basis of the Information exchange protocols used by the parties or by their agreement.

6.6. When using the Certificates, before the verification of the EUES, the Party receiving the ED must check the received Certificate:

  • The Certificate must belong to the transmitting party;

  • The Certificate must be valid at the time of the verification of the ES, in accordance with the established start and end dates of the Certificate;

  • The Certificate must not be withdrawn, or its validity must not be suspended.

6.7. When submitting answers for GET/POST requests and YooMoney API notifications, the Operator signs the Electronic document with its ES private key. The ES creation properties, verification algorithm and ES public key are specified on web page https://yoomoney.ru/i/forms/yc-api-public-keys-en.pdf

7. Operator’s CC Use Procedure

7.1. In order to receive the Certificate, the Counterparty independently generates the ES private key and the corresponding ES public key using ES means as well as the request for the PKCS No. 10 Certificate.

7.2. The Counterparty must fill the following fields in the request for a Certificate:

  • CN = Full name of the responsible officer or organization name or pseudonym;

  • E = email address;

  • OU = Name of the organization subdivision;

  • O= Organization name;

  • L = Organization location city;

  • C = Country code (for example, for Russia C = RU).

7.3. The Operator accepts the request from the Counterparty and forms the Counterparty’s Certificate on the basis of it.

7.4. Certificate parameters:

  • signature algorithm — RSA;

  • key length – 2048 bit;

  • hashing algorithm — sha256.

7.5. The hashing algorithm of the EUES formation and the Certificate’s parameters can be replaced by the parties’ agreement to more protected ones.

7.6. The Operator sends to the Counterparty the Certificate that will be used to sign the ED in the System as well as a full chain of certificates:

  • Root certificate of the CC;

  • Intermediate certificates of the CC.

7.7. The parties agreed to trust the certificates that they exchange.

7.8. The file of the Certificate is transmitted in X.509 format (Base64 or DER encoding, file format .cer) or PKCS#7 (file format .p7b) via e-mail or other pre-agreed method.

7.9. The parties print their files of Certificates on paper and then sign them by a relevant authorized person and affix with a corresponding organization’s seal (if needed), and transfer them to the other party. An example of the Certificate’s form on paper is provided at the end of this Annex.

7.10. The parties undertake to take all necessary measures to preserve the confidentiality of the ES private keys.

7.11. If the ES private key is compromised (or it is reasonably believed to be compromised), the Party must::

  • Stop the transfer of ED in the System and immediately (if it is impossible, then within 1 Working Day) notify the other Party about the fact of the compromising of its ES private key;

  • Generate a new ES private key, ES public key, and issue a new verification Certificate;

  • Transfer the file with a new Certificate to the other Party;

  • Ensure that the CC has registered the serial number of the compromised Certificate in the list of revoked Certificates and published a new list of the revoked Certificates;

  • Restore the operation of the System in cooperation with the other Party.

7.12. The encrypted Electronic documents are transmitted as follows:

  • the transmitting Party signs the Electronic document with its ES private key, encrypts the signed ED with the ES public key from the Certificate of the receiving Party and sends the encrypted signed ED.

  • the receiving Party decrypts the received document with its ES private key and checks the ES with the ES public key of the ES from the Certificate of the transmitting Party.

8. Obligations of the Parties

The Parties undertake to:

8.1. Independently install all the necessary software and hardware in the System.

8.2. Exchange the Certificates, ES public keys or Secret ES codes in accordance with the technical documentation for the protocols used for the integration.

8.3. Appoint the persons responsible for the work with the System in accordance with this Agreement.

8.4. Assign the security administrator responsible for the generation, accounting, exchange and security of keys/codes used in the System, for the protection against an unauthorized access and for the maintaining the of the System of the ES in the working condition.

8.5. Timely change the ES private keys, ES public key and the relevant Certificates (if there are any) in accordance with the applicable requirements:

  • CC's rules;

  • applicable law;

  • internal organizational and regulatory documents.


If there are no such requirements, the change is performed on a regular basis, 10 days before the Certificate expires or at least once a year for the simple ES and EUES without the use of Certificates.

8.6. Immediately inform the other Party about all cases of loss, theft, unauthorized access to the ES private key at the following addresses: the Operator’s — merchants@yoomoney.ru, the Counterparty’s — the e-mail address specified in the Contract or Application. At the same time, the work in the System is suspended until unplanned change of keys is complete.

8.7. Take on all the risks associated with the performance of its equipment and communication channels.

8.8. At its own expense maintain software and hardware complexes that ensure the operability of computers and communication means, providing the Electronic document flow, and constitute a part of the System.

8.9. Provide access to ES means only to the persons authorized to sign documents.

8.10. Do not take actions that could harm the System of the other Party while of using the EDF, for example, to launch network attacks, denial of service attacks, virus attacks, and others.

8.11. In a timely manner (via the e-mail specified in Clause 8.6 hereof and/or telephone) inform the other party about all cases of technical malfunctions or other circumstances influencing the Electronic document flow.

8.12. In case of possible security threats, the parties undertake to notify each other in a timely manner of such threats in order to take concerted measures to neutralize them.

8.13. Fulfill the requirements of technical and operational documentation for the software and hardware of the System.

8.14. It is recommended to develop and implement measures to ensure the information security of the System:

  • Confidentiality, integrity and accessibility of software and hardware means;

  • Confidentiality of the transmitted ED;

  • Integrity and accessibility of event registration protocols;

  • Confidentiality, integrity of the current keys and passwords;

  • To organize the internal functioning of the responsible person’s workplace in such a way as to exclude the possibility of using the System by persons who are not allowed to work with the System;

  • To keep confidential all the information on the technology of information protection used in the System.

8.15. Maintain the system time of the System's hardware and software in accordance with the current astronomical time with an accuracy of five minutes. The parties recognize the Moscow time MSK (UTC +3) as a common time scale.

8.16. The parties shall organize the archival storage of the ED during the period of validity of similar documents issued on paper.

9. Rights of the Parties

The Parties are entitled to:

9.1. Limit and suspend the use of the System in cases of the incompliance with the Agreement by another Party hereto, notifying it no later than on the day of the suspension, or at the request of the competent state authorities in the cases and in the manner provided for by the legislation of the Russian Federation.

9.2. Replace the System’s hardware and software with at least a two-Working Day prior notification of the other party.

9.3. Halt the operation of the System for technical reasons until it is restored.

9.4. Make scheduled and unscheduled replacement of the Secret ES Code, ES private key, ES public key and the Certificate at its own initiative, notifying the other party at least two working days in advance.

10. Responsibilities of parties and the risks of losses

10.1. The parties are responsible for the content of the ED signed by them, subject to the confirmation of the authenticity of the ES.

10.2. The parties are responsible for the confidentiality and the procedures for the use of the ES private keys and ES codes.

10.3. The party that committed the compromise of the ES private key is responsible for the ED signed using the compromised ES private key prior to its official notification of the cancellation (revocation) of the corresponding key or Certificate provided to the other Party.

10.4. The party which did not timely report on the loss or compromise of the ES private key, bears the associated risks.

10.5. In the event of a loss, the party that failed to fulfill (or fulfilled improperly) the obligations under the Agreement shall be liable to the other party for the losses incurred as a result of that. In the absence of the evidence of the non-fulfillment (improper fulfillment) of obligations under the Agreement by the parties, the risk of losses is borne by the party whose ES was used to sign the ED, the execution of which entailed such losses.

10.6. The parties are exempted from the liability for a partial or complete non-fulfillment of their obligations under the Agreement, if such a non-fulfillment has resulted from force majeure circumstances, that arose after the Agreement entered into force, as a result of extraordinary events that could not have been foreseen and prevented by reasonable measures. The party undertakes to immediately notify the other party of the occurrence and termination of the force majeure circumstances that impede the fulfillment of its obligations under the Agreement, while the term of the performance of the obligations under the Agreement shall be postponed proportionally to the time during which such circumstances lasted.

10.7. In the event of the termination of the Agreement for any reason, the parties are liable for the obligations that have arisen prior to the termination of the Agreement in accordance with the Russian Federation laws.

11. Settlement of disputes related to the authenticity of the ES

11.1. Any disputes between the parties related to the determination of the authenticity of the electronic signature in the ED, i.e. the integrity of the text and the authenticity of the ED’s sender, are transmitted for the settlement to a specially created expert commission.

11.2. The expert commission is convened on the basis of a written application (claim) by either party. The application shall contain requisites of the disputed signed ED and persons authorized to represent the interests of this party in front of the expert commission.

11.3. Not later than 10 Working Days from the receipt of the application(s) by the other party, the parties shall determine the date, place and time of the commencement of the expert commission’s work, establish which party provides the premises and configures of the ES means.

11.4. Powers of members of the expert commission are confirmed by powers of attorney.

11.5. The expert commission is formed in equal proportions from representatives of the parties.

11.6. The examination of the disputed ED is carried out in the presence of all members of the expert commission.

11.7. The examination is carried out in four stages:

  • Stage 1: the parties jointly establish, configure and test the ES means.

  • Stage 2: the parties provide their copies of the Certificates of verification keys for the ES, as well as the ES public keys for the EUES or Secret ES codes for the simple ES used to create the ES of the disputed ED;

  • Stage 3: depending on the ES type, the expert commission compares the received certificates, ES public keys or Secret ES codes with the ones received at the conclusion of the Main Contract. Matching Certificates, ES public keys and codes are considered as genuine. Also, the expert commission verifies the authenticity of the entire chain of certificates, if there is any.

  • Stage 4: if the third stage is successfully passed, the expert commission checks the authenticity of the ES in the disputed document in the ordinary manner described in this Agreement.

11.8. The results of the examination are drawn up in the form of a written conclusion called an Act of the Expert Commission, signed by all members of the expert commission. The Act is drawn up immediately after the completion of the last stage of the examination. The Act contains results of all stages of the examination, as well as all the essential details of the disputed ED. The Act is made in two copies — one for each of the parties. The Act of the expert commission is final and not subject to revision.

11.9. Confirmation of the authenticity of the ES in the disputed ED and documented in the Act will mean that this ED is legal valid and shall give effect to rights and obligations of the parties established in the Main Contract and the Agreement.

11.10. The parties acknowledge that the Act drawn up by the expert commission is binding on the parties and can serve as an evidence in the further dispute proceedings at the Arbitration Court.

11.11. If there is no agreement on the disputable issues and the voluntary execution of the decision of the expert commission, all materials on these issues can be submitted to the court of the Operator’s location or the location of its representative office in the city of St. Petersburg.

12. Persons authorized by the Parties to use the ES on behalf of them:

On behalf of the Operator — Chairperson of the Executive Board Shabanova, Tatyana Andreevna;

On behalf of the Counterparty which is a legal entity — the person authorized by the constituent documents or by the power of attorney; on behalf of the Counterparty which is an individual entrepreneur or an individual who uses a special tax regime “Self-employed Tax” — a person registered as an individual entrepreneur, or a person authorized by a power of attorney.

Example of the form for Certificate print:

Certification Center of YooMoney

Certificate of ES key

Issued to: YooMoney

Issued by: YooMoney CA

Valid from January 1, 2010 to December 31, 2020

Version:V3
Serial number: 00 00 00 01
Signature algorithm:sha256RSA
Issuer (CN): YooMoney CA
Subdivision (OU): CA
Company (O):YooMoney
City (L):Moscow
Region (S):Moscow
Country (C):RU
Valid from: January 1, 2010 0:00:00 (GMT+04:00)
Valid until: December 31, 2020 23:59:59 (GMT+04:00)
Owner (CN): YooMoney
Subdivision (OU): Web
Company (O):YooMoney
City (L):Moscow
Region (S):Moscow
Country (C):RU
Public key: RSA (2048 bit)
30 82 01 0a 02 82 01 01 00 87 17 c8 8e 57 1d 14 86 3e 03 86 ef 33 4d 43 44 03 1e ef 94 77 b3 4d c5 93 10 f4 3d 0c 5c 05
7f 33 5a cd 95 36 f4 85 84 2d c0 15 83 d4 a6 5e ee 3b bb d3 31 ed 41 49 58 9d c3 73 76 14 57 29 e1 aa dc 38 42 07 48 9a
5e 4f a3 fa e2 8e 23 23 28 c4 6f 01 8a 7e 57 6f 2c cb 4f 0f 15 a6 5c 6e c3 3b 5e 24 a4 30 b5 6c e4 7c 8c 39 c2 b2 40 51
80 40 c7 31 a2 64 3b ca 5d 53 54 a3 5d 38 79 a0 25 82 3b 34 3b 47 da c2 cd db f4 dd 07 ef 4b 92 f7 f2 91 a1 42 7a 7a 01
fd d5 8b 14 97 39 5b 67 1c 63 07 47 1c e3 b9 ba 15 bb 48 73 73 47 da 83 d2 c2 20 38 76 c7 e9 e1 b0 1e 28 4c 76 66 65 96
03 49 31 df 18 da 3a 0d 1d 69 71 50 a6 f0 88 5b a2 83 f4 74 a1 b8 25 f6 a6 33 3d ec bb 2a a1 65 67 89 07 4e 8b 86 93 3c
d0 b9 d3 d7 12 1f ae ff f7 fe 41 b1 ce 81 51 b7 20 87 2f 0b 43 fa a0 49 bd 02 03 01 00 01
Print Algorithm:sha1
Print:8a 16 b4 5c 3b 86 f9 84 31 d9 4e 68 89 3c 0c e1 d0 2a 0f 0e

Certificate validation result: the Certificate is valid. Validated on April 1, 2015. 0:00:00 (GMT+04:00).

Certification Center’s Authorized Person
Signature__________________ Seal
____________________, 20 __

Example of the form for the ES public key print:

signature key

Issued by: YooMoney CA

Signature algorithm:sha256RSA
Public key:RSA (2048 bit)
00:a0:67:7c:2f:c8:de:00:06:da:b0:03:33:0d:c7: 81:41:e0:59:19:bf:7c:59:99:81:74:d1:03:4d:43: f2:1b:7d:08:33:13:7c:0c:06:b0:cc:29:2e:1b:81: 74:83:d2:dc:a0:61:96:85:6c:11:ed:85:db:3b:ed: c7:b7:3c:29:17:5e:41:87:80:9e:2e:3e:74:0a:93: 87:03:74:dc:f9:a6:60:3a:ce:63:6a:6a:18:3d:8d: 99:02:df:0d:13:6b:68:9e:d5:96:55:10:c4:0e:33: 73:01:a8:04:10:dc:59:12:94:40:22:f5:e8:2c:43: 94:18:6d:82:cc:71:ff:b5:da:bf:cd:55:b9:55:01: 72:74:85:da:a6:7d:61:d1:fb:1f:98:cf:c4:40:80: 27:9f:fe:a5:1c:01:8f:e5:59:8d:12:d2:ea:fc:84: 4a:c1:13:80:ed:d2:8f:16:3f:76:76:29:f9:00:81: 49:ae:6f:6a:8c:62:8a:d2:4c:18:6a:0c:69:8f:52: 09:47:4e:45:37:37:cd:b8:30:5f:f1:79:c5:0e:62: 0d:bc:5a:ee:13:19:3e:46:94:f0:03:ff:e5:cb:99: 43:63:51:84:16:53:86:7e:9b:b4:13:c9:31:85:cf: a2:e8:97:2b:8b:b3:34:16:19:03:05:84:a3:20:aa: 5f:95


Certificate validation result: the Certificate is valid. Validated on April 1, 2015. 0:00:00 (GMT+04:00).
Certification Center’s Authorized Person
Signature __________________ Seal
________________, 20 __