I have created a payment module for Barclaycard EPDQ and all seems to work fine except for the callback. I am successfully redirected back to the page that I specifiy in the SuccessURL settings property however the ProcessCallback function is never called (checked via live debugging) hence the order does not get updated and appear as a new order.
Do you have any ideas why this is not being called or any additional ways that I can debug and try and see why it isn't being called. I used the Worldpay payment module as the base for the EPDQ payment module so I know that the callback function is correct.
So does Barclay do a true callback? Nothing you need to setup in their admin interface or enable or something? Do you send the teaCommerceCallBackUrl as information to the Barclay API when you generate the form?
The only way to debug is to do it at a live url. Maybe write to a file like some of the other payment providers. Just to be sure it has nothing to do with the debug process.
Apologies it took a while to respond. A little confused with this as I can't work out how the callback process actually works. The system is successfully redirecting to the Success and Failure URL's that I pass through to the payment provider, however how does the callback related to the ProcessCallback functional actually get called?
Depends on the payment gateway. The callback method is only activated if you pass that URL to the gateway in the GenerateForm method and the gateway use it, OR the gateway have a setting at their admin UI where you configure it. If it doesn't support true callbacks you need to override the FinalizeAtContinueUrl and return true in Tea Commerce. Then the TC system will fake the callback method call when the continue url is hit.
So if I am sending through a callback URL such as "http://<domain name>/basket/completed/" are you saying this would not call the ProcessCallback function. If that is so what is the correct Success/Failure URL that I should send through to the payment gateway? I know that the Barclaycard EPDQ gateway does do a true callback.
The callback URL MUST be the "magic" URL that Tea Commerce parses in in the GenerateForm method. Tha tis the one that will trigger the callback method. The /basket/complated/ url looks more like a continue URL that you should have as a setting for your provider. See some of the other payment providers and how they are programmed regarding this.
I can see the teaCommerceCallBackUrl in the GenerateHtmlForm method in some of the default payment providers as follows:
public override PaymentHtmlForm GenerateHtmlForm( Order order, string teaCommerceContinueUrl, string teaCommerceCancelUrl, string teaCommerceCallBackUrl, string teaCommerceCommunicationUrl, IDictionary<string, string> settings )
What I can't work out or find is where the teaCommerceCallBackUrl is actually generated as it doesn't look to be a property when viewing the SagePay or Worldpay payment providers?
Okay, so I think I am slowly getting there, just one other question though. Taking the WorldPay provider, it looks to send the successURL and the cancelURL to WorldPay but doesnt look to send the CallBackUrl, so in the case of WorldPay how does the ProcessCallback function get called?
I am still a little stuck with the implementation of callback. I am sending the AcceptURL as the teaCommerceCallbackURL through to Barclaycard EPDQ and it successfully responds to the URL sending parameters which are subsequently used within the ProcessCallback function. However all I am then left with is a blank page, how do I then redirect to a completed page once the ProcessCallback function has completed??
So, analysing further, Barclaycard EPDQ allows the following:
Direct HTTP server-to-server request - this allows a URL to be specified in the administration area, with a variable parameter passed through by a hidden PARAMVAR field. I have therfore tried to pass through the part of the teaCommerceCalledBackUrl which varies, namely the orderId + "/" + hash + ".aspx" part of the URL. However the PARAMVAR cannot contain special characters and these end up being URL Encoded which then breaks the link.
HTTP redirection in the browser - this allows URLs to be sent via fields as follows:
ACCEPTURL
DECLINEURL
EXCEPTIONURL
CANCELURL
I have tried passing the teaCommerceCallbackUrl through and this is successfully redirected back to, however as mentioned above I am then shown a blank page as no redirect occurs within the ProcessCallback method. If I send through the basket completed page URL then obviously the order is never updated as the ProcessCallback function is never called.
What would be your suggestion as the best way to proceed based on the information set out above?
The acceptUrl should never be the TeaCommerceCallbackUrl. The you should send the continueUrl and then override the property FinalizeAtContinueUrl which will make the callback when then continue url is hit.
Thanks for the additional information. For my own reference and pure curiosity, If I override and set the FinalizeAtContinueUrl property to True, does that then call the ProcessCallback function?
I have overriden the FinalizeAtContinueUrl property in my payment provider class as follows:
public override bool FinalizeAtContinueUrl { get { return true; } }
However when the callback is made to the accepturl that I have set then it is successfully redirected to the the page however nothing then happens, is there something else that I am missing?
If the provider returns true for FinalizeAtContinueUrl then the callback method will be called. That is how some of the other providers work. So it must be working :)
How are you debugging? Try and have the only code in your callback method to be some code that writes a file to disk. Then you can see that it works.
And just to be sure. You send the "magic" teaCommerceContinueUrl to the gateway and not just your own continue url? Only the magic one will be sure that the callback is also called.
Thanks Anders, that gave me pretty much the information I needed to get it working. As it so happens the Barclaycard EPDQ system is pretty much identical to the OGON payment provider that already exists, wish I had realised that in the first place :/ anyway I will send you through the Barclaycard EPDQ payment provider code once I am happy it all works as it should and I am happy for you to add it to the core TeaCommerce payment providers.
Just a quick question relating to this, seemed pointless starting a new thread. Does TeaCommerce also have a FinalizeAtCancelUrl function, as currently the Cancel callback doesn't work, this is because it works in the same way as the Continue function and is why I am using FinalizeAtContinueURL
Apologies for the late reply on this. The reason I was asking is that I want the status of the order to be set to either Cancelled or Declined depending on the status that is returned. Due to the way in which SagePay works I have had to use the FinalizeAtContinueURL but I can't see a way of doing this for the CancelURL and DeclineURL without having the concept of the FinalizeAt functionality?
Not possible to use the communication URL to do some of this. You could then do what you want at this URL and then redirect to the continue url when it is right or something like that.
Its a bit hard to help when you dont know exactly how the provider works and what you want to do. I could use many hours to investigate this :)
I could properly do paid support if you need more detailed help with this case.
ProcessCallback not called
I have created a payment module for Barclaycard EPDQ and all seems to work fine except for the callback. I am successfully redirected back to the page that I specifiy in the SuccessURL settings property however the ProcessCallback function is never called (checked via live debugging) hence the order does not get updated and appear as a new order.
Do you have any ideas why this is not being called or any additional ways that I can debug and try and see why it isn't being called. I used the Worldpay payment module as the base for the EPDQ payment module so I know that the callback function is correct.
Hi Graham
So does Barclay do a true callback? Nothing you need to setup in their admin interface or enable or something? Do you send the teaCommerceCallBackUrl as information to the Barclay API when you generate the form?
The only way to debug is to do it at a live url. Maybe write to a file like some of the other payment providers. Just to be sure it has nothing to do with the debug process.
Kind regards
Anders
Hi Anders,
Apologies it took a while to respond. A little confused with this as I can't work out how the callback process actually works. The system is successfully redirecting to the Success and Failure URL's that I pass through to the payment provider, however how does the callback related to the ProcessCallback functional actually get called?
Depends on the payment gateway. The callback method is only activated if you pass that URL to the gateway in the GenerateForm method and the gateway use it, OR the gateway have a setting at their admin UI where you configure it. If it doesn't support true callbacks you need to override the FinalizeAtContinueUrl and return true in Tea Commerce. Then the TC system will fake the callback method call when the continue url is hit.
Kind regards
Anders
So if I am sending through a callback URL such as "http://<domain name>/basket/completed/" are you saying this would not call the ProcessCallback function. If that is so what is the correct Success/Failure URL that I should send through to the payment gateway? I know that the Barclaycard EPDQ gateway does do a true callback.
The callback URL MUST be the "magic" URL that Tea Commerce parses in in the GenerateForm method. Tha tis the one that will trigger the callback method. The /basket/complated/ url looks more like a continue URL that you should have as a setting for your provider. See some of the other payment providers and how they are programmed regarding this.
I can see the teaCommerceCallBackUrl in the GenerateHtmlForm method in some of the default payment providers as follows:
public override PaymentHtmlForm GenerateHtmlForm( Order order, string teaCommerceContinueUrl, string teaCommerceCancelUrl, string teaCommerceCallBackUrl, string teaCommerceCommunicationUrl, IDictionary<string, string> settings )
What I can't work out or find is where the teaCommerceCallBackUrl is actually generated as it doesn't look to be a property when viewing the SagePay or Worldpay payment providers?
That is why I said "Magic". See here how its generated
https://github.com/TeaCommerce/Tea-Commerce-for-Umbraco/tree/master/Source/TeaCommerce.Umbraco.Configuration/PaymentProviders
If should not think of how it is generated - just use it :)
Okay, so I think I am slowly getting there, just one other question though. Taking the WorldPay provider, it looks to send the successURL and the cancelURL to WorldPay but doesnt look to send the CallBackUrl, so in the case of WorldPay how does the ProcessCallback function get called?
Its has the GetCartNumber so that indicates to me that you configure the callback URL in the admin interface of their system. Looks a bit like this silent post url here:
https://documentation.teacommerce.net/guides/payment-providers/authorizenet/
Note that the URL is for Tea Commerce v1 - will be updated to v3 later today :)
I am still a little stuck with the implementation of callback. I am sending the AcceptURL as the teaCommerceCallbackURL through to Barclaycard EPDQ and it successfully responds to the URL sending parameters which are subsequently used within the ProcessCallback function. However all I am then left with is a blank page, how do I then redirect to a completed page once the ProcessCallback function has completed??
So, analysing further, Barclaycard EPDQ allows the following:
What would be your suggestion as the best way to proceed based on the information set out above?
The acceptUrl should never be the TeaCommerceCallbackUrl. The you should send the continueUrl and then override the property FinalizeAtContinueUrl which will make the callback when then continue url is hit.
Thanks for the additional information. For my own reference and pure curiosity, If I override and set the FinalizeAtContinueUrl property to True, does that then call the ProcessCallback function?
I have overriden the FinalizeAtContinueUrl property in my payment provider class as follows:
public override bool FinalizeAtContinueUrl
{
get
{
return true;
}
}
However when the callback is made to the accepturl that I have set then it is successfully redirected to the the page however nothing then happens, is there something else that I am missing?
If the provider returns true for FinalizeAtContinueUrl then the callback method will be called. That is how some of the other providers work. So it must be working :)
How are you debugging? Try and have the only code in your callback method to be some code that writes a file to disk. Then you can see that it works.
And just to be sure. You send the "magic" teaCommerceContinueUrl to the gateway and not just your own continue url? Only the magic one will be sure that the callback is also called.
Kind regards
Anders
Thanks Anders, that gave me pretty much the information I needed to get it working. As it so happens the Barclaycard EPDQ system is pretty much identical to the OGON payment provider that already exists, wish I had realised that in the first place :/ anyway I will send you through the Barclaycard EPDQ payment provider code once I am happy it all works as it should and I am happy for you to add it to the core TeaCommerce payment providers.
Great you got it working!
Hi Anders,
Just a quick question relating to this, seemed pointless starting a new thread. Does TeaCommerce also have a FinalizeAtCancelUrl function, as currently the Cancel callback doesn't work, this is because it works in the same way as the Continue function and is why I am using FinalizeAtContinueURL
Thanks,
Graham
We don't have a finalize at cancel url - why would you want an order to be finalized when the payment gateway sends the customer to the cancel url?
Hi Anders,
Apologies for the late reply on this. The reason I was asking is that I want the status of the order to be set to either Cancelled or Declined depending on the status that is returned. Due to the way in which SagePay works I have had to use the FinalizeAtContinueURL but I can't see a way of doing this for the CancelURL and DeclineURL without having the concept of the FinalizeAt functionality?
Graham
Not possible to use the communication URL to do some of this. You could then do what you want at this URL and then redirect to the continue url when it is right or something like that.
Its a bit hard to help when you dont know exactly how the provider works and what you want to do. I could use many hours to investigate this :) I could properly do paid support if you need more detailed help with this case.
Kind regards
Anders
is working on a reply...