In my application I am listing some songs and users can tap on download and Itunes open and user can download the music. This far its working perfect.
Now I need to know if user have successfully purchased the music. I have some logic to be implemented based on whether the purchase is successful or not.
Is there anyway we can find a successful iTunes purchase? At-least when we use our affiliate ID?
Take a look at how Ebates does this. They link to the iTunes store through Apple's program in the LinkShare network (so you'll need to find analogous instructions for whichever network you use with iTunes: PHG, TradeDoubler, LinkShare, etc).
Notice that your outbound click to the iTunes store from Ebates contains a URL parameter u1 with a unique ID that looks like ebs1234567890sbe. That's what's called a "Signature" or "ShopperID" or "SID value". That ID gets attached to the user so that when they complete a purchase and you get your commission, your reporting will have this ID attached to the transaction. That's how cashback affiliates know to give the right cashback to the right user and you can use that same feature for your needs.
So, some steps for you:
Find the documentation for sending SID values for the affiiliate network you're using to send traffic to iTunes. Here's the documentation for LinkShare (pdf).
Pass a user id with clicks to iTunes
Integrate with your affiliate network's commissions API so that your servers know when a sale has been completed and which user id completed the sale
EDIT: iTunes affiliates working through the PHG network will find these resources useful:
This PDF is PHG's quick start guide. Follow the instructions for "Sub-ID tracking parameters."
PHG's API Docs discuss reporting methods.
Thanks to #Deepukjayan, here is the precise API query syntax for getting your pubref value back from PHG's iTunes API: https://login:pass#itunes-api.performancehorizon.com/reporting/report_publisher/publisher/YOUR_ID/conversion.json?publisher_reference=YOUR_PUBREF_STRING
Related
My problem:
I am having a hard time figuring out a way to safely manage auto-renewable subscriptions in iOS with Firebase.
Purchase process:
User1 purchases a subscription
Update User1's account on Firebase w/ the subscription identifier
(used to unlock content)
Store original_transaciton_identifier(OTI) w/ uid of User1 to match w/ receipt verification from Apple.
Grant user access
Edge cases causing my brain to implode:
User1 logs out of AppleId used to purchase subscription, but remains logged in to app w/ Firestore credentials.
Therefore, when I go to verify if the subscription has expired it does not return a valid subscription. I want the user to be able to keep their access until it is expired or canceled. Any tips on achieving this?
User2 logs into the same device User1 was previously using.
Therefore, the same AppleId is being used for both users. I can check if the current user has a subscription, and check the OTI to see if it corresponds to User2...which it won't.
We will show the 'purchase iAPs' screen, but what if this user wants to buy a subscription as well under the same AppleId? Is it normal for me to handle this saying, "Apple Id already connected with another account or something"?
Relevant articles I've been able to find:
How to tie auto-renewable subscriptions to in house user, not appled id
I've been struggling with this for sometime and haven't been able to find many resources. All help is appreciated.
For case #1:
When you attempt to access the receipt Apple will trigger a login prompt for the user to enter their iTunes credentials. If a receipt is still unavailable, you won't be able to verify the subscription status. The "right" way to do this is to store the entire receipt on your server, and periodically refresh it with /verifyReceipt. You'll check if the subscription was cancelled, and update the expiration_date so you know when to cut off access for the user.
For case #2:
Is it normal for me to handle this saying, "Apple Id already connected
with another account or something"?
Yes! If you're able to look at how some other large subscription apps handle this (Netflix, Spotify, HBO, etc.) - it's similar to what you describe. Instead of checking the receipt locally every time, if you maintain the subscription status on your server (as mentioned in #1) this would only happen if the user tries to "Restore Purchases".
This is a pretty extreme edge case, since not many people try to make a purchase on their friends phone and would require TouchID/FaceID in most cases - so it's more of a fraud prevention feature. Once you get millions of users you can get fancy and send them an automated email link to signup with Stripe if you detect this.
Alternative:
RevenueCat can handle all the subscription tracking and these edge cases out-of-the-box, and it plays nice with an official Firebase integration. Disclaimer: I work there.
I have iOS app and several ad campaigns for it. I build URLs for each campaign in iTunes connect (according to that guide) and it looks like that:
https://itunes.apple.com/app/apple-store/id0000000000?pt=0000&ct=&mt=8
Everything is OK and I can see statistics in App Analytics in iTunes Connect.
But is there any way to get campaign ID inside my app? I want to track that particular user install my app by clicking at some banner or link in newsletter and so on.
Thanks in advance.
Unfortunately, this is impossible. Apple prevents it.
There is a company that has patented one way to do it for advertising campaigns. It's expensive www.appsflyer.com
The "new" iTunes only gives you some information: https://www.nerdery.com/blog/itunes-connect-analytics-revolutionize-ios-app-marketing/
I have a client that needs to have its volunteers purchase an IAP (A data package that is downloaded), then somehow reimburse them. The problem is that there is no easy way to do this that I think Apple will approve of. Especially for over 1500 people. I've come up with several ways of doing this with their pros and cons, which one would be best to implement and does anyone have any other suggestions on how to do this?
1) Have the client send out iTunes gift cards via email. The IAP is $7, and you can't send a gift card less than $10. Also, they would have to send them one at a time, there is no way to send bulk. Not going to work
2) Create gift codes like iTunes gift cards. My client can purchase codes in bulk via IAP (so Apple still gets their money), and store them on my web server securely. I can then implement a system to send all the codes to a single email, or individually to multiple emails. Then the volunteers can use the codes to unlock that single IAP. This would be more work on my part, but easier for my client. Something tells me Apple probably would not approve of this method.
3) Create "Credits" that the client can purchase in bulk via IAP (so Apple still gets their money), then gift either the credits or send the IAP info itself to the volunteers via a p2p bluetooth connection created with game kit. This would be harder for the client, as they would have to send each "Credit" individually. But I think Apple would be more likely to approve this.
4) Have the client send me a list of UUIDs for each of the volunteers devices. I add the UUIDs to a secure list on my server. During the purchase the a check is preformed to see if the devices UUID matches one on my server. If it is, they are marked as "all ready paid" and given the IAP data. I don't know about this one, as the only way I can see the money transfer happening is myself getting paid directly, and Apple being left out (So they probably wouldn't approve of this. I have no problem giving Apple their 30% if I could find a way to get that to work with this.
I'd go with Option 5, and create my own IAP system. Much like Option 3, but bypassing Apple all together. Add a Custom URL Scheme to you application, give it to your client to distribute. When your app is launched by its Custom URL Scheme have it open to a promo code entry page.
Your client would be able to purchase/create codes as necessary via a website that you set up for them. You would then store the codes (or create an algorithm to check generated codes against), and validate the codes as the users enter them.
Then your clients users would enter their unique code and have everything unlocked/downloaded as needed.
I have done a similar set up with promo codes to unlock the full version of my applications so I could create my own promotions, without making the upgrades free for everyone by removing/altering the IAP.
My team and I are going to write an app for an organisation where the user can donate to this organisation. The app itself is not the problem, but we don't really know how we can handle this.
Our first thought was that we could make the donations like if you purchase an item in a game for real money. But there are 2 problems:
There are only fixed amounts like 99c and so on
Apple gets 30%, and we want the user to know who gets how much. The developers: 10%, The Organisation 90%. But if Apple gets 30% of ALL the money, and people see that, they may not donate for that reason. I wouldn't either.
Our second thought was that we implement a webthingy (don't know how the element is called atm) in our app, which simply works like Safari and we direct them to the donation page or something, but how does the organisation know that the donations are from our app then?
Is there any other way we can handle this? I think people will be able to donate via credit cards and PayPal.
Edit, I found this:
21.1 Apps that include the ability to make donations to recognized charitable organizations must be free
21.2 The collection of donations must be done via a web site in Safari or an SMS
The app will be free, and it is fine if it has to be via SMS or Safari, but HOW does the organisation know the donations coming in, are from the app?
Update:
US non-profits can accept donations via Apple Pay:
Starting November 14, 2016, nonprofits based in the United States can use Apple Pay to provide a simple and secure way to accept donations from within their app and website. Similar to using Apple Pay to buy goods and services, users can donate without entering their billing, shipping, or contact details.
The App Store guidelines go on to say:
Acceptable
...
Approved nonprofits may fundraise directly within their own apps or third-party apps, provided those fundraising campaigns adhere to all App Review Guidelines and offer Apple Pay support. These apps must disclose how the funds will be used, abide by all required local and federal laws, and ensure appropriate tax receipts are available to donors. Additional information shall be provided to App Review upon request. Nonprofit platforms that connect donors to other nonprofits must ensure that every nonprofit listed in the app has also gone through the nonprofit approval process. Learn more about becoming an approved nonprofit.
Unacceptable
...
Unless you are an approved nonprofit or otherwise permitted under Section 3.2.1 (vi) above, collecting funds within the app for charities and fundraisers. Apps that seek to raise money for such causes must be free on the App Store and may only collect funds outside of the app, such as via Safari or SMS.
My old answer, below, predated this revision in the charitable giving policy.
As you note, section 21 of the App Store Review Guidelines says:
21.Charities and contributions
21.1 Apps that include the ability to make donations to recognized charitable organizations must be free
21.2 The collection of donations must be done via a web site in Safari or an SMS
You ask how you know if they're from your app: For Safari use a unique URL or include a HTTP parameter that you append to the URL when you invoke Safari, which their web server code will capture. As other have suggested, you might want to log the initiation of the transaction for your own reconciliation purposes, too. For SMS, I assume you'd have a dedicated SMS number for app donations.
But HOW does the organisation know the donations coming in, are from the app?
Make a new page on the organization's site that has a URL that isn't linked to anywhere and non-indexable by search engines (robots.txt).
In your app, make a UIWebView set to a URL on your own servers that redirects to the page you make in step 1. You should also make this URL non-indexable.
In that page
Check that the referrer is your page
Check that the user agent is whatever UIWebView sends
Have the page log whatever happens somewhere (date/time, donation amount, etc) -- to reconcile with their data
When a successful donation is made, it should record that it came from this page (and therefore, your app)
Someone could fake that they used your app by making the appropriate request, but why would they. Even if they did, you should probably get credit for that donation anyway.
You can't use IAP for any virtual good that are not consumed in the app as far as I know, apple will reject your app if you try it. (However i've seem some exceptions to that)
try www.stripe.com, they have the best payment interface i've seem so far.
someone even made an iOS SDK to help you with the implementation https://github.com/briancollins/stripe-ios
I don't believe Apple will allow you to use in-app purchases to accept donations. Marco looked into this with his Instapaper app and couldn't do it (now he charges for server searches). You actually have to provide something for the money. Your best bet is to develop a web app that uses a private api to process the donation. That way you can know for certain where the donations are coming from.
Ah, nevermind, you can accept donation on a free app. Missed that. Still, using a private api in a web app is probably your best bet.
From April 2020 you cannot donate inside the app. Apple teams say you can't donate inside the IOS app if you are a nonprofit organization. you must redirect the user to Safari or on your website for donation or using SMS for donation.
Otherwise, You can use Apple Pay for donation like in App Purchase if you are profit Organization
soo if you are a nonprofit organization and you want to donate, please follow these steps.
I am using Flutterwave SKD for donation. You can use as you want like Stripe and PayPal etc.
1: I am using the Flutterwave Php SDK for donation. just download the PHP SDK of your payment gateway from your Payment gateway DOC.
2: create a webpage for payment on your web end and from your app open this webpage into Safari, And pass user ID with URL parameter so you can keep the record of which user donate us and how much.
like (PageWebUrl/userID) (https://www.mywebPageLink.com/donation/userId=20)
3: When a user successfully donates save the data into that user-id and redirect the user to your app.
4: call an API to retrieve the donation data for your app.
Coooool Done...
I'm not looking to harvest information, I'm just trying to create a way to offer my users custom promo codes for In App Purchases since Apple doesn't offer promo codes for IAP. I'm looking for a way to identify a user when they move from device to device so I can unlock their In App Purchases they've gotten access to by using one of my custom promo codes.
Is there anyway to programmatically get the current user's iTunes Connect username?
No, and that is the way it should be. I, as a user, don't want that a developer can get my Apple Id which is also my email address.
The only way I think this works is to let the user create an account on a server which is managed by you.