I am trying to figure out which type of payment is the most appropriate for a given situation. I am pretty sure there must already be a similar question somewhere but I seem to be asking wrong questions when searching for it.
Application will give user ability to store and manage any amount of certain data type for free. There will be a paid option to selected certain data for processing. Once done processing the output of process will be visible for this user within the same application.
As I must not describe a specific situation I will add theoretical example to give better description: We are building an application where user can import images from his gallery. He can have any number of images in application, add more, delete them... There is an option where user may select a single photo and send it to our service for processing. Once processing is done another photo will be returned which has all faces on image blurred out.
So which type of payment is most appropriate in this case and which types are completely out of question? This is what we considered so far:
Subscription
We do not want subscription because we expect that users will use this feature every now and then. Basically we expect most users to only use it once. If a user uses this feature 10 times we already consider him as a power user. We also expect that this usage will be stretched over years, not days (So someone may use it once a year). For that reason we can expect that users would need to subscribe, use the feature, unsubscribe.
None-consumable IAP
Initially this sounded like a most fitting solution. But the problem is that we would need to offer personalized items for each user to utilize this. I am not even sure if this is doable; create a new IAP item for every request that user makes.
Another idea was to buy the same IAP multiple times. As far as I understand this is not possible. However, I have seen an app that had IAP in place and had an option to "donate" using IAP multiple times. Now sure how they made that possible but now I'm thinking that they spawned some number of IAP items, all with same description and price and users would be iterating through them when donating multiple times. We could do a similar approach but it does not feel right.
Consumable IAP
This one seems technically doable but is this correct? We would create some soft currency which user would be able to buy and consume within his application. I feel like this approach may be rejected by Apple. Plus it may look fishy to users.
Apple Pay
Personally I find this the most correct one. We could implement Apple Pay in our application and user would simply confirm transaction when sending item for processing (or before viewing when received). But is this correct usage of Apple Pay for this case or can we expect some pushback from Apple reviewers that because we use this content only within the application we need to use some from of IAP?
If each time you repeat the operation you must pay it is a consumable. If the first time you pay the feature is unlocked for life it is a non-consumable.
You are not allowed to use Apple Pay if you are selling a digital good. There are exceptions like a 1 to 1 digital meeting, coaching, appointment but doesn't sounds like it.
Note that you can purchase multiple consumables at the same time.
I wrote an article about that categorisation and other stuff and gave some other examples. Have a look at the "Define your products" section.