We are using a custom WorldPay payment provider which all seem's to be working fine processing orders but when cancelling a payment nothing appears to change with regards to the order. When I re-direct back to the website the item is still in my basket and checking the database the payment status is still set as 'Pending Authorization'
My ToCancelled.config file which is the default file is shown below:
<configuration>
<components>
<!-- Pipeline Instance -->
<component id="ToCancelled"
service="UCommerce.Pipelines.IPipeline`1[[UCommerce.EntitiesV2.PurchaseOrder, UCommerce]], UCommerce"
type="UCommerce.Pipelines.OrderProcessing.OrderProcessingPipeline, UCommerce.Pipelines">
<parameters>
<tasks>
<array>
<!--
Payment processing vendors ussually require additional subscription fees for you to be able to access their API.
Please consult your agreement to see if API access is supported for your particular plan.
-->
<value>${ToCancelled.CancelPaymentTask}</value>
</array>
</tasks>
</parameters>
</component>
<!-- Pipeline Tasks-->
<component id="ToCancelled.CancelPaymentTask"
service="UCommerce.Pipelines.IPipelineTask`1[[UCommerce.EntitiesV2.PurchaseOrder, UCommerce]], UCommerce"
type="UCommerce.Pipelines.OrderProcessing.CancelPaymentTask, UCommerce.Pipelines" />
</components>
</configuration>
I've checked the logs and it mentions nothing about issues processing the pipeline or anything. I do however see a few logs related to threads being abborted but these seem to occur as I actually am re-directed to WorldPay and none after that.
Thread was being aborted. Void AbortInternal() at System.Threading.Thread.AbortInternal() at System.Threading.Thread.Abort(Object stateInfo) at System.Web.HttpResponse.End() at UCommerce.Transactions.Payments.ExternalPaymentMethodService.RequestPayment(PaymentRequest paymentRequest) at UCommerce.Transactions.TransactionLibraryInternal.RequestPayment(Int32 paymentId) at Castle.DynamicProxy.AbstractInvocation.Proceed() at UCommerce.Infrastructure.Interceptor.ExceptionLoggingInterceptor.Intercept(IInvocation invocation) at Castle.DynamicProxy.AbstractInvocation.Proceed() at Castle.Proxies.TransactionLibraryInternalProxy.RequestPayment(Int32 paymentId) at UCommerce.Transactions.TransactionLibraryInternal.RequestPayments() at Castle.DynamicProxy.AbstractInvocation.Proceed() at UCommerce.Infrastructure.Interceptor.ExceptionLoggingInterceptor.Intercept(IInvocation invocation) at UCommerce.Infrastructure.Interceptor.ExceptionLoggingInterceptor.Intercept(IInvocation invocation) at Castle.DynamicProxy.AbstractInvocation.Proceed() at ASP._Page_macroScripts_uCommerce_Preview_cshtml.Execute() at System.Web.WebPages.WebPageBase.ExecutePageHierarchy() at System.Web.WebPages.WebPage.ExecutePageHierarchy() at System.Web.WebPages.WebPageBase.ExecutePageHierarchy(WebPageContext pageContext, TextWriter writer, WebPageRenderingBase startPage) at umbraco.MacroEngines.RazorMacroEngine.ExecuteRazor(MacroModel macro, INode currentPage) at umbraco.MacroEngines.RazorMacroEngine.Execute(MacroModel macro, INode currentPage) at umbraco.macro.loadMacroScript(MacroModel macro) at umbraco.macro.renderMacro(Hashtable pageElements, Int32 pageId) at umbraco.presentation.templateControls.Macro.CreateChildControls() at System.Web.UI.Control.EnsureChildControls() at System.Web.UI.Control.InitRecursive(Control namingContainer) at System.Web.UI.Control.InitRecursive(Control namingContainer) at System.Web.UI.Control.InitRecursive(Control namingContainer) at System.Web.UI.Control.InitRecursive(Control namingContainer) at System.Web.UI.Control.InitRecursive(Control namingContainer) at System.Web.UI.Control.InitRecursive(Control namingContainer) at System.Web.UI.Control.InitRecursive(Control namingContainer) at System.Web.UI.Control.InitRecursive(Control namingContainer) at System.Web.UI.Control.InitRecursive(Control namingContainer) at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) at System.Web.UI.Page.ProcessRequest() at System.Web.UI.Page.ProcessRequest(HttpContext context) at ASP.default_aspx.ProcessRequest(HttpContext context) at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) at System.Web.HttpApplication.PipelineStepManager.ResumeSteps(Exception error) at System.Web.HttpApplication.BeginProcessRequestNotification(HttpContext context, AsyncCallback cb) at System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context) at System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntPtr managedHttpContext, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags) at System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr managedHttpContext, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags) at System.Web.Hosting.UnsafeIISMethods.MgdIndicateCompletion(IntPtr pHandler, RequestNotificationStatus& notificationStatus) at System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntPtr managedHttpContext, IntPtr nativeRequestContext, In...
As this is a tricky one to debug I decided to install a new fresh copy uCommerce and the razor store and that also has this thread being aborted message in the error logs when the user is redirected onto the payment provider (WorldPay).
I spoke with uCommerce about this error before CG13, and if memory serves me well it is the redirect that trigges the thread aborted error. I understood that this is normal behavior, and shouldn't be related to the other issues you are having.
Looks like you're seeing a symptom of a different issue.
The ToCancelled pipeline will only process payment that are in a certain state: Authorized or Acquired.
Yours seem to be in "Pending Authorization", which is the initial state for new payment before the customer is passed to the payment gateway to authorize their creditcard.
If you're seeing successful payments on the gateway the issue might be:
A) The callback from the gateway is not received: Check whether your server is accessible from the internet and whether there is any info in the logs.
B) The callback is received, but an error is triggered in the Checkout pipeline: Check for errors in the log, typically SMTP errors are the main culprit here or the server DNS name is not resolvable locally.
Thanks for your reply. No error logs except the one around thread being aborted which as I suspected is to do with the re-direct.
If I look in the database at the uCommerce_Payment table all my payments are either status 10000001 or 10000003 so when completing the order the callback is completed successfully. It's just when I go through to WorldPay and then click cancel it does not actually cancel the order? The order is still in the users basket and the status stays as 10000001.
I've now got that horrible feeling that what I'm thinking is not actually the functionality. Is it that the cancelled pipeline is only called when a order is manually cancelled via uCommerce or the WorldPay admin system? Not the user just cancellimg payment on the payment screens,
You're right. The ToCancelled pipeline is only executed when the order is cancelled as you mention.
The only signal that you potentially get that a customer cancels the payment process is if the gateway redirects the customer to a cancel URL. I can't remember off the top of my head whether WorldPay supports that. If it does there will be a cancel URL in the config file.
ToCancelled Pipeline not running
Hi,
We are using a custom WorldPay payment provider which all seem's to be working fine processing orders but when cancelling a payment nothing appears to change with regards to the order. When I re-direct back to the website the item is still in my basket and checking the database the payment status is still set as 'Pending Authorization'
My ToCancelled.config file which is the default file is shown below:
Any help would be much appreciated.
John
As this is a tricky one to debug I decided to install a new fresh copy uCommerce and the razor store and that also has this thread being aborted message in the error logs when the user is redirected onto the payment provider (WorldPay).
I spoke with uCommerce about this error before CG13, and if memory serves me well it is the redirect that trigges the thread aborted error. I understood that this is normal behavior, and shouldn't be related to the other issues you are having.
Hi John,
Looks like you're seeing a symptom of a different issue.
The ToCancelled pipeline will only process payment that are in a certain state: Authorized or Acquired.
Yours seem to be in "Pending Authorization", which is the initial state for new payment before the customer is passed to the payment gateway to authorize their creditcard.
If you're seeing successful payments on the gateway the issue might be:
A) The callback from the gateway is not received: Check whether your server is accessible from the internet and whether there is any info in the logs.
B) The callback is received, but an error is triggered in the Checkout pipeline: Check for errors in the log, typically SMTP errors are the main culprit here or the server DNS name is not resolvable locally.
Hope this helps.
Hi Soren,
Thanks for your reply. No error logs except the one around thread being aborted which as I suspected is to do with the re-direct.
If I look in the database at the uCommerce_Payment table all my payments are either status 10000001 or 10000003 so when completing the order the callback is completed successfully. It's just when I go through to WorldPay and then click cancel it does not actually cancel the order? The order is still in the users basket and the status stays as 10000001.
John
I've now got that horrible feeling that what I'm thinking is not actually the functionality. Is it that the cancelled pipeline is only called when a order is manually cancelled via uCommerce or the WorldPay admin system? Not the user just cancellimg payment on the payment screens,
John
Hi John,
You're right. The ToCancelled pipeline is only executed when the order is cancelled as you mention.
The only signal that you potentially get that a customer cancels the payment process is if the gateway redirects the customer to a cancel URL. I can't remember off the top of my head whether WorldPay supports that. If it does there will be a cancel URL in the config file.
Hope this helps.
Yeah that really does, thanks Soren. For reference WorldPay takes a acceptUrl and declineUrl.
John
is working on a reply...