I am having a product and its license is gets validated from server. Can any body tell me how many test scenarios i can prepare on this to validate license...?
How do we know how many unless we know how the validation works? ;-)
Well if you server validated based on time try changing the time in the client and valdate.
Change system time (future date) , install app and then change the date to current date and then try validating.
Enter the same license key (if any) in two copies and try validating
You might also want to consider using an off-the-shelf license server scheme like FlexNet. This allows your customer to manage your product licensing along many other licensed products.
Validate whether the license will work for 24 hours or not
Validate whether the license will expire in 24 hours or it will expire in 24:59:59
(Ex: When a license expires in one day then check whether it expires in 24 hrs or same day 24:59:59)
Related
Using oauth we are getting the shop's token with the purpose of using it for creating bills using shopify_api. We successfully create ApplicationCharge and RecurringApplicatiomCharge. The user can confirm or deny that request. But we have a question regarding the RecurringApplicationCharge: will the shopify notify our backend at each withdrawal of money for subscription from the account ? Or should we check the withdrawal fact using API in order to know to prolong the subscription or not?
The charge object has the following attributes:
billing_on
trial_ends_on
activated_on
cancelled_on
Reading the documentation:
billing_on The date and time when the customer will be billed. The
API returns this value in ISO 8601 format.
If you periodically update the charge you can check the next billing_on value. Just be sure to keep checking, if you forget to you won't be able to see previous dates.
There don't seem to be any webhooks for payment notifications of apps.
Recently I renewal my developer account. But unfortunately i didn't delete UDID's from the list. Now it reaches 100. I have 9 months time to again renewal my account. SO how can i add new UDID's ? Is there any chance again to renewal my account for adding/ Managing devices.Please provide me suggestion.
As far as I know there is no way to remove old UDIDs before next license renewal.
So I suggest you to buy second developer license and use it for you needs.
I am implementing a simple server-side verification for Windows 8 IAPs and I'm slightly baffled on how to handle this. Basically what I do know is I verify the receipt using the code that was included in the example
http://msdn.microsoft.com/en-ie/library/windows/apps/jj649137.aspx
In the example, there is a AppReceipt and ProductReceipt. If I understood it correctly, having a simple IAP to buy, for example, gold in the game, I am only interested in the ProductReceipt. However, I don't understand why "AppReceipt" is included here at all. Is the initial app purchase always included in the receipt or is it an optional field?
So an unified way of making sure the user cannot "cash in" the same receipt twice would simply to save the ProductReceipt ID in the back end database? And that this would be a valid approach for both durables and consumables, of which the latter is not yet implemented?
AppReceipt is just an example that you can ignore. In most cases game will send you receipt (ProductReceipt XML) and you will have to verify it on server side.
If you look at: http://social.msdn.microsoft.com/Forums/windowsapps/en-US/8b3cf68d-897d-4a47-ace0-2c42355bf688/protecting-your-windows-store-app-from-unauthorized-use?forum=windowsstore
You will notice:
The ID of each receipt element is unique per user (and device) and you can validate it on your server to confirm that the transaction is legitimate for that user and not a fraudulent transaction. This is especially valuable when your app has its own authentication mechanism because it allows you to validate that each user that appears to have purchased your app is, in fact, a unique customer.
So if you want to, you can extract IDs from this XML.
When a user purchases a subscription, I store the receipt on completed transaction on the server alongside a key to identify the user the receipt belongs to. When the app needs to check if the subscription is still active, it queries the server, the server validates the receipt with Apple and returns info to my app wether the subscription is expired or not.
Now the question is:
When the response returns a latest_receipt/_info field, the server should take that receipt and replace the old receipt for future verifications. What happens if there is a gap in the subscription period (e.g. the user subscribed for 1 month, then cancelled, then subscribed again) or the user changed the subscription type (e.g. from 1 month to 3 moths)?
Will the original receipt still validate, and return a latest_receipt/_info field, or do I need to store a new receipt from the new transaction?
I'm really confused on this auto-renewal thing right now, so I'm not even sure if my validation process is right.
I'm not sure about all possibilities you have to verify receipts and maybe it works your way, but we did slightly different and by that don't face your problem.
We store all the receipts on device-side (note that auto-renews result in new receipts as well). Whenever verification is necessary we post the latest device-stored receipt to server where it is verified by calling iTunes. After that the server responds to device about user's rights.
I think that's the way Apple recommends it (or at least this is how I understood Apple's docs).
I am working on an iPhone app and I want to implement the new model of auto-renewal for in-app purchases. I am able to successfully implement transactions and can even get subscribed to the app, but what if the user cancels the auto renewal subscription?
How will I be able to know that it has been cancelled, and so not continue to allow access (once expired)?
You can find the expiration date of a user's subscription by sending a receipt verification to Apple's servers. Check out figure 1-3 on the In-App Purchase Programming Guide.
Basically the steps are:
On the device, get a transaction receipt for an in-app-purchase. Either one you've saved during a transaction or by calling [SKPaymentQueue restoreCompletedTransactions].
Send that receipt to your server. (This is preferred over trying to do a receipt verification with Apple's servers directly from the app, since that would require you to store your shared secret on the device.)
Send the receipt to Apple's servers from your server, and in the response look for a key named expires_date (expressed in milli seconds since Jan 1, 1970 GMT).
I used this guide to help me on the server side: Verifying Apple App Store Receipts For In App Purchases With PHP and cURL.
There is no way to determine if the user has auto-renewal turned on or off. Apple doesn't give you access to this information. The only way is to wait until the expiration date passes without a renewal.
if the receipt status is 21006 and there is a key named cancellation_date, then it's a cancellation, you can find the new expiration date in that key but it's a formatted date, if you need a better value to parse check for receipt['latest_expired_receipt_info']['cancellation_date_ms'] same as expires_date