You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is another thing: when redirecting to the returnUrl/cancelUrl, the URL will contain the parameters encoded and signed. The documentation states that you should not be used to process that kind of data, but it's the only way to know if the purchase was approved, rejected, canceled, etc.
What we do to process the status and the payment is to read that data on the returnUrl, and update our transaction as "paid but unreported". After receiving the data from notifyUrl, we update it as "paid".
There is another thing: when redirecting to the
returnUrl
/cancelUrl
, the URL will contain the parameters encoded and signed. The documentation states that you should not be used to process that kind of data, but it's the only way to know if the purchase was approved, rejected, canceled, etc.What we do to process the status and the payment is to read that data on the
returnUrl
, and update our transaction as "paid but unreported". After receiving the data fromnotifyUrl
, we update it as "paid".In order to accomplish that workflow, this function should be able to get the parameters from
$_POST
but also from$_GET
: https://github.com/PatronBase/omnipay-redsys/blob/master/src/Message/CompletePurchaseRequest.php#L10-L13I would love to know about your workflow if it's different and your opinion about this. Would you be interested in a PR of #2, #3, and this issue?
The text was updated successfully, but these errors were encountered: