I have a bunch of IAPs in my iOS application, and I have implemented receipt validation for the IAPs.
I'm wondering what error handling I should be doing if the receipt validation request fails.
So, say you have a user who legitimately purchases one of the IAPs, the transaction was successful but the request to verify the receipt fails for whatever reason (e.g. no connection, Apple's server is down). I assume that the user will have been charged because the transaction was successful, but as the validation failed the user will not have been given the content.
What should I do in this situation? I know it might be a rare case but I want to account for it anyway.
I was thinking I could save the receipt to persistent storage and retry the receipt validation in the background until it succeeds. Is this a viable option? Do the receipts remain valid forever or do they expire after a certain amount of time?
I couldn't find much information on this from Apple's documentation so I'm asking you guys.
Thanks in advance
Related
I am trying to implement StoreKit's ability to have automatically renewable subscriptions in my macOS application.
After reading dozens of pages and checking examples, I understand how everything fits together but fail to get it to work correctly.
What I am trying to do:
As soon as the app starts, check if an active subscription is available by evaluating the local receipt. I'm specifically checking the unavailability of a cancellation date in any of the In-App Purchase field entries of the receipt and whether the subscription expiration date is in the future.
In case no (active) subscription is available, I'm purchasing the subscription using StoreKit's APIs.
Both scenarios are working fine as this flow works perfectly when the subscription is purchased for the first time. However, the receipt does not get updated automatically after the subscription expiration date ends. I'm expecting this receipt to be updated periodically as also shown on Auto-renewing subscription and app receipt. As a result the first step described above fails because the expiration date at some point is in the history and hence, is considered expired.
Two things I find strange:
My SKPaymentTransactionObserver instance only gets called after purchasing the subscription (after a user explicitly buying it). It never gets called when the subscription expires and should automatically renew (as shown in the above blog post);
Explicitly asking my receipt (containing the IAP's expiration date) to be updated using the SKReceiptRefreshRequest API fails by calling it's request:didFailWithError: delegate method. The error object is nil so I cannot see why it fails updating.
I can share code but I have a feeling this is not related to code but instead is some kind of project/environment setting and/or behaviour I do not fully get.
Do you have any suggestions what to try?
After a few days of experimenting I changed the mechanism to use the server-side validation documented on https://developer.apple.com/library/content/releasenotes/General/ValidateAppStoreReceipt/Chapters/ValidateRemotely.html#//apple_ref/doc/uid/TP40010573-CH104-SW1. Obviously this requires a web service running somewhere and makes your environment more complicated but at least things work in a more stable (and secure) way.
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.
I'm working on a project that require my application to pay the user to his paypal account when he asks it.
Here's how I did it so far:
The (logged) user goes to the Pay page that will list all his Payments (received or not)
He enters his Paypal email and his application (mine) password (for security)
The POST page get a list of all the Payments that have status="UNPAID" for that user and update the status to "WORKING" (to avoid the user to refresh the page before the whole process is done and resend the same amount of money)
We count the total amount to pay in that list (a simple for)
The amount is sent to Paypal via Paypal Adaptive Payment API (request: PAY)
The response is checked, if completed, the list status is set to "COMPLETED", if not, the list is reverted to "UNPAID" (the SQL update is made via a WHERE id IN(x, y, z) in case a second Payment request has been made during that time.
A message is then displayed to the user
But I need your help, I'm in front of one risky problem I'd like to avoid, and I would know how you would do:
If the user hit refresh on the process page, I don't want to send him twice (or more) the amount (The "WORKING" lock is here for that, but what happens if the user hit refresh before I set the lock ?)
Rare possible: what happens if the user hit f5 after the lock "WORKING" is made, but before the request to paypal, and a new payment is received. By following what I did, just one item (the new) would be get and set to WORKING, but all others previous payment would be losts
How would you do? What is the best way to make it to be 100% reliable?
Thanks for your help
Note:
The steps between 4 to 6 is made via a PlayFramework jobs, called with now() and awaiting() the result
you can:
prevent double post via JQuery
use the checkAuthenticity() method to validate the request
do a GET redirect after processing the POST (so they can't submit the same 2 times even by mistake)
do the payment processing asynchronous (see below)
For the payment, instead of calling the job, set the id's of payments in a queue (or table in the database) and a job that runs once per minute that processes that table if it has some data. When the user does the POST you redirect to a page that says that you are processing the payments and will notify if there is some issue. You can notify the user later via a UI warning using comet or via mail.
That way you don't link the request to the processing, and you won't have threading/racing issues, as well as being able to detect stale requests (payments already done) if you do a sequential processing.
I have a subscription based website that interacts with a 3rd party system to handle the payments. The steps to process a new subscriber registration are as follow:
The subscriber enters his/her details in the subscription form and click on the submit button.
Assuming the details specified are valid, a new record is created in the database to store these details.
The subscriber is then redirected to the website of the 3rd party system (similar to paypal) to process the payment.
Once the payment is succesful, the 3rd party website then redirect the subscriber back to our website.
At this time, I know that the payment was succesful, so the record in the database is updated to indicate that payment has been made successfully.
A problem that I have found occurring quite often is that if a subscriber pays but does not complete the process correctly (e.g. uses the back browser, closes the window), his/her record in the database doesn't get updated about this. Accordingly, I don't know if s/he has paid by just looking the record and need to wait for the report from the 3rd party system to find this out.
How do you solve this problem?
PS. One of the main reasons to store their details into the database before the payment process is done is so they can come back to complete the payment without re-entering their details again. For example, when their credit cards were rejected by the 3rd party system and they need to sort this out with their financial institution which may take a while.
The third-party payment system should inform you of the successful transaction regardless of what the user does.
For example, in PayPal, an IPN (instant payment notification) is sent to your server as POST data to a URL that you specify. Your server then verifies with Paypal that the transaction is genuine, and if so, updates the database record to indicate the subscription is valid. At a point in the future, PayPal may or may not then redirect the user back to your website. (The "may not" can occur in cases such as the user closing their browser, hitting Back, or jumping to a new URL)
Note that this "conversation" between Paypal and your server is independent of the user's session - it is a "private conversation" between you and PayPal about that user's transaction.
Obviously there can be communications outages and server failures, so if Paypal does not get the validation request from your server immediately it will periodically send retries to your server to ensure that the transaction is eventually completed.
If your payment system doesn't have at least some basic mechanism for ensuring transaction reliability, then choose a different provider. Chances are that they do, but you will have to implement things correctly on your server to be sure that the system works properly.
P.S. It is quite normal to require a user to log in (and thus be registered in the database) before they initiate any financial transaction. You need to gather all the relevant information before they go to purchase, as after the purchase you have no way of guaranteeing that they will return to you to provide any further information.
I am attempting to integrate Authorize.net into my site. I have set up and activated a test account in their test.authorize.net domain and have obtained and inserted their API key/login for my account into my configurations. I run my script through their API and I get the proper success message that they've received the information. However, every time I log into the test.authorize.net domain and search for the transactions via their Search tab, it always returns with nothing regardless of what parameters I search with. What can cause this?
Look in the unsettled transactions. That's where they'll be.
FYI, Authorize.Net developer accounts do not actually process transactions. They only validate that the data you sent over via their API was valid and complete. If it is you will receive an approved response with a fake transaction number, approval, and AVS response code (which is always a match). If your made an invalid API call an error message will be returned alerting you to your error so you can correct it.
If you don't want o call Authorize.Net for support or they give you the run around, you can also get help in their developer forums.
Authorize.net does not actually log transactions in test mode.
You should call their support; they are fantastic. However, from my experience you typically get a shared account where lots of tests are running and it can be hard to search for your transaction.