Background
My iOS app supports multiple user accounts, but the user can only be logged into one account at a time. The app also offers a subscription service ("credits" in the form of a renewable In-App Purchase).
I'm having trouble keeping the in-app subscriptions separated to the specific user account that bought them. If a user buys credits on Account One and then signs out, and another user signs into Account Two (on the same device), the SKPaymentQueue still proceeds with the renewal process for the purchases from Account One (and, consequently, triggers the logic that unlocks those credits).
Question
What is the correct method of handling renewable in-app purchases for an app that supports multiple accounts? Is there any way to keep purchases from "overflowing" into other accounts on the same device? What else should be kept in mind?
I'm pretty sure what you're trying to do isn't possible. In-app purchases are tied to the Apple ID that purchased them. That means that if the user is logged into an Apple ID that has purchased the subscription, you are always going to be told it is available. A single user can't purchase the same subscription multiple times. The only way would be to force an Apple ID change when they change users in your app, which I'm almost certain you can't do.
Related
So I am building an app with react-native (expo) where a user fixes appointment with some other person and to do so, he has pay the other person.
Now how can I handle payments here. What i want is the user makes the payment and the receiver should be the other person but how much i understood the payment gateways, the payment is received by the app owner or in simple words, receiver is a single person.
I also tried deep linking to directly take the user to some UPI app like google pay or paytm but it seems that those apps require some special type of account (merchant account) to make the transaction if we access them using deep links (which is a problem as it is not necessary that every user will have a merchant account).
As I said, it is always better that you have your own payment gateway account, and all the transaction goes through your gateway, meaning you get the money and you build a system which will forward the payment to the receiver. I have worked on 2 such apps:
1: Where we have our own razorpay account, and we get the payment first, and then we forward it.
2: Where in we were directly having transaction between 2 users, but not through app, instead we display them the account details of the receiver and give them 48hrs time to pay that account. But we had to manually handle this scenario since one cannot know if the user has paid to the said account, since it's not your account.
3: There is one more method where in payment gateway has a webhook which consists of a virtual account number, and every user that lands on your app, you can create a virtual account number for him/her and store the user-virtual account number relationship in your db, whenever there is a payment, you can find out about the user through this virtual account number. Read about this.
The deep link is a good idea, but again, as you mentioned, it will require the end user to be a merchant user(have a merchant account), you can find more details here
Maybe you can ask your users to create a merchant account, which again I am not sure if it's possible, and if it's possible, if it's feasible?
The best way according to me is, you handle this through your payment gateway, and instantly forward it to the user who should have received it. Again there are some rules and clause to it(some commission is taken by those payment gateway,etc), check those things out.
I think the most close answer to my question is to use razorpay routes where we can link multiple accounts with our account and transfer money accordingly.
More details here
There is an app that allows users to pay their bills in one place they are asked to log in to their accounts with various billers. Then it retrieves their bill amount and due date and makes it available in the app. My question is what is the feature of allowing users to login to other platforms through your app called? An API or something else?
In my app I have users subscribing to Auto-Renewable In-App Purchases. They can subscribe either 1 or 12 months.
my question is that if a user has purchased 12 months subscription from one device and suppose the device got stolen after the purchase
With new device the user login with same credentials in the application
(as now it will contain new device id ) ???
Did the user will be able to continue with the subscription, what he purchased or the user need to pay again for auto renew subscription as he/she has new device id..
You will need to use a non-consumable in-app purchase.
Check out how to do that at How do you add an in-app purchase to an iOS application?
Once you read the accepted answer you will see that your app needs a restore button which means if the user uses the same apple id with any device, your in-app purchase can be restored. There is no need for device id.
And about keeping track of time before your subscription ends. For this you should ask your user to register with their username/password and store it in your database with the subscription end date. Therefore, every time you user tries to restore in-app purchase your app can check the end subscription date in your database.
The guide says that I need to declare the in app purchases (token, price, availability) in the submission process, but I can't for the life of me find it!
If it's a universal app, do I need to resubmit the Windows Store app (versus the Windows Phone app which is submitted separately) and put the In-App Purchases in there?
Does that mean that both Phone and Non-Phone apps have to have the same list of in-app purchases?
In the Windows Store dashboard, populating your list of in-app purchases is done from the Selling Details section early in the submission process. There's a link there near the top of the page, under "In-app Purchases" that says "Use the Windows Store in-app purchase system." This takes you to the page where you enter the purchase details.
In the Windows Phone Store dashboard, once you've created an app, go back to the dashboard home, click on the app under In-progress Submissions, and you'll see a page with a number of links/tabs: Lifecycle | Quick stats | Reviews | Pricing | Details | Products. Click on "Products" and you'll go to the place where you define in-app purchases.
You do need to create the in-app purchases separately on both dashboards, because you are submitting separate apps in the end. Each submission can therefore have its own list of in-app purchases, because clearly there are scenarios where you might have a purchase available on one platform but not the other.
Now if you have the apps in both stores associated with one another, i.e. you use the same app name and then associate them so they have the same package family name/ID, then you allow your customers to share in-app purchases between the two apps, provided that you use the same product ID for each. This way, the app ID + product ID uniquely identifies the in-app purchase for the user, so if the user has purchased it on one platform it's available on the other. If you use different product IDs, however, then you won't have that shared entitlement.
Note that it's the app ID + product ID that makes these shared entitlements: you can implement each app however you want, meaning that you don't have to use an universal app project. They must both be targeting the 8.1 platforms, however, because that's where this capability is enabled.
I am working on one app. In this app to buy some non digital items i have to give access to users to do transactions using credit card / debit card. I have seen some apps in app store which accepts credit card / debit card . Those apps are Pay Anywhere , Rev COIN.
1) Can we know which third party API's they are using. 2)While using these apps do we need any card reader(another device) to swipe the card.
As well how to get those API's. Can any one help me please. This plays majority role in my app. Any suggestions please.
Doing some transactions with ZOOZ are ok . But coming to my app i have one requirement. i.e user can send order for one item and user can say expiry time(i.e in how many days product has to be delivered) at the time of offering an item payment will be done. before delivering the product user can cancel the order. whenever the order is cancelled some amount has to be deducted and remaining has to be refunded.
For example user sending request for pepsi which is worth of 10$ and expiry time is 3days payment will be done immediately. Next day he may want to cancel the order in such a case user 2$ will be deducted and remaining 8$ has to be credited back to user account. Can we do any these type of transactions using some API's.
Zooz is one way that you can do in-app payments. It's supposed to be easy. That kind of model would be for you using an app as a kind of online "store" like amazon.
If you're talking about using an iOS device to record transactions (using a single unit as a cash-register system) then you would need a card swipe add-on unless you want the customer to input all of their credit information when they pay.
Or, as jgervin pointed out you could use card.io to let the users take a picture of their credit card. The company charges you per-scan however.
Important note: Apple will reject your app from the app-store. See the linked questions.
Pay for a physical product with in-app purchase
Has anyone implemented the PayPal API through a native iPhone app?
Which PayPal iPhone SDK should I use?
So hopefully you're planning to deploy with airwatch or something similar.