To use this request, you should contact your manager
 Before accepting money from the buyer on the account, the payment gate can call the merchant script Check URL using the Request Method.  Check URL on the merchant side must be public, without authorization.  {{project}} sends information about the number and properties of the order and waits for a response. Failure to respond within the specified time is considered as a refusal to pay.  The Check URL script is called only if this option was enabled in the merchant settings.
Merchant response to check_url:
 If Check URL is empty at the moment of payment initialization or not specified at the moment of payment initialization, and is set to empty in the merchant settings, then the step of checking the ability to make a payment is skipped and it is considered that the merchant agrees to accept the payment.
 After receiving a payment from a client or if it is impossible to make a payment, {{project}} calls the Result URL of the store and sends information about the payment result to it using the Request Method method.  Upon receipt of this request, the merchant must take the necessary actions to transfer the goods or services to the buyer, if the payment was successful. If pg_can_reject is equal to 1 and the merchant cannot accept the payment (for example, the ticket reservation has expired), it must respond with a rejected status, and {{project}} will reject the payment. In this case, the pg_description field from the merchant response is shown to the user as the reason for the refusal.
Result URL on the merchant side must be public, without authorization.
 If the merchant's server is not available at the time the Result URL is called, or if the response from the server was not 200, {{project}} will make repeated attempts to call it every half an hour for 2 hours, even if the pg_lifetime account expires.  If the first attempt to call Result URL is unsuccessful, then the payment is not canceled, and in subsequent calls Result URL does not allow the merchant to refuse the payment.  The store must be prepared for the Result URL to be called repeatedly for the same payment. Retry responses must match the original response, even if the pg_lifetime transaction has expired.
Merchant response to result_url
 The rejected status can be returned by the merchant only if the pg_can_reject parameter equal to 1 was specified in the incoming request from the gate, otherwise, regardless of the merchant's response, the payment will be considered completed. If the merchant refused the payment (rejected answered), the buyer is redirected to Failure URL, otherwise - to Success URL.
ok - payment accepted
rejected - payment refusal if pg_can_reject is equal to 1
 In case of successful payment, the URL specified in pg_post_link will be called  Merchant server should respond with status 200  Post link on the merchant side must be public, without authorization.
 After completing the payment in the online payment system, the buyer is redirected to the merchant page Success URL or Failure URL, depending on the result of the payment. Redirection occurs using the Success URL Method or Failure URL Method specified during payment initialization.  If at GET request Success URL or Failure URL already contain parameters in query string, then additional parameters pg_order_id, pg_payment_id and custom variables of the merchant are appended to the end of query string. The merchant must ensure that the names of additional parameters do not match the names of existing parameters.
The difference between Result URL and Success URL must be clearly understood
 Result URL is called directly from the {{project}} server, while Success URL is called by the user's browser when {{project}} redirects the user back to the store site.  It is wrong to use Success URL as the only way to find out about the completion of the payment, because the user may for various reasons (for example, when the connection is broken) not to reach the Success URL after the payment. The most reliable way to find out about the completion of the payment is to implement a Result URL, which {{project}} undertakes to call again every half an hour within 2 hours after the payment, if the first attempt for any reason failed.