Hi Gary,

It's probably the order, which is created with en-gb for its culture. When new baskets are created uCommerce will give them a locale based on the language Umbraco is currently using.

If you don't have a language configure for the hostname Umbraco/ASP.NET will use the browser language. This is where the en-gb is coming from. If you modify your hostname to include en-nz it will work as expected.

I'll test the Create/Request issue you mention.

Hi Gary,

Just tried out the scenario locally, which worked fine. Then tried your site to see if I could recreate it, which, surprisingly, also worked: I get to the PayPal sandbox as expected.

Could you provide me with the steps to repro?

Thanks.

Hi,

Thanks for looking into this for me, Søren. What's the weather like in Pipitea? ;-)

Yes, I fixed (or maybe kludged) my site to work ok.

I can see some orders in the uCommerce_PurchaseOrder table with CultureCode set to en-GB. These are from around the time I was implementing the paypal integration. Orders from before this time, though, were being set up correctly with a CultureCode of en-NZ. I'm guessing that there is something odd happening with the paypal integration, with the implementation of RequestPayment(), or with CreatePayment() when requestPayment is set to false().

I think the issue came down to values in the umbracoLanguage table. I only have one country set up in uCommerce - New Zealand - which I defined with a Culture Code of en-NZ.I stumbled across the umbracoLanguage table and found that it had only one row in it, with a value of en-NZ in the languageISOCode field and a blank in the languageCultureName field. I changed the languageCultureName field to also have a value of en-NZ - which, as I say, may have fixed the problem (it didn't appear to straight away, but maybe that was because I was using a basket that had been defined with a CultureCode of en-GB before I made the change).

I thought about going back and resetting the umbracoLanguage table to the way I found it, to see if the problem reappears, but I'm concerned that this may have unintended consequences.

The other change I made was to replace the call to RequestPayment() in the XSLT script processing the order confirmation with a call to CreatePayment() - reapplying the existing payment and setting both requestPayment and overwriteExisting equal to true(). This seems to me to be more-or-less functionally equivalent to a call to RequestPayment(), except that it changes the paymentId (which I don't really care about) and - for me - it works.

Maybe your code uses Culture from uCommerce_Country in some places and languageCultureName from umbracoLanguage in others?

In any case, my site now works OK. Thanks again.

Wonderful.

The locales stored with the country are never used for language purposes. We leave the selection of the proper language up to Umbraco and do indeed store that value on the order. The reason for this is that you might need to send e-mails after the order is placed in a different language from what the admin user is using, e.g. a Danish user looking at an order placed in the UK.

I have the same issue since updating an existing site to uCommerce 2.1. I don't use email confirmation, I am just getting the error:

Collection was modified; enumeration operation may not execute. Boolean MoveNext() at System.Collections.Generic.Dictionary`2.KeyCollection.Enumerator.MoveNext() at UCommerce.Xslt.TransactionLibrary.RequestPayments() at UCommerce.Xslt.Library.HandledCall[T](Func`1 method)

It happens when calling RequestPayments() in XSLT with default payment service (used for cash on delivery). No PayPal etc. involved.

Have no clue what's going on.

I can confirm that every purchaseOrder has two payment records in uCommerce_Payment, both are also displayed in backend.

If anyone else ran into this issue, this is my workaround:

       public static string RequestFirstPayment() {

            try {
                if(!SiteContext.Current.OrderContext.HasBasket) {
                    return "No basket found";
                }

                var purchaseOrder = SiteContext.Current.OrderContext.GetBasket().PurchaseOrder;
                Payment payment = purchaseOrder.Payments.First();
                UCommerce.Xslt.TransactionLibrary.RequestPayment(payment.Id);
                return "";
            }
            catch(Exception ex) {
                return ex.Message;
            }

        }

Put this into your xslt extension lib and replace RequestPayments() with RequestFirstPayment(). Did the trick for me, but I still wonder why there are two payments since updating to uCommerce 2.1, hmmm...

There's a fix included for this in uCommerce 2.5.

FWIW I've just experienced similar issues in v2.6.1, the site had no hostnames added and so therefore as you mentioned takes the culture from my browser (en-GB) and as a result throws exceptions when attempting to send the order confirmation. The only way to get around it was to add a hostname to the root node with a culture of en-US. This is quite confusing and also not sure if it is necessary to kill the checkout process as a result of there being no hostname.

You could add en-GB as well. I'll look into what the actually error is and see if uCommerce can fallback gracefully to a supported language.

I don't think that adding en-GB is really a solution because whilst it might work for me it wouldn't for you if your browser is using another cutlture?

Agreed. I have created a work item to add a graceful fallback option if the language in play isn't configured in Umbraco.

is working on a reply...