Introduction
Check request
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.check_url: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.ok - payment acceptedrejected - payment refusalerror - error in data interpretation.Result notify
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.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.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 acceptedrejected - payment refusal if pg_can_reject is equal to 1error - error in data interpretationPayout notify
pg_post_link will be calledMerchant server should respond with status 200
Post link on the merchant side must be public, without authorization.Redirect back
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.Result URL and Success URL must be clearly understoodResult 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.Support
If you found an inaccuracy or need help, feel free to reach out! 👋