Developer forum

Not a known problem - but we have fixed some concurrency issues with checkouthandlers, but I believe your version contains those.

We have seen some things in your implementations (Espresso) where some async json-ish is happening as part of the checkout flow that has causes issues before. Might be worth checking in dev tools during checkout what chatter happens on xhr/fetch.

In you order log you can see a thread id of each callback. Can you share that information - will tell if it is the same request doing something twice or if it is two different requests doing something once...

BR Nicolai

here is a partial log for an order that has sent out multiple confirmations. 

looks like seperate threads - there are also 1½-3 minutes between each email being sent.

 

The customer has contacted quickpay support, and they say:
 

There is a lot of errors in the monitoring/event viewer:

Seems like sometimes something odd is coming in the callback containing markup. Could be something in the payment form that contains some data send to quickpay and then becomes part of the callback data.

On another note there is a good list of errors that you should look into.

And something we cannot fullyt explain yet is this:

Callback is coming in (and it is slow to execute), then the receipt is coming in. But for some reason the completion of some of your carts are really slow. Maybe export, live integration or something?

But it seems like the callback is 'hanging' and waiting for something causing Quickpay to send another request for callback when no response is coming - timeout something.

...

I have noticed that the site is really slow when navigating around - could also sometimes cause slow responses and then this happens...

But we are not done investigating - but what happens in your end that could cause these delays? CheckoutDoneOrderIsComplete subscribers? Anything integration? Other fancy stuff in the receipt template?

BR Nicolai

There is a live integration running - 99.9% standard integration framework, but an older version.

for the specific request mentioned in the screenshot you included here, the response time from NAV seems to be ok:
1/19/2022 12:14:33 PM: DebugInfo: Request CalculateOrder sent: '<?xml version="1.0" encoding="UTF-8" standalone="yes"?><CalculateOrder><Orders><Order><column columnName="OrderCustomerAccessUserExternalId">Anonymous</column><column columnName="CreateOrder">True</column><column columnName="OrderShopID">SHOP1</column><column columnName="OrderID">ORDER-4147</column>#####SNIP EXTRA######
1/19/2022 12:14:33 PM: DebugInfo: Response CalculateOrder received: '<?xml version="1.0" encoding="utf-8"?><tables><table tableName="EcomOrderLines">##### SNIP ORDERLINES</table><table tableName="EcomOrders"><item table="EcomOrders"><column columnName="OrderCreated"><![CDATA[TRUE]]></column><column columnName="OrderID"><![CDATA[SO422504]]></column>######## SNIP EXTRA COLUMNS </item></table></tables>'.

As far as I know, there shouldn't be anything fancy in the recipt template or the reciept email.

We have written with Quickpay support, and it looks like they get a timeout, which fits with your explanation. 

I will try to deactivate the live integration temporarily, and see if we still get the same problem.

Is there any way we can see the full data that is being sent to/from quickpay? 

Regards, Jonas