Hi Simon,

Looks like your custom payment provider is trying to load a value from a nullable type with a value of null. You can check for that condition using the HasValue method on the nullable type.

The issue now seems to be resolved although still not entirely sure why it came about or what I did to make it go away. The confusing thing is that it appeared to be thrown before calling any of my custom code e.g. when adding to the basket which was some way before hitting the payment process. That may be down to my getting to grips with the pipelines still.

Thanks, Simon

Hi Soren, I'm getting the same error after a failed payment... which then seems to destroy the basket giving me xslt errors, which I can then only rectify after clearing cookies.

What could be causing the basket cookie to become corrupt after a failed payment?

where should I be looking to try and catch this before it happens?

thanks for you help.

- Tim

I'm still using uCommerce-2.1.0.0 if thats of any help

Now I've remembered my login details I'll add what I mentioned on Twitter a moment ago.

You can avoid the cart getting destroyed by not calling Checkout() -that's probably what's destroying the cart.

In regards the error, that's usually thrown when there's some missing data e.g. payment id (or similar). Have you checked the Umbraco logs, that might give you a little more insight. If not, set umbdebugshowtrace=yes on your form and then you should be able to get a little more insight.

If you think it's a pipeline issue, write to the PurchaseOrder's Audit Trail so you know where in the pipeline it fails.

HTH

Thanks Tim, appreciate the help...

to clarify, after an order's payment fails, If I search for that order number in the backoffice It still says the Order staus is: basket
The checkout() proceedure may be called by the custom payment provider. so perhaps thats where the problem lies (checkout shoulnt be called for failed payments)

only things I can see in my xslt are:
CommerceLibrary:CreatePayment($paymentMethodId, -1, true(), true())
and CommerceLibrary:ExecuteBasketPipeline()

For curiousityies sake I commented out <value>${Checkout.ClearBasketInformation}</value> in the checkout pipeline to see if that would prevent the basket from dying but no luck with that.

thanks for the heads up on further debugging info, hadnt thought to go down the umbdebugshowtrace=yes route.

will post updates here if they are relevant for anyone having a similar issue.

cheers,
- Tim

Given that the Calculate payment total task is failing my bet is on of one the amount fields on your payment is null. Maybe the fee field. Could you take a look at the payment in question and see if any of the numeric fields are null on it? 

Thanks. 

Hi Soren, thanks for the tip
further things to report

I have been trying to track down where the problem lies,
At first glance, I dont think its the pay Payment fee field being blank as I can see a value of 0.00 when I look in the back office.
I do see a null value here on completed payments.. not sure if that really matters though? since its not completed payments that I'm having trouble with.

if I create a new order (so that my basket works), then manually edit my basketid cookie value back to a failed payment's basketid I get the same error (I know thats probably pretty obvious for you, but bear with me)
this led me to think maybe because CompetedDate has a value (in my failed purchaseOrder) instead of NULL this might be where the problem lies, I've then tried to manually set the values of a failed PurchaseOrder with those of a good PurchaseOrder to see whether that might make a difference. no luck there either.

below are 3 purchase orders:
first is failed payment, 2nd is a fresh Purchase Order before payment
and finally my manually modified PurchaseOrder to try to circumnavigate the error

I guess there must be a flag on a table somewhere else that expires a purchase order so basket calls cant be used any more?

OrderId, OrderNumber, CustomerId, OrderStatusId, CreatedDate, CompletedDate, CurrencyId, ProductCatalogGroupId, BillingAddressId, Note, BasketId, VAT, OrderTotal, ShppiingTotal, PaymentTotal, TaxTotal, SubTotal, OrderGuid, ModifiedOn, CultureCode, Discount, DiscountTotal

2068    WEB-729    69    1    2012-10-08 22:45:36.000    2012-10-10 13:05:43.000    6    13    2605    NULL    396E7F6D-221B-4FF3-BE2E-C654384C46FB    33.25    199.50    0.00    0.00    33.25    166.25    8F5A6C51-B06F-43E7-BFEC-A43610584C92    2012-10-10 13:05:44.000    en-US    0.00    0.00

2076    NULL    NULL    1    2012-10-10 15:18:01.000    NULL    6    13    NULL    NULL    E8DA8A72-223E-4B4D-A3DE-B1045BBDFF0C    28.17    169.00    0.00    0.00    28.17    140.83    C99C3701-9C9C-4299-A6C6-F148308E85F4    2012-10-10 15:18:01.000    en-US    0.00    0.00

2068    NULL    NULL    1    2012-10-08 22:45:36.000    NULL    6    13    NULL    NULL    396E7F6D-221B-4FF3-BE2E-C654384C46FB    33.25    199.50    0.00    0.00    33.25    166.25    8F5A6C51-B06F-43E7-BFEC-A43610584C92    2012-10-10 13:05:44.000    en-US    0.00    0.00

Could you post the values from the associated payments from the uCommerce_Payment table? I believe that's where we'll find the issue.

Thanks.

Yep, sure thing
First one is a successful payment, second is a failed payment WEB-729 as above.
as you can see FeeTotal is Null in both.
how to remedy the situation?

PaymentId, TransactionId, PaymentMethodName, Created, PaymentMethodId, Fee, FeePercentage, PaymenStausId, Amount, OrderId, FeeTotal, ReferenceId
804    b72d7a68-c395-48b9-9a2e-e88813ed4a80    HSBC    2012-10-10 13:28:53.000    8    0.00    0.0000    10000006    103.95    2071    NULL    NULL
801    df58dcdf-25ee-430c-b726-b2ba115b4f7d    HSBC    2012-10-10 13:06:23.000    8    0.00    0.0000    10000001    199.50    2068    NULL    WEB-729

The issue is the second last column where FeeTotal is null. You want to assign zero or the total fee the customer is to pay using this particular payment method.

Typically this is done by calling the CalculatePaymentFee method of the payment method service.

Hope this helps.

is working on a reply...