Restoration didn't work using "production" server (In-App/Qt-/Symbian)

[felipecrochik]

When I try my application using the test server any time I try to purchase a product (after the first) I am presented with the login to the ovi store screen and then get a message saying that "no payment is needed" and my application gets the "purchase complete signal" like it was purchased for the first time. Exactly the behavior I would expect.

The exact same code (after I remove the test_mode.txt file and change the IAP_VARIANTID.txt to my product Id) just ignored that I had purchased the same product and presented all the screens like it was the first time - I ended up being charged for my application again

When I tried to check for upgradable products using the same account I get one as expected but when I try to restore it I get a RestorationNotSupported error.

Is this a BUG on the production server? Is it a delay before the product can be restored after being purchased the first time (even if shows as restorable)?

Thanks in advance
Felipe

[izinin]

Hi Felipe

It looks like there is application packaging problem. Please let me know more about your application to move further in the problem analysis

1. please detail what IAP model your application is to implement : either Nokia DRM or non-DRM, subscription model?
2. you say you have changed VARIANTID.txt content with your production id value, how did you obtain that? The point is product id, if i understand you correctly, shall not be coded in VARIANTID.txt. This file must contain your application ID. Application ID is allocated by OVI Store and updated in VARIANTID.txt during the application signing and DRM encrypting automatically by OVI Store. Application ID initial value is '000000' -- six zeroes. You shall never change it manually.
3. And you mention IAP_VARIANTID.txt is it correct filename in your application?

Regards,
Igor

[felipecrochik]

Hi Felipe

Hi Igor,

[*]please detail what IAP model your application is to implement : either Nokia DRM or non-DRM, subscription model?

I am not using DRM. I just call

pIAPClient->purchaseProduct(productId, IAPClient::ForcedAutomaticRestoration);

When using the testserver (normal mode) after I login I get a simple message saying that no payment is necessary and my application gets the purchaseCompleted signal. When I use the production server after login the I am presented with the "price screen".

[*]you say you have changed VARIANTID.txt content with your production id value, how did you obtain that? The point is product id, if i understand you correctly, shall not be coded in VARIANTID.txt. This file must contain your application ID. Application ID is allocated by OVI Store and updated in VARIANTID.txt during the application signing and DRM encrypting automatically by OVI Store. Application ID initial value is '000000' -- six zeroes. You shall never change it manually.

This may be the problem. I had the 6 digits Application ID assigned to my in-app purchase on VARIANTID. The purchase worked just fine, only the restoration failed. I will give it a try with all zeroes.

[*]And you mention IAP_VARIANTID.txt is it correct filename in your application?

Yes.

Regards,
Igor

Thank you,
Felipe

[felipecrochik]

I changed the IAP_VARIANTID.txt to all zeroes and didn't make any difference as was expected since the issue seems to be with the server side not client.

Is this related to this other issue: http://www.developer.nokia.com/Commu...l=1#post885222

Any other ideas? Is it even worth to worry about the IAP with we can only deploy to a VERY LIMITED set of devices?

[izinin]

Hi Felipe,

IAP_VARIANTID.txt name is correct , if your application has been gone through OVI Store publishing process it has assigned application ID as you mentioned

I had the 6 digits Application ID assigned to my in-app purchase on VARIANTID

-- six zeroes here must be for application before publishing on OVI. So it seems all is correct here

There is only one point : non-DRM model or in other words "subscription model" does not support purchase restoration and you mentioned about having RestorationNotSupported error in the log. Subscription model implies you have to implement a product resource server that will have logic around purchase handling, in this case OVI provides only purchase ticket verification API and UI purchase flow on device. Purchase restoration you have to implement yourself for example by this sequence :

1. user selects a product from catalog list
2. the application obtains user and device id and passes that data along with product id to the resource server
3. the resource server checks by using Purchase Ticket Verification API whether requested product has been bought by this user and device id combination (you can minimize network data round-trip by using a database on server side where to store purchase tickets)
4. if user request for a product is found to be already bought you can allow user to download the item (that will be restoration) or force him to buy the item once again (as it is common for subscription model)

For more details how to implement non-DRM IAP please check
Purchase and restoration with no built-in DRM protection , Purchase Ticket Verification API and sample application found in IAP SDK iap_qt_sdk_0.3.1_24.01.12\Examples\InApplicationPurchase\BuyAndDownloadExample

