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).
Related
I am implementing subscriptions to a premium service on a website using Paypal as the payment service. I have successfully created a Catalog Product and Billing Plan through the API, and I am able to get to the payment page on Paypal, but it's not clear how I'm supposed to persist a user identifier through the purchase process.
I assumed it would be something along the lines of passing a user id somewhere, but there's nothing in the Paypal documentation about this. I need to be able to let the user make a purchase and have the Paypal webhook send the confirmation to an endpoint on my site, and that's where I'd expect to get their user id to toggle the subscription on their account on my end.
Is there something I'm missing? There has to be a way to do this cause I'd imagine it's a pretty common use case. If anyone has information or has done this before, I'd love to hear. Thanks.
The only truly secure way I've found when using javascript SDK, is to securely generate a unique custom_id on your server side associated with the user.
Then when you create the buttons, the 'createSubscription' function takes custom_id as a parameter.
Then use a webhook to receive events from your subscription and the custom_id will be present in the body of all BILLING.SUBSCRIPTION events under resource.custom_id.
I am able to get to the payment page on PayPal,
You are vague about what you are doing here. There are multiple ways (and some ways have multiple versions) of accepting subscriptions via PayPal, so it is important that you provide full details about the method you are using.
The time to associate a created subscription ID with a user ID is when it is approved, in the onApprove function if you are using a Smart Payment Button: https://developer.paypal.com/docs/subscriptions/integrate/#4-create-a-subscription
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.
I'm using Paypal rest api to make payment
the workflow is:
Create payment
Redirect to approval Url
User approved (return back to my site)
Execute payment
But there's one thing that I don't want users re-filling shipping address again because it was filled in my website.
So I change the workflow to:
Create web profile (set no shipping field)
Get web profile ID
Create payment with experienceProfileId given
Redirect to approval Url
User approved (return back to my site)
Execute payment
But I found this will create a lots WebProfile every time user request payment.
I think it is crazy to do:
create and delete it later again and again
attempt listing WebProfiles and check which is the one I want to use every time while creating payment
store experienceProfileId as a constant
What is the best practice for handling WebProfile or does there any solution just hiding shipping address while user approving payments?
Maybe this is not the answer regarding this "WebProfile". As a fact, I dont know what exactly "WebProfile" does or is.
I worked on the same Workflow these days. As you wrote I needed to predefine some address. For me it was obvious, that I have to do the database-stuff on my Website. Then I exactly define the order, shipping_address, etc. and send the users to Paypal.
If you predefine the new ShippingAddress() to your ´new ItemList()´ by
$itemlist->setShippingAddress($shippingaddress) the user cannot change it within the Process.
http://i.imgur.com/nAg8jxU.png
Maybe this helps you a little.
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 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