I am trying to build an app where people can buy NFTs. However I have been rejected due to missing In-App-Purchase function and I was about to add the function.
But now that I think it has a point to consider, because NFT MUST be non-refundable but Apple sometimes can be on the customer's side which means the customer can success to get a refund.
NFT is a blockchain thing, and once the ownership of an NFT is transferred to someone it's not possible to take it back unlike those items in mobile games.
So I am curious if putting In-App-Purchase function is a good idea, and if there is a 100% guarantee that I can make an item non-refundable. In other words, I need any purchasable item to be 100% non-refundable NO MATTER WHAT.
Does anyone have a solution?
Related
Is there any way to implement conditional logic for payments in Swift? For example:
Say the user has agreed to have 10$ withdrawn from his bank account he connected to his app account if, on a specific day, he has not fulfilled a condition that can be tracked with the app.
If he fulfills the condition until 23:59, no money will be withdrawn. If he doesn't, at 00:00 on the next day, the 10$ are automatically withdrawn from his bank account.
I don't know of any app that does this and I'm not even sure whether an app like this would be permitted on the app store. I'm not even sure whether that's technically possible.
Would be thankful for any helpful input!
Using the in-app payments system (a.k.a. iOS in-app purchases which utilise the StoreKit2 or StoreKit API) this not feasible.
Explaining how in-app purchases work would be a bit tedious.
However, to put it simply, you can basically initiate either a one-time payment request, or a recurring payment request.
In each of these scenarios, the user may obviously either make the payment or decline, about which you would get updated in code.
The closest the system comes to what you are asking for is recurring payments (technically called the auto-renewable subscriptions).
However there is no way to ask Apple to conditionally deduct money based on whether the user has performed some action or not.
I'm pretty sure you should not be looking at the iOS in-app purchase system as a way to do what your are looking for.
You could use 3rd-party payments.
However, whether Apple allows this, would depend on what kind of condition you expect the user to fulfil. If it relates to a real world service or material, then you may be able to justify it to Apple, however, if it is a digital service, lets say an app based activity, such as opening the app a given number or times, or viewing the app for a given amount of time, then I'm pretty sure this would be in violation of the Apple App Store Guidelines and they would reject your app when you submit it for review.
To be honest without understanding the use-case a little more clearly it is a bit difficult to advise you on the technical feasibility.
So I’m creating an app for a guy who runs a local auction (a mini ebay meets craigslist if you will, but for more in person transactions). I’m doing it as a favor, but to also build my portfolio, so hey we both get something out of it. Now I’m running into a bit of a thinker on the “payment system”. The idea we came up with is when a seller completes the transaction, and confirms the sale, the money is held “by a middle man” until the buyer confirms the item (kind of like how Pay pal can release funds early if the buyer of an ebay item says it’s a good sale).
The client wants it set up this way so that he doesn’t miss out on his cut (10% of the sale)– as in I buy an item, meet the seller in person, then we just do an exchange there having used the app as more of a means to meet. I know Uber charges your card automatically upon GPS once you reach your destination, but it would be better to pull up the “buyer” portion of the app to confirm the sale, thus moving it from the middle man to the seller.
Aside from ensuring the client gets his cut, this can also build confidence that the “sale is funded” when the buyer is on their way.
Anyway, are there API’s out there that can help be build something like this for speedy transactions?
Not sure if this helps, but we will be using Parse as the back end.
Thanks!
There are several payment APIs for the iOS, and I can recommend Stripe which has everything you need. They have an excellent support and documentation for integrating with iOS. You can check the documentation here. Also it works really well with Apple Pay and it's implementation is no brainer.
I'm working on an iOS app and am currently trying to come up with strategies of how to manage in-app purchases:
Android has the nice capability that it caches product ownership information locally on the device and can therefore check ownership without having to prompt the user for a password. iOS, on the other hand, cannot restore purchases at all without asking the user to log in and Apple therefore specifically discourages ownership-checks at app-launch in their Restoring Purchased Products documentation (last sentence of first paragraph).
Now, technically, you can get iOS to provide the same "ownership caching" for non-consumable items as Android does, by just never calling finishTransaction:, except in the case of failed transactions. That way, at every app launch, as soon as you call addTransactionObserver:, you get a list of owned products without a user login request.
Clearly, I can also provide this cache myself using something like NSUserDefaults, but that would be a bit more work and just adds more opportunities to make mistakes in implementing the ownership tracking. And since I need to handle randomly reported transactions from the transaction observer anyways for good measure, I would basically have to implement the above idea and then duplicate its functionality again using NSUserDefaults or such.
Thus my questions: Is it OK to (mis-)use unfinished transactions in this way? Will they ever expire automatically? Might Apple reject my app if they notice that this is what I'm doing? Are there any negative implications of this idea (reliability, performance, wasted memory/storage)?
I have a very strait forward question (and yes I've looked though apple documentation to see if this has an answer but no luck... I may have accidentally missed it though)
Here's my plan:
The problem I've been trying to find a workaround for is that if the admin would ever want to add a product, he would have to log into iTunes connect to add it and also add it in a custom control panel. We, obviously, don't want to make him suffer that so I've been looking for a solution but I need you guys to tell me if it's allowed by apple. Basically I will take over most of the product handling on our servers and will only go to apple with the transactions. This means that apple will not have an in-app purchase set up for ALL the products... only one for each length of subscription (1 month, 3 month... etc) and a few consumable in-app purchases for the various prices of the issues/singles
Side note: I will be selling monthly issues that contain multiple singles for each day of the month. The user will be able to download a full month or a single day at a time if they like.
DEFINITION OF CONSUMABLE PURCHASE - products must be purchased each time the user needs that item. For example, one-time services are commonly implemented as consumable products.
So I will store all the information in our server about the products and if someone chooses to buy a single month's issue that was set to 4.99 (on our server, not apples) then the app will run the in-app purchase with apple that is listed for the 4.99 tier. Whenever a person opens the app for the first time, their app will send some information to our server and they will have a row set aside for them where all the information about their purchases will be recorded so that they can restore them if they switch over to another device.
If you guys think i'm safe in doing this, please let me know so that I can proceed. Also, if this method helps anyone, feel free to use it!
Thanks,
Matt
I think your restore process might be flawed. You talk about the app sending some information up to your server, but what is that information? There is no reliable way to uniquely identify a user across different devices.
If you want to continue on this path you'll want to make sure that your recovery and failover process is very solid. Try out every imaginable scenario. From an app store submission point of view, you'll want to consider a token/coin-based approach. Of course, Apple's guidelines are fairly loose and subject to change so it's always possible you'll get rejected, but tokens are certainly more solid than simply using the same generic in-app purchase.
In a token system, you would set up in-app purchases for different numbers of tokens that the user can purchase as a sort-of virtual currency only valid within your application. Then users can spend these tokens on any items that you dynamically create.
Server-side this means you'll need some way to store how many tokens a user currently has and a way to uniquely identify a user across devices, which is a fairly uncertain proposition. Instead of storing the number of tokens each user has, you could implement some sort of hashing algorithm that generates a hash from an in-app purchase receipt and then sends it up to your server. If the app crashes or the network dies after purchase but before sending your hashes up, next time they open the app you can recalculate all of the hashes, send 'em up, and if the server doesn't recognize a hash it just adds it to the database. Then if a user wants to restore their purchases you simply recalculate the hashes on the device using the in-app purchase receipts you'll receive and then send them up to your server and ask the server to figure out for each of those hashes, how many tokens the user has left. You could think of it like a gift card system, where each hash is one gift card.
Again, app store rules change and if apple thinks you're trying to game the system and not provide a useful experience they have the right to reject you. It could be worthwhile to open a Developer Technical Support request and see if an apple engineer can provide you with a better solution or tell you if the reviewers are likely to accept your application.
I'm about to take my first foray into In-App purchases, and I'm not quite sure how to handle my situation. At top is my situation, with some actual questions in bold at the bottom. Any advice would be appreciated.
I'm designing an app that will have a LOT of in-app purchase content. Every day, around 20 or 30 new items will be generated for sale. 3 or 4 days worth of items will be for sale at any given time, and after that they go away.
So we're talking a lot of items. Way too many to add to submit to Apple for a unique ProductID each day.
Of all these hundred items, there are actually only 4 or 5 different types of item. So I'm thinking I'll need to make 1 SKProduct for each type. Under the hood (and invisible to the user) the will actually be buying a credit good for 1 item of type X. After the transaction goes through, I send the receipt AND the requested item to our server. Our server stores that and sends the file back. If they want a 2nd file, they need to buy a 2nd credit and repeat the process. Of course to the user it will be presented like they're buying Item 1, Item 2, and Item 3 directly.
To make this even more complicated, we also want to offer a 3 month subscription (at a significantly higher tier) for those who don't want to buy their items ala carte.
1. Does this sound like a good approach?
Will Apple be okay with this? If not, what possible alternatives do I have?
2. Optimally we'd like to allow people to re-download items they've already paid for.
Would a good approach be to make each credit non-consumable, and since I've already stored the receipt info on the server I can match it to whatever item they should get? If this is too complicated or against Apple's rules, we may just make the item consumable since the item is only good for a few days anyway...
3. Is there anything else I'm overlooking here?
Thanks for any insight you guys can provide.
Take a look about what the iOS Development Program License Agreement says about treating In App Purchases like credits:
2.1 You may not use the In App Purchase API to enable an end-user to set up a pre-paid account to be used for subsequent purchases of
content, functionality, or services, or otherwise create balances or
credits that end-users can redeem or use to make purchases at a later
time.
2.2 You may not enable end-users to purchase Currency of any kind through the In App
Purchase API, including but not limited to any Currency for exchange,
gifting, redemption, transfer, trading or use in purchasing or
obtaining anything within or outside of Your Application. “Currency”
means any form of currency, points, credits, resources, content or
other items or units recognized by a group of individuals or entities
as representing a particular value and that can be transferred or
circulated as a medium of exchange.
Correct me if I'm wrong, but if your approach does not unlock/add functionality or change the behavior of the app by buying an In App Purchase, my guess is that this could be problematic when trying to get Apple's approval.
Hope this helps,