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.
Related
I have a requirement to do 3rd party age verification before I ship an order. I'm using a company called EVS for this. They released a shopify app recently, but seems partly baked. It requires a user to enter date of birth when registering for an account and then triggers the verification when the user places an order. The main problem with that is that it's rare for a customer to actually create an account before ordering for the first time -- instead they order first, then shopify emails them to create an account after the fact. Creating the account afterward does not allow the customer to enter DOB.
So I'm planning to implement my own solution. I can use EVS's API to run the verification by sending a combination of Name, Address, DOB, DL# and State, and last 4 of SSN. I have already built a proprietary order management system that pulls in customer and order data, and I can write a client to perform the verification.
I'm less savvy on the shopify side. I need to balance customer friction when placing an order for the first time, against having to do a lot of manual work for verification.
Below are the options I have conceived. Are there any other options? Any ideas for a better solution? Keep in mind I need to verify a customer once. I can tag the customer account as verified, and once verified it's business as usual.
Alter shopify templates to only show the checkout button when a user is logged in. If not logged in, show a "Create an account" button instead. That way the user provides DOB during account creation and the EVS app works as designed.
Set up a separate verification site like verify.my-domain.com. I can trigger an email to the customer upon order creation and ask them to verify. (May have issues with incorrect email addresses or spam filtering.)
If customer is not logged in, or account is not age verified, and they click Checkout, I can redirect them to a page. I can use a form on the page to do the verification. If verification passes, send them on to checkout.
For option 3, I don't know what shopify allows or what best practices allow. Can I use js to pass data to my own server on a different subdomain? Or post the form to another subdomain and then redirect back to shopify?
I'd appreciate any thoughts or suggestions.
You have pretty much summed up all your options, to clarify on them a little:
You can require that customers create an account in the store checkout settings. /admin/settings/checkout
This would work, you could iframe it in too on a custom Page. Or, better, use cross-domain calls or jsonp.
This is a little convoluted and you would have to persist and maintain lot of external state. I'd avoid this
I think a combination of 1 and 2. Turn on "require customer account". Modify the customer account creation page. Implement a cross domain policy with your server which will host custom code leveraging the EVS API.
I'm not sure if you are selling tangible goods or not but with stringent policies on users' age you have to bear in mind that shipping addresses could change. For a tight integration you should look at having webhooks whenever a customer is changed and make sure all their data is still valid since their last EVS approval.
I've been looking into this quite extensively and we've spent a number of hours experimenting with options. Our client in this case is on Shopify Plus so we do have the benefit of access to checkout.liquid.
Our research has led us to believe that one cannot pass the required 'customer note' of the date of birth to the checkout should they be attempting to checkout as a 'guest'. Perhaps because the 'customer' does not yet exist.
Our options have been narrowed down to:
Write a custom backend app that allows Shopify and EVS to communicate directly (XML API on the EVS side) in the checkout process or just prior and then pass the verification status back to Shopify to allow the order to proceed, or append some relevant status marker for the fulfillment department to act accordingly. The EVS app doesn't prevent the order from proceeding, but does flag the customer's age as unverified in the Risk Level panel in the admin. This would be quite a substantial project and by no means low hanging fruit. There is also risk of re-doing a lot of what the EVS app does already and running into they same obstacles they did.
Force customers to register prior to checkout (if not signed in). This seems the most viable approach. The only caveat being that existing customers will not have the customer note (birth date) and we'd need to build a smaller backend app to allow them to append this to their customer account via the Shopify API (this cannot be done via liquid).
These are our findings and I'd love to know more about how you ended up approaching this.
My Passbook-related app was recently rejected based on guideline 23.3:
23.3: Passes must be signed by the entity that will be distributing the pass under its own name, trademark, or brand or the app will be rejected and Passbook credentials may be revoked
I had a few questions and got on the phone with someone at Apple. They told me that to remedy my problem I could create a sign-up form in my application. This sign-up form could then be used to create a certificate and pass type ID for the user based on their credentials. However, I've been combing through the documentation and I've not found anything that allows people to create Pass Type IDs or Certificates without at paid developer membership. Is this correct, would my users need a paid developer membership to create their own Pass Type IDs?
If they don't, is it even possible to create a PassType ID at runtime? For example, using the information in the sign-up form I might make an API request with PassKit / some kind of Passbook server to create a Pass Type ID:
PassID *ID = [PassKit createIDWithName:#"USER_INFO"];
Is there anything like that or was the Apple technician talking about something else?
would my users need a paid developer membership to create their own
Pass Type IDs
As crazy as this sounds - yes! The only way of fully satisfying this guideline is to pay the Apple Tax and sign up as a Developer. There are several long threads in the Apple Developer Forums talking about the reasoning and implications of this. While it is not popular, the majority of us concede there are very good reasons for this, that in the long term, will protect the integrity of the platform (as well as keep the Apple lawyers happy in the short term).
The main reasoning is because in most jurisdictions; coupons, tickets, travel documents and other typical Passbook content create a binding obligation upon the issuer. Legally, in the event of non-fulfilment, the pass issuer is liable to the consumer. In order to protect themselves, Apple needs to ensure that under no circumstances, could they be deemed as the issuer of any Passbook pass.
The Apple Developer programme registration validates the identity of any individual or corporation who is accepted. It also forces Developers to sign the terms of the Developer Agreement which has an entire attachment dedicated to what you can and cannot do with Passbook and with your PassID certificate. This provides Apple with enough legal protection against any claims for unfulfilled goods or services relating to any Passbook pass.
While there has been a lot of pushback and calls for a faster, less US centric process (you would not believe how difficult it is to get a DUNS number for an small entity outside of the US), I don't expect this to change any time soon.
As for auto provisioning. Myself and the creators of the other major Passbook platforms have been calling for this since before iOS6 was launched. I have an open radar dated 7th August requesting a simple API to issue and revoke Pass Type ID certificates. I'm intrigued as to what your Apple Technician was referring to since as far as I am aware, there is no such service.
// rant
What is frustrating about this is that there are a number of approved Apps that allow full pass customisation but issue the passes under the App developer's certificate.
Apple also seem to turning a blind eye to certain services that issue passes under their own certificate that bear the logo and trademark of major brands (and then have the audacity to call on these brands to 'claim their passes').
Even Passtools (now Urban Airship) claim to offer a 'Unique Apple Developer Certificate from PassTools', which technically would be in violation of the Apple Developer Agreement.
So the bottom line is that on this occasion, you may have just been unlucky.
// end rant
I'm not sure what the technician was talking about, but 23.3 refers to a server (likely yours) going through a signing process with the pass before sending the pkpass file to a device.
For high level information, review the "signing and compressing the pass" section of the passbook programming guide.
I have a single authorize.net account, and I have 5 different e-commerce applications tied to that account. Some are posting from a public site and some are posting from managed access sites. I am using SIM and I have read about the Relay Response, but as far as I can tell I can only have one URL listed. That will not work for me as I need a different URL for each different point of entry into the e-commerce system.
My problem at the moment is that I need to update a datafield via a guid upon successful payment completion to confirm purchase of a digital item, but if I put in a relay response page it is getting sent to all my access points and throwing errors. Other parts of the e-commerce system need to send different emails upon completion etc, plus all the urls are different at the top level.
Is there some other way of accomplishing this task that I am overlooking?
Use Silent Post*. It's Authorize.Net's equivalent of Paypal's IPN. It will only post to one URL per account but it happens behind the scenes. This means you can send a custom flag along with each transaction identifying which site the purchase is for and then have it respond accordingly (e.g. send emails, update database, etc).
*I am the author of this content
I am developing an application where I have a section only for paid users where they purchase for the section using the in-app purhcase system in iOS. I know that I need to keep track of the purchase history myself, and this is where the problem begins. I have a database and I am capable of storing users in my database, with a web service interface. How can I create a system where a URL is pinged only when a user has made the purchase.
As an example, I have the URL:
http://example.com/registerUserPremium/userid=123456
How can I get this to be called only when a purchase is made? The most elegant way seems like Apple pinging the URL with a special user ID upon purchase, but I can't find a way of doing it. It is obviously not a solution to make the user call that URL within the app, as it can be cracked/pirated. What is a good way of providing such a mechanism that is piracy-proof. My service is web-based, so if I can get this part done, the rest relies on my server-side mechanism (the user will just send a special key that is stored in its keychain, to the server) so I'll be able to finish the project. In short, I need a way to call a URL only when a purchase is made. What are some possible solutions?
Thanks,
Can.
I see two solutions:
"Server product model" (doc): the appstore contact your servers every time a user makes a purchase. In this case you have all of the information right away.
"Builtin product model" (same doc) in which the application gets the receipt from the appstore. In this latter case you can contact your server special URL, providing the receipt information, and the server can verify that the receipt has not been tampered with asking the app store to verify (it's a simple post, see here).
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).