value can not be null param name ordernumber

Michel Collard 38 posts 248 karma points

Dec 29, 2020 @ 15:12

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:

,"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.

Copy Link

Matt Brailsford 2958 posts 15629 karma points MVP 7x c-trib

Jan 04, 2021 @ 09:08

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

Copy Link

Michel Collard 38 posts 248 karma points

Jan 11, 2021 @ 14:42

Thanks for your reply.

We don't have a load balanced environment.

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.

  Response.AppendHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1.
    Response.AppendHeader("Pragma", "no-cache"); // HTTP 1.0.
    Response.AppendHeader("Expires", "0"); // Proxies.

Will this cause problems?

Copy Link

Matt Brailsford 2958 posts 15629 karma points MVP 7x c-trib

Jan 12, 2021 @ 10:21

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

Copy Link

is working on a reply...

This forum is in read-only mode while we transition to the new forum.

You can continue this topic on the new forum by tapping the "Continue discussion" link below.

Flag this post as spam?

Value can not be null param. name: orderNumber