Java Development

[Utel]

Hi everybody,

I need help on 30 days subscription model.

I develop an app wich give access to a chat community. To know if a user can use the chat community, we store the payment status of each user on server side.

After 10 trial messages, user have to buy a monthly subscription. I use the PaymentService API. Actually, the user don't buy the app (we want user can access the app even if he can not send messages...) but an in-app good called "montly subcription" with a 30-day licence type.

The problem is, each time a user try to send a message, we need to check if his payment status is ok on server side. It can't do it on client side, because it would mean that any other people could develop an other app to access to the web service without being charged (it is easy to spy a TCP/IP connection to know wich request to do to the web service...).

Someone advise me to switch to a dynamic licence model. I understood that RIM will then, send us a request with an unique user ID after each successful transaction. Questions are :

1. What is this unique user ID exactly ? Is it the PIN ?

2. Does it depends on the smartphone my client will use ? If yes, What's happen if a user change of smartphone ? Does he loose his subscription ?

3. Will RIM send us a request on a transaction status change (RENEWAL, REFUND, CANCEL..) ?

Thanks in advance.

[Utel]

Hi everybody,

I need help on 30 days subscription model.

I develop an app wich give access to a chat community. To know if a user can use the chat community, we store the payment status of each user on server side.

After 10 trial messages, user have to buy a monthly subscription. I use the PaymentService API. Actually, the user don't buy the app (we want user can access the app even if he can not send messages...) but an in-app good called "montly subcription" with a 30-day licence type.

The problem is, each time a user try to send a message, we need to check if his payment status is ok on server side. It can't do it on client side, because it would mean that any other people could develop an other app to access to the web service without being charged (it is easy to spy a TCP/IP connection to know wich request to do to the web service...).

Someone advise me to switch to a dynamic licence model. I understood that RIM will then, send us a request with an unique user ID after each successful transaction. Questions are :

1. What is this unique user ID exactly ? Is it the PIN ?

2. Does it depends on the smartphone my client will use ? If yes, What's happen if a user change of smartphone ? Does he loose his subscription ?

3. Will RIM send us a request on a transaction status change (RENEWAL, REFUND, CANCEL..) ?

Thanks in advance.

[Utel]

Someone advise me to switch to a dynamic licence model. I understood that RIM will then, send us a request with an unique user ID after each successful transaction. Questions are :

[Utel]

1. What is this unique user ID exactly ? Is it the PIN ?

[Utel]

2. Does it depends on the smartphone my client will use ? If yes, What's happen if a user change of smartphone ? Does he loose his subscription ?

[Utel]

3. Will RIM send us a request on a transaction status change (RENEWAL, REFUND, CANCEL..) ?

[oros]

Hello Utel,

If you haven't already, I would highly recommend the following article outlining digital goods associated with your application:

http://docs.blackberry.com/en/developers/deliverables/33895/Registering_your_virtual_goods_1314130_1...

Some specific areas of interest include:

1) License type: Can be set to a 7 or 30-day subscription model.

2) Initial trial period: Different than "10 uses" but you can set a specific number of days before the user would need to purchase the digital good.

3) Renewal price: To automatically renew a subscription.

Please note that the dynamic license model refers to the license key that the end user is sent. If you use a dynamic model, you will need to supply your own license generation algorithm as outlined in the article above.

Applications, and digital goods, are tied to a users's BBID. If they were to switch devices and re-activate their BBID on that new device, they would have access to their previously purchased items.

I do not believe there is an automatic status change notification that is send to vendors, however through the use of PaymentEngine.getExistingPurchases(), you can query the current status of a digital good to see whether it is purchased. You could use this in conjunction with your 10 trial messages (in lieu of the trial period) to see whether the item is currently purchased before prompting them.

Erik Oros

BlackBerry Development Advisor

[Utel]

Hi,

Thanks for your reply. I've carefully read this documentations.

But, for the matter of security, and to not allow other people to use our chat community service without fee, I need a server side verification process. The aim is to keep my servers continuously aware of any customer payment status (trial period, payed, renewed, canceled, refunded), and to allow them to check it (or to be informed of it by RIM servers).

I want to prevent me from another developer wich could develop a basic application to use our web service with no fee. Since RIM seems to not provide a web service to check a payment ticket on server side, I do not see how to do...

Maybe I miss something... ??
Could you give me more details on how to do that, please ?

Regards.

[oros]

Hello Utel,

You could leverage PaymentEngine.getExistingPurchases() on the application side and submit the data to your servers every now and then (i.e. when the application starts, or have a background application that polls every X amount of time.) You would then have a fairly up to date copy of this information on your servers that you could leverage.

Alternatively, requiring user credentials (i.e. they need to sign up for an account with you in order to use the web service) would also be an approach. Any unrecognized user would be denied access, and you could implement a client-side check on the status of the purchases to ensure they are able to make the necessary calls.

The remainin scenario is a valid user using the alternate application. In that case, you would again need to make the comparison against server-side information which circles back to submitting purchase status information occassionally to your servers.