As Belle supporting it temporary problem with highest priority to solve -- i sure you will not waste your time on IAP implementation.

if you have more questions please ask.

[felipecrochik]

I am not sure we are on the "same page" about this. Let me try again:

This is the flow I would like to see - it makes sense and that currently works with the testserver on "Normal" mode:

1. use clicks a button; my application calls pIAPClient->purchaseProduct(productId, IAPClient::ForcedAutomaticRestoration);
2. Ovi "client" takes over and ask user to enter credentials
3. Ovi client presents product information, including price and "default" method of payment
4. User clicks "Buy"
5. Ovi client presents "thank you" screen
6. User clicks "OK", Ovi client closes and sends signal purchaseComplete to my application

...User happily plays with the application for a long time and eventually has to reinstall it, then:

1. use clicks a button; my application calls pIAPClient->purchaseProduct(productId, IAPClient::ForcedAutomaticRestoration);
2. Ovi "client" takes over and ask user to enter credentials
3. Ovi client check user/in-app content id and realize the user has purchased it already
4. Ovi client presents window saying "No payment is necessary"
5. User clicks "OK", Ovi client closes and sends signal purchaseComplete to my application

What my application does after the purchase signal does not really matter.
IMPORTANT: This entire flow currently WORKS using the test server in normal mode.
When I tried on the production server it failed to recognize that the user had already purchased the product and presented the regular buy flow.

[izinin]

hi

Please pay your attention on the fact that non-DRM model does not support purchase restoration despite you pass IAPClient::ForcedAutomaticRestoration flag value to the purchase call. That is per documentation and that is implemented.
Restoration in test mode works for the both models and that confuses you. That is a side effect - it can be considered as a bug

IAP models are distinguished by OVI store during publishing process. DRM protected model must have predefined directory structure in the application package, non-DRM can be any.

Perhaps you need to make your application to follow DRM protection model that is only way how to employ already made restoration functionality. BTW it is based on licensing mechanism -- after purchase is done license is deployed on device.

sorry for miscommunication -- but there is the only one way how to get on "the same page"

[izinin]

Hi

i submitted bug report on that IAP behaviour saying:

IAP non-DRM model does not support product restoration. But it does support it in the application test mode. That fact gives developers wrong assumption this IAP behavior will remain in the application release version. Moreover non-DRM model product restoration is not accented enough in the documentation and can be easy overlooked during project estimation phase. This wrong assumption leads to design error that is very costly to fix

Thank you for rising that issue

[felipecrochik]

Since I got more people interested in looking into this, let me review it:

When I try to purchase a content for the second time with the same account using test mode, this is the partial log:

[Qt Message] addService("c:\resource\apps\xmldata\iapservice.xml") returned  5 
[Qt Message] loadInterface("com.nokia.qt.IAP") returned  0 
[Qt Message] --> IAPClientImpl::IAPClientImpl(QObject *) 
[Qt Message] --> IapTestMode::IapTestMode(const QString &, QObject *) 
[Qt Message] IapTestMode::readTestModeFile: test mode "testserver" "testMode" "Normal" 
....
[Qt Message] --> void IAPClientImpl::socketReady() 
[Qt Message] IapUtil::readFromSocket() received  1922  bytes 
[Qt Message] IapUtil::readFromSocket(): message of 1922 bytes 
[Qt Message] "SERVER => CLIENT MESSAGE: Message id: PURDONE, Request id: 1, Status: OK" 
[Qt Message] IAPClientImpl::socketReady(): Request  1 , status= "OK" , purchaseTicket= "PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9InllcyI/PjxQdXJjaGFzZVRpY2tldCBzaWduYXR1cmU9IjdmZDFjNTk4M2E3MjA5MDEwOTdmMWM2ZWQ1NDgwNjNiODQzNjM4MTEiIG
...
[Qt Message] <-- void IAPClientImpl::socketReady() 
[Qt Message] ::. purchaseCompleted with status:  "OK"

and on the phone screen immediately after I log in I see this:


When I try exact the same thing but not including the TEST_MODE.txt file (production mode):

[Qt Message] addService("c:\resource\apps\xmldata\iapservice.xml") returned  5 
[Qt Message] loadInterface("com.nokia.qt.IAP") returned  0 
[Qt Message] --> IAPClientImpl::IAPClientImpl(QObject *) 
[Qt Message] --> IapTestMode::IapTestMode(const QString &, QObject *) 
[Qt Message] IapTestMode::readTestModeFile: test mode is not used

