Subscription notifications (the followup orders on the subscription) don't have merchant private data from the original order

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Place a subscription order
2. Wait for the next billing cycle
3. Examine notifications for merchant private data from the original order

What is the expected output? What do you see instead?

I expect the merchant private data to remain with the order-summary in the 
shopping-cart element. It's not there.

What version of the product are you using? On what operating system?

This is about v.2.5.0.6, but I just upgraded to v.2.5.0.7 and am assuming that 
this has not been addressed in the latest version.

Please provide any additional information below.

It's important to maintain the merchant private data: I have keys to the 
customer's original subscription product. I need to know which order is to be 
applied to which subscription item. I can't go by BuyerId, because one buyer 
may have several subscriptions. I can't go by the merchantId of the item, 
because they may have purchased several of them - I need to map the specific 
subscrption reorder to the exact subscription in my dB. The only way to do this 
is if you keep the merchant private data from the original order with the 
shopping cart that is part of the re-orders when they come in each month.

Original issue reported on code.google.com by lglath...@gmail.com on 3 Dec 2011 at 6:30

[GoogleCodeExporter]

btw -- I just want to add one more thing. It would have been nice to have a 
flag in the cart as well: a simple boolean value that tells me if the order is 
a subscription re-order versus a subscription initial order. The more important 
issue right now is as described -- retain and pass back my merchant private 
data for each re-order

Original comment by lglath...@gmail.com on 3 Dec 2011 at 6:33

[GoogleCodeExporter]

sorry ... one more note: I tried to trap the exception (when the merchant 
private data is missing) with the following code, but I get an object reference 
error that the Try-Catch block fails to catch. It actually doesn't trigger the 
execption here but in an outer Try-Catch that surrounds this one. If you will 
include the merchant private data every re-order, then this will not be an 
issue. If you decide to 'NotFix' that request and continue to leave the 
merchant private data out, then I hope you'll be able to explain why this 
Try-Catch fails when the merchant private data isn't present:

Try
  If notification.ordersummary.shoppingcart.merchantprivatedata Is Nothing Then
    'Log that the merchant private data isn't present
  Else
    'Use the merchant private data
  End If
Catch ex As Exception
  'Log the error
End Try

This whole block fails and 'object reference not found' is caught by an outer 
Try-Catch block that surrounds this one. Why isn't this catching that the 
merchant private data tags are not present in the notification XML?

Original comment by lglath...@gmail.com on 3 Dec 2011 at 6:48

[GoogleCodeExporter]

ANOTHER ISSUE: The item elements in the subscription is missing the 
merchant-item-id ... 

<shopping-cart>
      <items>
        <item>
          <item-name>SellRex Webstore</item-name>
          <item-description>For test.sellrex.com</item-description>
          <unit-price currency="USD">1.0</unit-price>
          <quantity>1</quantity>
        </item>
      </items>
    </shopping-cart>

We need the merchant-private-data from the original order in the shopping-cart 
elements (as described above) + the merchant-item-id:

<merchant-item-id>XXXXXXXXXXX</merchant-item-id>

added to those other item elements. Thanks -- Luke

Original comment by lglath...@gmail.com on 4 Dec 2011 at 4:54

[GoogleCodeExporter]

Is this issue only when the subscription goes up for renewal or in the original 
message?

In non subscription conditions, the merchant private data has worked for over 4 
years without an issue.

Original comment by joseph.f...@gmail.com on 9 Dec 2011 at 10:27

[GoogleCodeExporter]

If it is only when the orders come later, we need to open a case with Google 
since I have no way to control the xml coming from them.

Have you logged the raw xml to see what the message is coming over the wire?

Original comment by joseph.f...@gmail.com on 9 Dec 2011 at 10:29

[GoogleCodeExporter]

It is when the new orders come later. When the initial subscription order 
arrives, all of the merchant private data is there. When the order then goes 
onto weekly/monthly/etc. billing cycyle, the orders come in without the 
merchant private data. Here is the main problem with the current scenario:

1. If you have merchants under one BuyerID who purchase multiple subscriptions
2. If the subscription is exactly the same item (i.e., same MerchantItemId)
3. The new orders have no other distinguishing entries to tie them back to the 
exact initial order (i.e., if the merchant private data is missing)
4. THEN ... You have no reliable way to attach subscription recurring orders 
(the future billing cycle orders) back to the individual subscription purchases.