FInally, instead of polling the status constantly, there is only really one time that you would really need to update the status of the purchase: when the user makes the purchase.  So when they buy the subscription, you could notify your server and set an expiry date for that user/device PIN/etc. On subsequent web service calls, you can check that the request is within the expiry window. You would then only need to update the expiry when the user makes another purchase (i.e. renews their subscription.) This could also be combined with polling on the client-side as a two-tiered check.

Erik Oros

BlackBerry Development Advisor

[Utel]

Hello Erik Oros,

After reading your post, the solution seems to use a dynamic licence with client payment status updates. I undestood the client could give the transaction ID of the last existing purchase and our web service compare it to the known transaction ID for this user.

I still have two questions :
Does the PIN given by RIM payment server is the same PIN used on BlackBerry smartphones ?
Does the web service will be informed of renewal by RIM payment server ? (otherwise, the risk to have fake informations from an alternate application still the same)

Many Thanks.

[oros]

Hello Utel,

Can you please clarify which PIN you are referring to that is returned by the payment server?

As for the renewal, there wouldn't be an automated notification to your server. The subscription virtual goods are designed to give timed-access to specific application functionality and automatically re-charge the customer as required.

It seems the concern here is that a user can create an application themselves to access your public web service and retrieve content directly. You are attempting to leverage virtual goods in order to prevent such access, but it may be simpler to break this down into two main focusses:

1) Limit your in-app functionality based on the status of the subscription by checking PaymentEnginge.getExistingPurchases; and,

2) Retrict access to your Web Service by unauthorized parties. Some idea would be requring user credentials in the request, server-side encryption and client-side decryption of the web service results, etc. This is an implementation that would be dependant on what you feel is most secure but the issue attempting to be solved here (unauthorized access to your web service) is somewhat removed from the purpose of a subscription digital good. The concern isn't just faking a web service request from another application, but from anywhere really (i.e. desktop.)

Let me know if you have any questions.

Erik Oros

BlackBerry Development Advisor

[Utel]

Hi Erik Oros,

Thanks for your reply.

However I still have questions. Maybe I didn't explain myself clearly. Let me exposed this in an other way :

Currently, our customers can access to our service using different connection methods including our BB apps and a web site. Every customer has a user account with a login/password to access to the chat environnement.

After a trial time period, customers have to subscribe to the service. Our general terms specify that the subscription will be renewed automatically, even if the does not connect with the BB app. That means, a user could subscribe on the BlackBerry client application, chat on it, use his account on the web, and use it again on the BlackBerry client application 40 days after, for example.

That's why, UTEL servers must be synchronized with RIM payment server to check customers payment status.  And so, we must be able to process the check regardless of the run or not run of the BB app.

We already implement this kind of process with other vendors plateforms. They provide a web service which allows us to update our customers payment status database from the payment servers.

Does RIM can provide a solution for that ? Could you help me to find a way to do it with BlackBerry ?

Many thanks for your help.

[oros · Accepted solution]

Hello Utel,

I understand more clearly now. Unfortunately, the Payment Service SDK is designed for SmartPhone/Tablet platforms specifically; a similar API for desktop querying (i.e. from a web server) does not exist.

If you are leveraging the Payment Service SDK for this, then automatic renewal/syncing with your own servers will not be possible with an unconnected application (i.e. if the user doesn't run your application.)

One consideration might be to, when the application starts, query your own server for their status. If the status is not valid, prompt the user to make the purchase with the APIs. Upon purchase completion, send another update to your server indicating that this account is good for another X (i.e. 30) days.

The above solves the majority of the problems, except for the automatic renewal. This approach also adds manual re-purchase steps every X days. However, it would address the issue of having the subscription updated from multiple sources, since your server is the first source being checked.

The other approach would be to set up a subscription good for X days that automatically renews. On application start, you could query the status of the good and update your server to match. The issue here is that if the user does not run their application, you can not make that query and your database may not be up to date.

Given these two options, the first would seem to be ideal as the drawbacks are re-purchase every X days, as opposed to potentially out-of-sync database with the second approach.

If we combine the two, we can get a subscription good that automatically renews, and on launch, the application queries the status/updates your server. The only thing missing is that if the application is not run, then this update to your server will not occur from the device side. One workaround may be that any account that has not checked-in (via device or other route) in over the specified amount of time (i.e. 30 days) is considered no longer valid. Then, the next time the user launches their application, that automatic check will take place, update your server, and the customer is good to go again.

Erik Oros

BlackBerry Development Advisor

[Utel]

Hello Erik Oros,

Thank you very for your clear answers.

I think we'll apply the second solution with encryption for client/server communications.

I have a very last question on payment :
With dynamic licence model, RIM payment servers send a request like
PIN=12341234&email=customeremail@email.com&product=product&version=1.2&transactionid=123&test=false

Does the PIN number correspond tothe PIN that we can get on client side with DeviceInfo.getDeviceId() ?

Thanks again.

[oros]

Hi Utel, that's right. The PIN is the unique identifying PIN of the device which can be retrieved with that API.

A sample for converting the int to a hex string can be found here:

http://supportforums.blackberry.com/t5/Java-Development/Blackberry-PIN/m-p/190030/highlight/true#M25...

Erik Oros

BlackBerry Development Advisor