It repeats the same flow of when I first purchased presenting me with the payment confirmation screen and if I click the confirm button it bills me again for the same content on the same account (just received my bill from AT&T).

p.s. I don't have the log with me right now (will have to change the code again) but when I tried to use the m_pIAPClient->getRestorableProducts(); on the production server I get the ID for the content but it gives me some "unexpected" error (that I don't remember) when I try to call m_pIAPClient->restoreProduct(productId); I am sure it also did work when using the test server. Of course, the ideal scenario is that we shouldn't even need to go trough the restore products flow and the server would just not bill the second time - EXACT THE BEHAVIOR I SEE WHEN USING THE TEST SERVER.

[felipecrochik]

Hi,
I don't think the issue is with the DRM (or not). Hopefully my previous post will clear it out. Again, it WORKS on the test server - it just DOESN'T work after I start using the production server and it all happens before any DRM/non-DRM would be involved.
Thanks,
Felipe

Hi

i submitted bug report on that IAP behaviour saying:

IAP non-DRM model does not support product restoration. But it does support it in the application test mode. That fact gives developers wrong assumption this IAP behavior will remain in the application release version. Moreover non-DRM model product restoration is not accented enough in the documentation and can be easy overlooked during project estimation phase. This wrong assumption leads to design error that is very costly to fix

Thank you for rising that issue

[derconny]

Hi,
I don't have a straight answer, but I can tell you that I had similar issues with IAP. There is a lot of confusion whether or not to the store tracks non-DRM purchases. And, like you, I stumbled over the problem that the store works different in production and testing mode. Personally I think the store should remember all items that a user bought and thus offer automatic restoration if the developer wants to. That should happen whether or not the item is using DRM. But well..

Now what I currently do is that I take care of the restoration process completely by myself. My IAP downloads are on my own backend server (Django) so I use that to store which user bought what. I'm using the store API only to get the price of an item, to get the user ID and to actually buy something. Doing a restore completely bypasses the store.

This surely not the fastest way to implement it (and it also has its drawbacks), but for me it was the closest I could get to an actually working app.

Cheers,
Conny

[izinin]

Hi,

This is exact way as non-DRM IAP model shall be implemented (according to IAP documentation non-DRM model does not support purchase restoration. IAP behavior in test mode is a bit misleading)

Now what I currently do is that I take care of the restoration process completely by myself. My IAP downloads are on my own backend server (Django) so I use that to store which user bought what. I'm using the store API only to get the price of an item, to get the user ID and to actually buy something. Doing a restore completely bypasses the store.

[felipecrochik]

If that is by "design" I have to ask WHY? It doesn't make sense... The "server" MUST know that the "X" user bought the content "Y". It is SO MUCH CLEANER the way the TEST server works.
I have to say that I don't buy that this is BY DESIGN and not a DEFECT: the production server returns a list of "restorable" products but just give you an error when you tell it to restore one.
IAP can be the best add-on Nokia offered to developers since Qt, just get it right!
It can't be too hard to get the production server to work as the test - I don't see how anybody would loose anything and it is probably easier than getting the test server to not work as the production

Hi,

This is exact way as non-DRM IAP model shall be implemented (according to IAP documentation non-DRM model does not support purchase restoration. IAP behavior in test mode is a bit misleading)

[izinin]

Hi

IAP non-DRM model does not support purchase restoration because non-DRM model does not employ device License Manager functionality -- it is not a defect but a freedom to developer to implement their own logic of product handling. Product restoration is based on License Manager. If you need product restoration why don't you select DRM model and deploy your items to sell bundled with your application?

[rstalin]

Hello I have the same problem.
But my problem is more serious because my app have published.

I don't notice the problem until got customer complaint,
I have unpublished and request Nokia support to unpublish
many time still can see my app in the store.

I remember to test IAP beta last year .
Even I use non-Drm item and purchase again can still restore in release version.
It seem can't restore from upgrade .
It's also impossible to use DRM.
If using drm, i can't request ovi sign because capability problem...
Now I have no idea to do
I think the problem is very serious defect.
No wonder no one want develop new app for symbian...
So many problems!!