I am developing a payment application for apple users, where users will have an account and will be able to recharge using apple pay.
Its fine while my application is in production. Below Figure 8-1 Production.
But while my application is in testflight of apple. A listed users(allowed by me) can download/update his/her testflight application from store, Also can recharge his account balance using sandbox of apple pay.
According to guideline of Apple store.
https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Chapters/AppReview.html#//apple_ref/doc/uid/TP40008267-CH10-SW1
As the Figure 8-1(App review) of the above link though the users pay from his/her sandbox apple pay account user will receive money in his production account!!!
My question is
What is the better way to handle those transactions of apple sandbox transactions?
and
How typical payment applications handle those types of situations?
You have to understand the difference between Testflight users and sandbox users for testing in-app purchases.
You are sending your test users to test the app via Testflight and you invite them with their real email address.
They can never do a sandbox purchase with their real (production) account that they currently use in the App Store for example.
Here is what you have to do:
Go to iTunes Connect - https://itunesconnect.apple.com
Go to Users and Roles
In the top right select Sandbox Testers
Add a test user (first & last name, email address (not the email that someone uses for the App Store - I like to use a fake email like test#testApp.com or whatever)
Now you can share this email address with your tester(s), then they have to go to App Store or Settings - iTunes & App Store and log out of their account and log in with your sandbox account (they will be switched to the App Store that you specified for the sand box user so you can see how it would work for someone in USA vs. someone in Italy or China).
As you can see in the image below all Sandbox payments will have [Environment: Sandbox] written on them. And no money will be exchanged since you are only testing to see if your in-app purchases or subscriptions work...hope it helps
I think Apple has given recommended approach in your mentioned article.
When validating receipts on your server, your server needs to be able to handle a production-signed app getting its receipts from Apple’s test environment. The recommended approach is for your production server to always validate receipts against the production App Store first. If validation fails with the error code “Sandbox receipt used in production”, validate against the test environment instead.
Related
Ok, I suspect the answer to this is simple. But here goes...
I am in the process of submitting my app. I am submitting for review even though my In-App purchase integration has not been tested. This is essentially because I am unable to retrieve my list of IAP items if the IAP items have not been submitted/verified. So it seems to me this is like a "chicken or the egg" kind of situation.
My plan is to submit the App and the 1st IAP item. Then I am assuming this will allow me to magically retrieve the IAP item when I run the App.
Am I approaching this correctly, or is there a more intuitive/simpler way to test the IAP retrieval process (and the many other things to test once it is retrieved)?
Per Apple's Documentation:
To perform testing for in-app purchase products Set up test user
accounts within Users and Roles in iTunes Connect, as detailed in
Creating Sandbox Tester Accounts in iTunes Connect Developer Guide.
You’ll need a test user for each territory you want to test the app
in.
Clear any account information stored on your test device.
In Settings, go to the Store settings. Click the Sign Out button. This
prevents an actual user account from automatically being used when
testing.
Important: Don’t enter your test account information in the Store
settings panel. Doing so may invalidate your test account. Connect
your test device to your Mac.
In Xcode, set your test device as your scheme’s destination.
Open your app, and perform your in-app purchase product testing.
Use your test account credentials to test the purchase.
When your app uses the Store Kit API to request a payment, you’re
asked to sign in. Select Use Existing Account and enter your test
account user name and password. You are then asked to confirm the
purchase. The transaction completes.
No financial transaction takes place, but a receipt is generated for a
successful transaction.
It's pretty straightforward, just takes a bit of set up. Good luck!
I have developed an app like money wallet (e.g. paytm), where user can request money to each other and transfer money to each others account. with every transaction of user, Admin will get some fixed percent commission.
As app is for one small town only,right now user will have to manually contact admin to load money in his wallet or to withdraw it.
I want to submit my app on iTunes store. I know to use any digital content, services, unlock features we need to use In App Purchase. And for any physical good we need to go with any other third party payment gateway.
So I am confused that will apple approve my app or not. Please help.
Thanks,
First, you never know if Apple will approve or not. The only way to know for sure is to submit and see what happens.
Your description of features sounds like you are probably taking the correct approach.
Its important to use In app purchase for unlocking content/features:
Apps that unlock or enable additional features or functionality
with mechanisms other than the App Store will be rejected
And equally for real world purchases to use something else:
Apps using IAP to purchase physical goods or goods and services used
outside of the App will be rejected
The complete guidelines can be found here https://developer.apple.com/app-store/review/guidelines/#purchasing-currencies
And again, its Apples own words:
This is a living document, and new Apps presenting new questions may
result in new rules at any time. Perhaps your App will trigger this.
I tried to submit using paytm integration sdk, and after that my app got rejected
following is reply from App Store
Guideline 3.1.1 - Business - Payments - In-App Purchase
We noticed that your app or its metadata enables the purchase of content, services, or functionality in the app by means other than the in-app purchase API, which is not appropriate for the App Store.
Next Steps
While the payment system that you have included may conduct the transaction outside of the app, if the purchasable content, functionality, or services are intended to be used in the app, they must be purchased using in-app purchase, within the app - unless it is of the type referenced in guideline 3.1.3 of the App Store Review Guidelines.
Please see attached screenshots for details.
Since your App Store Connect status is Rejected, a new binary will be required.
Having an app with login to our server. We want to introduce nonconsumable in-apps, but I don't know how to make an in-app available to one server account and unavailable to another server account on a single device. What product id's should I use? Are there any dynamics available in itunes connect? Maybe I should use a consumable in-app to "buy" virtual goods? If so, how can i validate this on my server (I know i can do it for non consumables, but it looks like it won't work for consumables)
Also, if I implement the subject above, how can I correctly restore my purchases on another itunes account but the same server login?
What are the best practicies for this?
I am looking to start selling an app on the Apple app store however currently the app uses our own servers to generate a license to the customer once they have purchased it. How can our existing licensing system which uses our own servers be implemented if a customer purchases the app from the App Store instead?
The application license will be a yearly renewable one. Therefore, so far, from what I have read, the app on the App Store could just come with an auto-renewal option (opt-out of course) so that would take care of the subscription cycle but how can our own server issue the customer the one year license which they could then renew from iTunes using the auto-renew function of the App Store?
I am sorry if this is not clear but it would go like this:
Customer downloads application from app store with a one year auto
renewal subscription.
Customer pays.
The app store verifies the
payment.
Once payment is verified it contacts our server to create a
license for that purchase and for one year.
That license is sent back
from our server to the purchased app to unlock the subscription.
Please correct me if my understanding on how this works is wrong but if anyone can point me in the right direction or give examples of how an application on the app store can successfully issue licenses from their own server then I would be very grateful.
As an example, look at "Aviation Exam". They let you buy subscriptions on-device as in-app purchases, or on their own website. In each case the details are synced to a user's account on their own server, so the same exam can be used from any device.
Look at the Apple documentation for how in-app purchase subscriptions work on iOS. Then your app can send details of a purchase to your servers, and download further information.
Edit; after discussion in comments:
If you want payment to go via Apple then it has to be via App Purchase or In-App Purchase. In-App Purchase specifically supports the idea of buying a subscription for a limited time. This is explained at the second link above.
If you want the user to create an account on your server you can either have a page in the app for them to input their details, or you can bring up a web page served from your website. Either way, the info can go to your server and it can create an account.
The key thing is, if payment went via Apple then inside the app is the only place you know this. The app can send this info to your server. You need some common identifier (i.e. a user-name) that is known to your server and to your user, then the user keys it in to your app and it can all be matched up.
There is nothing complicated here, to a decent software developer. All they need is an existence proof such as I gave at the top, and they can figure out how to link the info together.
Edit 2
Some tutorials for in-app purchase listed at: In-App purchase server model
Lots of low-level detail at: Verify receipt for in App purchase
If you prefer to handle payment yourself, not via Apple, then the situation is very different. Now, your own systems have to keep track of what has been bought, when subscriptions run out, etc. To begin with, the app won't know this at all. However, once you identify the user by having them enter credentials (username/password), you can fetch all the details from your back-end system to the app and proceed as above. Again, this is all visible in the example I gave at the beginning, which supports both Apple and non-Apple payments.
One thing to note: if you handle payment yourself then Apple isn't getting its 30% cut, which is the usual App Store commission, so they may not like this. The guidelines say:
11.1 Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected
11.13 Apps that link to external mechanisms for purchases or subscriptions to be used in the App, such as a "buy" button that goes to a web site to purchase a digital book, will be rejected
That's pretty clear-cut, but since there are apps that rely on subscriptions or content purchased elsewhere, they don't seem to follow these rules in every case. Even the Amazon Kindle app was allowed back, once they took the 'buy' button off.
I want to create an app that will be displayed as FREE on the App Store, but upon opening it, users are required to do and in-app purchase to be able to access any of the content. I am reading the App Store Review Guidelines, but I am not sure if Apple allows this since the users will not be able to see anything on the app unless they subscribe to it.
The reason I need this is because my client wants the app to be sold at $0.99/year and I don't think this can be done by setting only via Price Tier.
Create a membership only app.
You must sign in to use the app (you can give apple a test account)
then you can manage the membership on your own servers. Or allow them to sign up with the in app purchase.
(enable both the user login and the in app purchase to get a user login, then you can give apple a "test" account that requires no purchase)
They will test your in app purchases anyhow so make sure you follow all the rules on Re-Activating in app purchases, this way if the user comes back and reloads their purchase and they have 2 months left you are sure the app will still allow them.
As long as you dont try to accept credit cards from the app, and use their in app purchase system you should be fine.
If you want to enable users to purchase their account from your server, you cannot allow the purchase from the app. The login however can enable the app without the purchase (and the test account should) but in app purchase should allow them to attach their purchase to the account they use.
I think im rambling now so I hope thats enough clarification.
What you can do is present a demo of the app as a feature before the user buying in-app purchase.just a screen extra. So that Apple does not reject it.
The other option is:
If you have a login/password app, you can tell apple that your app requires login before any feature can be given, only if your in-app thing is login related.