Async callback to payment processor does not finalize the order?
Hi,
I have my uCommerce working with the ePay payment provider, and the async callback from ePay back to the shop goes through as expected (there's a neat little log in ePay that confirms this, and I can also see the TransactionId for the order being updated in the uCommerce_Payment table). Setting it all up was quite hazzle free btw., thank you for making things easy!
Now... I'd expect the order to appear in the uCommerce backend under "New orders" when the callback has been executed. But it does not. I have to explicitly return to my shop (which requires the user to click a button in the ePay payment window) and have my XSLT call CommerceLibrary:Checkout() for the order to appear under "New orders". That really is problematic since there's no guarantee that the user will actually do this, nor that the return request actually goes through (in case of lost internet connections, mac crashes etc).
To make matters worse, when I eventually do call CommerceLibrary:Checkout() to make the order appear in the uCommerce backend, the order reference number has been incremented by one, compared to the reference number displayed in the ePay payment window. Diving back into the database also confirms this - the ReferenceId in the uCommerce_Payment table is "Reference-[number]" and the OrderNumber in the uCommerce_PurchaseOrder table is "Reference-[number + 1]" for the same order. Suspicious.... kinda makes me think I'm doing something wrong altogether.
Is there some kind of pipeline configuration I can fiddle with for the payment processor to make this work so: 1. The order shows up under "New orders" when it has been invoked 2. The order keeps the same reference number on the order as given to the payment provider
It seems your has the proper status set (Authorized) so your store is reachable from the internet.
Does your ePay payment method have the "checkout" pipeline configured?
Are you seeing any errors in the umbracoLog table? When something like this happens it's usually due to a bad SMTP server config or the stores is unable to request local content. You can check the latter by doing a remote desktop to the server and requesting a piece of content using the domain name of the site, e.g. www.mystore.com/whatever.aspx
If you can't resolve the hostname locally, the simplest fix is to assign the hostname www.mystore.com to IP 127.0.0.1 in your hosts config.
Than you for your answer - that helped some. Now I have the checkout pipeline executing on async callback, and the order ends up in "New orders" as soon as the payment has been processed by the payment window. Excellent!
However, the problem with the order reference numbers still persists. When I track the DB changes step by step I can see, that "ReferenceId" is set to "Reference-[number]" in "uCommerce_Payment" when I call CommerceLibrary:CreatePayment(...), and the "OrderNumber" is set to "Reference-[number+1]" in "uCommerce_PurchaseOrder" when the checkout pipeline is executed.
I tried removing the "Checkout.AssignOrderNumber" task in the checkout pipeline, but that just resulted in no order number being assigned to the order. Is it possible that the "Checkout.AssignOrderNumber" task does not take into account what's set in "uCommerce_Payment" for the order and simply adds the next order number to "uCommerce_PurchaseOrder"?
Nope. I only call CommerceLibrary:CreatePayment([payment method], -1, true(), true()) which sends me to the ePay payment window. It doesn't look like the checkout pipeline does either... it's configured like this:
uCommerce works this way by design. It uses the order number series (uCommerce -> Settings -> Orders -> Order Numbers) both for creating unique payment reference IDs and for creating unique order numbers.
In other words, uCommerce creates two order numbers for each order when using a payment provider like ePay; one for the payment and one for the order itself. So, if uCommerce has been configured to use the same order number series for both the payment and the order, the orders in uCommerce will appear to be skipping one order number for each new order... the skipped order numbers have then been used for the payment reference IDs.
FYI: The payment reference ID assigned to an order can be found on the "Shipping" tab of the order along with the rest of the payment info for the order.
I guess the best practice would be to have two order number series - one for generating payment reference IDs and one for generating order numbers. That way you won't get the "skipping order numbers" in the list of orders. You can choose the applicable order number series explicitly on your product catalog groups.
Async callback to payment processor does not finalize the order?
Hi,
I have my uCommerce working with the ePay payment provider, and the async callback from ePay back to the shop goes through as expected (there's a neat little log in ePay that confirms this, and I can also see the TransactionId for the order being updated in the uCommerce_Payment table). Setting it all up was quite hazzle free btw., thank you for making things easy!
Now... I'd expect the order to appear in the uCommerce backend under "New orders" when the callback has been executed. But it does not. I have to explicitly return to my shop (which requires the user to click a button in the ePay payment window) and have my XSLT call CommerceLibrary:Checkout() for the order to appear under "New orders". That really is problematic since there's no guarantee that the user will actually do this, nor that the return request actually goes through (in case of lost internet connections, mac crashes etc).
To make matters worse, when I eventually do call CommerceLibrary:Checkout() to make the order appear in the uCommerce backend, the order reference number has been incremented by one, compared to the reference number displayed in the ePay payment window. Diving back into the database also confirms this - the ReferenceId in the uCommerce_Payment table is "Reference-[number]" and the OrderNumber in the uCommerce_PurchaseOrder table is "Reference-[number + 1]" for the same order. Suspicious.... kinda makes me think I'm doing something wrong altogether.
Is there some kind of pipeline configuration I can fiddle with for the payment processor to make this work so:
1. The order shows up under "New orders" when it has been invoked
2. The order keeps the same reference number on the order as given to the payment provider
..? Or is there another solution?
I'm running uCommerce 2.6.1.0
Kind regards,
Kenn
Hi Kenn,
It seems your has the proper status set (Authorized) so your store is reachable from the internet.
Does your ePay payment method have the "checkout" pipeline configured?
Are you seeing any errors in the umbracoLog table? When something like this happens it's usually due to a bad SMTP server config or the stores is unable to request local content. You can check the latter by doing a remote desktop to the server and requesting a piece of content using the domain name of the site, e.g. www.mystore.com/whatever.aspx
If you can't resolve the hostname locally, the simplest fix is to assign the hostname www.mystore.com to IP 127.0.0.1 in your hosts config.
Hope this helps.
Hi Søren,
Than you for your answer - that helped some. Now I have the checkout pipeline executing on async callback, and the order ends up in "New orders" as soon as the payment has been processed by the payment window. Excellent!
However, the problem with the order reference numbers still persists. When I track the DB changes step by step I can see, that "ReferenceId" is set to "Reference-[number]" in "uCommerce_Payment" when I call CommerceLibrary:CreatePayment(...), and the "OrderNumber" is set to "Reference-[number+1]" in "uCommerce_PurchaseOrder" when the checkout pipeline is executed.
I tried removing the "Checkout.AssignOrderNumber" task in the checkout pipeline, but that just resulted in no order number being assigned to the order. Is it possible that the "Checkout.AssignOrderNumber" task does not take into account what's set in "uCommerce_Payment" for the order and simply adds the next order number to "uCommerce_PurchaseOrder"?
-Kenn
Are you executing CommerceLibrary:Checkout() at any point?
Hi,
Nope. I only call CommerceLibrary:CreatePayment([payment method], -1, true(), true()) which sends me to the ePay payment window. It doesn't look like the checkout pipeline does either... it's configured like this:
<tasks>
<array>
<value>${Checkout.ValidatePaymentsMadeAgainstOrderTotal}</value>
<value>${Checkout.AssignOrderNumber}</value>
<value>${Checkout.CreateCustomer}</value>
<value>${Checkout.CreateMemberForCustomer}</value>
<value>${Checkout.ConvertBasketToPurchaseOrder}</value>
<value>${Checkout.AddAuditTrailForCurrentOrderStatus}</value>
<value>${Checkout.SetVoucherUses}</value>
<value>${Checkout.ClearBasketInformation}</value>
<value>${Checkout.SavePurchaseOrder}</value>
<value>${Checkout.SendConfirmationEmail}</value>
</array>
</tasks>
Alright, fixed by email (thanks, Søren).
uCommerce works this way by design. It uses the order number series (uCommerce -> Settings -> Orders -> Order Numbers) both for creating unique payment reference IDs and for creating unique order numbers.
In other words, uCommerce creates two order numbers for each order when using a payment provider like ePay; one for the payment and one for the order itself. So, if uCommerce has been configured to use the same order number series for both the payment and the order, the orders in uCommerce will appear to be skipping one order number for each new order... the skipped order numbers have then been used for the payment reference IDs.
FYI: The payment reference ID assigned to an order can be found on the "Shipping" tab of the order along with the rest of the payment info for the order.
I guess the best practice would be to have two order number series - one for generating payment reference IDs and one for generating order numbers. That way you won't get the "skipping order numbers" in the list of orders. You can choose the applicable order number series explicitly on your product catalog groups.
Thanks for being awesome and posting the follow up in the forum.
is working on a reply...