Yesterday a customer payed an order. Unfortunately the callback came back with an error.
I couldn't read the error because of web.config settings so I tried to push the status again today with error messages enabled.
It returned a 500 status with the message:
,"ExceptionMessage":"Value cannot be null.\r\nParameter name:
orderNumber"
I can't see the processCallback being hit in my payment provider.
Also I'm not sure if it's an error because of a property from the push message is null or the actual order doesn't have an ordernumber?(which it doesn't have according to the database)
Is there still a way to push the payment status for this specific order?
Update:
This is the full message:
{"Message":"An error has occurred.","ExceptionMessage":"Value cannot be null.\r\nParameter name: orderNumber","ExceptionType":"System.ArgumentNullException","StackTrace":" at Vendr.Core.AssertionExtensions.MustNotBeNull[T](T param, String paramName)\r\n at Vendr.Core.AssertionExtensions.MustNotBeNullOrEmpty(String param, String paramName)\r\n at Vendr.Core.Web.PaymentProviders.OrderReference..ctor(Guid orderId, String orderNumber)\r\n at Vendr.Core.Web.OrderReferenceExtensions.GenerateOrderReference(OrderReadOnly order)\r\n at Vendr.Core.Web.Controllers.VendrPaymentController.Callback(IPaymentProvider paymentProvider, OrderReference orderReference)\r\n at Vendr.Core.Web.Controllers.VendrPaymentController.HandleRequestWithOrder(String requestType, String paymentProviderAlias, Guid orderId, String orderNumber, String hash, Func`3 handler)\r\n at Vendr.Core.Web.Controllers.VendrPaymentController.Callback(String vendrPaymentProviderAlias, Guid vendrOrderId, String vendrOrderNumber, String vendrHash)\r\n at lambda_method(Closure , Object , Object[] )\r\n at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ActionExecutor.<>c__DisplayClass6_2.<GetExecutor>b__2(Object instance, Object[] methodParameters)\r\n at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ExecuteAsync(HttpControllerContext controllerContext, IDictionary`2 arguments, CancellationToken cancellationToken)\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at System.Web.Http.Controllers.ApiControllerActionInvoker.<InvokeActionAsyncCore>d__1.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at System.Web.Http.Controllers.ActionFilterResult.<ExecuteAsync>d__5.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at System.Web.Http.Filters.AuthorizationFilterAttribute.<ExecuteAuthorizationFilterAsyncCore>d__3.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at System.Web.Http.Dispatcher.HttpControllerDispatcher.<SendAsync>d__15.MoveNext()"}
The callbackUrl which is send from Buckaroo is complete with the provideralias, orderid, ordernumber and hash.
Hmm, for the callbackUrl to be fully configured with the order ID + order Number yet the order doesn't have an order number against it is a little odd. I think the only time we potentially clear an order number is if the order is modified after payment is initialized (which is when the order number is generated). Could there have been anything that would have modified the order between payment initialization and payment complete that would require an order recalculation?
The only other thing I could think could be happening is if you are in a a load balanced environment and if there is something wrong with the cache invalidation and a previous version of the order got re-saved.
We do have a review page where the @Html.BeginPaymentForm is called so the user can be redirected to Buckaroo.
The user did go back once from the review page to the previous step. Then the user went to the review page again(Buckaroo is then also called to provide the redirect URL again with a new order number).
Which I think is normal behaviour?
The user did pay the second time and the cart wasn't changed between going to the payment and returning from Buckaroo if I can see correct in the IIS log.
Every callback from that specific cart in the IIS log has returned a 500 error.
This can also be seen in the Buckaroo portal.
Also, this is the only order we know that had this problem. So no big deal.
Ps.
I noticed, we do prevent caching(by using the browser back button) on the reviewpage by adding headers to the current response.
Hmm, yea, it's ok for a customer to leave the review step and come back. The review step is when the order number is generated (in order to have one set prior to going to the payment gateway) and if they leave and come back, it should get a new order number (as some gateways don't allow processing the same order number twice) so it's completely valid behavior.
I don't think the cache header would be a problem.
I'm really not sure what has happened here for the order number to be removed. To fix the data, you might have to go into the database and give the order the order number you know it should have along with a finalized date if it hasn't already got one. That should at least make the data correct.
Best I can suggest for now is to monitor this and if it happens again, see if there are any similarities in how those orders took place 🤔
We recently had the exact same thing happen to a random order. We cant seem to get to the bottom of it but just thinking if it is a one off maybe we can live with it.
Did you notice this issue keeps popping up through?
If so, I probably need to figure out why.
I'm a colleague of Michel, and yes we still have this problem once in a while, let's say around once every 500 orders. We have a manual workflow where we check the order manually and change the database values accordingly.
It's unfortunate, but we could not get to the bottom of this issue. We weren't able to solve, let alone reproduce it on a regular basis, so it's pretty difficult to solve.
I don't know if you ever came to an answer, but we've managed to reproduce a workflow for this in our project.
Basically someone goes through the Vendr checkout all the way to the external payment service provider. In our case Mollie.
The VendrOrder object gets assigned an OrderNumber in that last step, which is then forwarded to the external PSP. As far as the PSP is concerned, our orderNumber reference is ORDER-01234-56789-ABCDE
The customer starts wondering if they filled in their address information correctly and goes back to the Vendr address information step in their browser.
On this page we have a flow where we call .SetShippingCountryRegion(). Which sets the VendrOrder object's OrderNumber property to null.
Are you saying you call SetShippingCountryRegion regardless? Or have they changed their address? If they are just continuing without changing anything, then the simplest solutionw ould be for you to check before updating the shipping country region to esure it's actually different. If it's unchanged, then there wouldn't be a need to reset the order number.
Made a mistake above, it was actually us calling SetPaymentMethod(paymentMethod) on the currentOrder object on every pageload for VendrCheckoutInformationPage.
This was the bit that reset the OrderNumber property to null. Resolved it by simply only calling .SetPaymentMethod() whenever currentOrder.PaymentInfo.PaymentMethodId == null
We do call .SetShippingCountryRegion() when a customer hits submit on the VendrCheckoutInformationPage. Will have to test that scenario tomorrow.. Whether that would cause the same situation and what the workaround should be :)
Most likely just adding a check for whether the property is null. Since we only ship to one country, we only need to set it once.
Value can not be null param. name: orderNumber
Information:
Umbraco: v8.8.0 Vendr: v1.3.4 Vendr payment provider: Custom Buckaroo
Hi,
Yesterday a customer payed an order. Unfortunately the callback came back with an error. I couldn't read the error because of web.config settings so I tried to push the status again today with error messages enabled. It returned a 500 status with the message:
I can't see the processCallback being hit in my payment provider. Also I'm not sure if it's an error because of a property from the push message is null or the actual order doesn't have an ordernumber?(which it doesn't have according to the database)
Is there still a way to push the payment status for this specific order?
Update:
This is the full message:
The callbackUrl which is send from Buckaroo is complete with the provideralias, orderid, ordernumber and hash.
Hi Michel,
Hmm, for the callbackUrl to be fully configured with the order ID + order Number yet the order doesn't have an order number against it is a little odd. I think the only time we potentially clear an order number is if the order is modified after payment is initialized (which is when the order number is generated). Could there have been anything that would have modified the order between payment initialization and payment complete that would require an order recalculation?
The only other thing I could think could be happening is if you are in a a load balanced environment and if there is something wrong with the cache invalidation and a previous version of the order got re-saved.
Let me know if any of these sound likely?
Many thanks
Matt
Thanks for your reply.
We don't have a load balanced environment.
We do have a review page where the
@Html.BeginPaymentFormis called so the user can be redirected to Buckaroo.The user did go back once from the review page to the previous step. Then the user went to the review page again(Buckaroo is then also called to provide the redirect URL again with a new order number).
Which I think is normal behaviour? The user did pay the second time and the cart wasn't changed between going to the payment and returning from Buckaroo if I can see correct in the IIS log.
Every callback from that specific cart in the IIS log has returned a 500 error. This can also be seen in the Buckaroo portal. Also, this is the only order we know that had this problem. So no big deal.
Ps. I noticed, we do prevent caching(by using the browser back button) on the reviewpage by adding headers to the current response.
Will this cause problems?
Hi Michel,
Hmm, yea, it's ok for a customer to leave the review step and come back. The review step is when the order number is generated (in order to have one set prior to going to the payment gateway) and if they leave and come back, it should get a new order number (as some gateways don't allow processing the same order number twice) so it's completely valid behavior.
I don't think the cache header would be a problem.
I'm really not sure what has happened here for the order number to be removed. To fix the data, you might have to go into the database and give the order the order number you know it should have along with a finalized date if it hasn't already got one. That should at least make the data correct.
Best I can suggest for now is to monitor this and if it happens again, see if there are any similarities in how those orders took place 🤔
Matt
Hi Michel,
Did you continue to get this issue?
We recently had the exact same thing happen to a random order. We cant seem to get to the bottom of it but just thinking if it is a one off maybe we can live with it.
Did you notice this issue keeps popping up through? If so, I probably need to figure out why.
Hi David,
I'm a colleague of Michel, and yes we still have this problem once in a while, let's say around once every 500 orders. We have a manual workflow where we check the order manually and change the database values accordingly.
It's unfortunate, but we could not get to the bottom of this issue. We weren't able to solve, let alone reproduce it on a regular basis, so it's pretty difficult to solve.
Yeah seems like possibly the same thing. I will see if we can find a work around like yourself.
If we get to the bottom of the issue I will let you know what we found out.
I don't know if you ever came to an answer, but we've managed to reproduce a workflow for this in our project.
Basically someone goes through the Vendr checkout all the way to the external payment service provider. In our case Mollie.
The
VendrOrderobject gets assigned anOrderNumberin that last step, which is then forwarded to the external PSP. As far as the PSP is concerned, our orderNumber reference isORDER-01234-56789-ABCDEThe customer starts wondering if they filled in their address information correctly and goes back to the Vendr address information step in their browser.
On this page we have a flow where we call
.SetShippingCountryRegion(). Which sets theVendrOrderobject'sOrderNumberproperty tonull.On the external PSP browser tab the customer pays for their order after they've confirmed their address information to be correct.
VendrOrderobject hasOrderNumbervalue ofnullinstead ofORDER-01234-56789-ABCDESo for us the solution would be to prevent the possibility of resetting the orderNumber for the above situation
Are you saying you call
SetShippingCountryRegionregardless? Or have they changed their address? If they are just continuing without changing anything, then the simplest solutionw ould be for you to check before updating the shipping country region to esure it's actually different. If it's unchanged, then there wouldn't be a need to reset the order number.Made a mistake above, it was actually us calling
SetPaymentMethod(paymentMethod)on thecurrentOrderobject on every pageload forVendrCheckoutInformationPage.This was the bit that reset the
OrderNumberproperty tonull. Resolved it by simply only calling.SetPaymentMethod()whenevercurrentOrder.PaymentInfo.PaymentMethodId == nullWe do call
.SetShippingCountryRegion()when a customer hits submit on theVendrCheckoutInformationPage. Will have to test that scenario tomorrow.. Whether that would cause the same situation and what the workaround should be :)Most likely just adding a check for whether the property is null. Since we only ship to one country, we only need to set it once.
is working on a reply...