[Question] get transaction ID and transaction reference from redirects returnUrl and cancelUrl

[4n70w4]

trafficstars

Hi! I am developing a payment gateway based on omnipay. Abstract scheme looks like this: many sites of sellers <-> my gateway <-> many payment systems

1. seller site send to my gateway invoice with their returnUrl and cancelUrl, i save it in DB.
2. I generate new returnUrl and cancelUrl with my gateway host and send it to payment system.
3. payment system redirect to my gateway, I need to determine the transaction ID and transaction reference that find id DB original returnUrl and cancelUrl and redirect to seller site.

Question: omnipay provides methods for parsing data from redirects returnUrl and cancelUrl? If not, then this is a feature request.

This is necessary because some payment systems do not allow for set custom returnUrl and cancelUrl for each payment. This payment systems require setting constant values in back-office.

[judgej]

If there is data to parse (e.g. GET and POST data) then the gateway driver will provide complete* methods.

So on return to the merchant site, the application would do something like:

$response = $gateway->completeAuthorize()->send();

with the results being in the $response object. Sometimes that complete method may make an additional call back to the gateway to get further details about the result. Sometimes the complete result is available to it in the success or cancel POST (which will be signed and/or encrypted, if it is to be trusted).

You will need to be aware that some gateways include the return URLs in message signing, so beyond a point those URLs cannot be changed. But if you are the effective merchant site (a proxy, if I am reading correctly) then that should not be a problem since you are generating all the signing within your payment site as that is where Omnipay is running.

[4n70w4]

current \Omnipay\Common\GatewayInterface declared only 2 complete* methods:

 * @method \Omnipay\Common\Message\RequestInterface completeAuthorize(array $options = array()) (Optional method)
 *         Handle return from off-site gateways after authorization
 * @method \Omnipay\Common\Message\RequestInterface completePurchase(array $options = array())  (Optional method)
 *         Handle return from off-site gateways after purchase

and semantically not suitable for handle redirect (not server to server callback) after payment (succes or cancel, returnUrl or cancelUrl) to thank you page.

Yes, can it implement by yourself. But at the moment naming of these methods is not regulated and may be named differently or absent in different plugins.

For example: https://mygw.local/some-callback/ - is returnUrl or cancelUrl

paypal express make redirect (not server to server callback) user after payment to https://mygw.local/some-callback/?token=EC-23981419811YC530N&PayerID=9A2UUTPUJB238

1. (optional) Need detect gateway type (paypal or another)
2. (required) Need map GET-param token to transactionReference

I think this is useful and important functionality. And omnipay should regulate its use, and plugins authors should implement it.

[judgej]

For server-to-server notifications use acceptNotify(). For the PayPal example you would use completeAuthorize() or completePurchase(). I'm not sure if there is a third case here? I do have a feeling I'm missing something.

For detecting the gateway type, I think your only practical option is to use different routes for each type.

[4n70w4]

This issue is not about server to server.

For Paypal Express gateway call completePurchase() need pass array with from paypal-added get params token and PayerID values. (example: mygw.local/some-callback/?token=EC-23981419811YC530N&PayerID=9A2UUTPUJB238) Other payment systems can add their own parameters to returnUrl and cancelUrl.

In my case, the returnUrl and cancelUrl pages located on another site and cannot call completePurchase(). But I can create an my own wrapper for returnUrl and cancelUrl for parse get-params generated by payment system and 301 redirect to final returnUrl or cancelUrl.

The problem is to unify the parsing of generated by payments systems get parameters added to returnUrl and cancelUrl. The gateways that I use now do not provide separate methods for perverting these parameters and mapping them into omnipay-specific names. For example - convert Paypal Express token param from returnUrl or cancelUrl to omnipay transactionReference.

[MR-AMDEV]

This issue is not about server to server.

For Paypal Express gateway call completePurchase() need pass array with from paypal-added get params token and PayerID values. (example: mygw.local/some-callback/?token=EC-23981419811YC530N&PayerID=9A2UUTPUJB238) Other payment systems can add their own parameters to returnUrl and cancelUrl.

In my case, the returnUrl and cancelUrl pages located on another site and cannot call completePurchase(). But I can create an my own wrapper for returnUrl and cancelUrl for parse get-params generated by payment system and 301 redirect to final returnUrl or cancelUrl.

The problem is to unify the parsing of generated by payments systems get parameters added to returnUrl and cancelUrl. The gateways that I use now do not provide separate methods for perverting these parameters and mapping them into omnipay-specific names. For example - convert Paypal Express token param from returnUrl or cancelUrl to omnipay transactionReference.

Thanks man i was stuck where i was getting returned after the checkout and there was nothing to do .By reading your comment the logic becomes fully clear to me and i just complete sandbox payment successfully.Thanks man