So, imagine a situation such as with our product, SellRex eCommerce shopping 
cart ( http://www.sellrex.com/ ): One merchant of ours may setup and start 
using several different webstores. They are ordering the exact same item (same 
MerchantItemId), but they are on different billing cycles. When future orders 
come in on each subscription, our system has no way to tie each order back to 
each individual subscription to properly credit the billing cycle.

You can't use BuyerId, becuase that is on our system mapped to several 
subscription orders from them. You can't user OrderId ... that is unique to 
each new order -- there is no node that tells you what the original OrderId is. 
You can't use MerchantItemId ... they have multiple subscriptions of that one 
item. There is no unique way to do this unless Google adds the merchant private 
data to the order summary of ALL reorders that come in later on the 
subscription. If they will add that data, we have a special code in our 
merchant private data that will key it properly back and allow us to get the 
right subscription credited.

I also want to point out that something really should be changed in the .NET 
client API to properly report "Nothing" in the 
notification.ordersummary.shoppingcart.merchantprivatedata when it isn't 
present. My workaround at the moment is to use the cheesy:

If requestXml.Contains("merchant-private-data") Then ...

That's pretty sad that I have to do a string search to find out if the XML is 
missing. Yes, I know I can use XML parsing/searching (XPath query for example), 
but I found out in testing that that method is much slower than just searching 
for the string in the XML.

AND---- Still no answer on my other request. There should be a indication in 
the XML for 'subscription-order' maybe set to 'initial' or 'reorder' or 'false' 
-- just to make it easy to distinquish all three conditions in one tag without 
having to do one boolean node for subscription as 'true' or 'false' and 
subscription-reorder node as 'true' or 'false'. Some kind of flagging would be 
helpful either way.

Original comment by lglath...@gmail.com on 9 Dec 2011 at 11:51

[GoogleCodeExporter]

oh ... and YES ... I have been trapping all of the XML. Let me know if you want 
me to paste in the entire XML. I have that and can do it if you want to see all 
of it. I'm sure the Google engineers are well aware that the subscription 
reorder XML lacks the ordinary merchant-private-data block --- but let me know 
if you want to see all of that.

Original comment by lglath...@gmail.com on 9 Dec 2011 at 11:53

[GoogleCodeExporter]

It's been a month. Is this the correct forum to post for Google Checkout 
issues? If not, can someone let me know how to request this update? Thanks

Original comment by lglath...@gmail.com on 4 Jan 2012 at 7:55

[GoogleCodeExporter]

I posted this over in the Google Checkout beta forum, where this issue was 
brought up by another developer. There is also a workaround over there ... put 
the merchant-private-data into one or more of the items on the order. 
Apparently, the item-level merchant private data does get persisted. I haven't 
tested that yet, but I will soon ( 
https://groups.google.com/a/googleproductforums.com/forum/#!category-topic/check
out-merchant/checkout-betas/DXeS-_5b6LA ).

If the keepers of the .NET client library have connections with those 
developers, I hope they'll try to get this on the To Do List over there. Thanks.

Original comment by lglath...@gmail.com on 8 Jan 2012 at 7:41

[GoogleCodeExporter]

lglatham2 since you did not know if it was a code or an api issue you posted it 
in the correct place. It is an issue with the api.

Original comment by joseph.f...@gmail.com on 3 Aug 2012 at 2:59

• Changed state: Invalid

[GoogleCodeExporter]

Thanks for the update. Can you remove my username from your last post? ... 
thanks.

Original comment by lglath...@gmail.com on 3 Aug 2012 at 3:07

[GoogleCodeExporter]

And - I don't get why you marked this issue "invalid." We shouldn't have to 
hack the merchant private data into individual items to preserve it 
reorder-to-reorder. The order level merchant private data is the only way to 
track an initial order when the subscription orders come in later. I don't 
think it's an "invalid" concern.

Original comment by lglath...@gmail.com on 3 Aug 2012 at 3:09

[GoogleCodeExporter]

I changed it to wontfix since it is a known issue with the api and I am not 
able to do anything on my side to fix the issue.

I have talked to the team and they are getting back to me on an ETA.

Original comment by joseph.f...@gmail.com on 8 Aug 2012 at 2:11

• Changed state: WontFix

[GoogleCodeExporter]

Awesome -- thanks.

Original comment by lglath...@gmail.com on 8 Aug 2012 at 2:18