1. Who absorbs cost of fraud on IAP?
You do. Write code that verifies the receipt and cannot be backed-up.
2. How can we identify which users were refunded?
Refunds for consumable IAPs is very very rare. Apple understands the scam.
3. What are Apple's thresholds/limits for IAP?
Please explain your question.
4. Is Apple refunding users for Consumable products? Will they refund only last purchase or multiple purchases?
No one on this forum has ever complained about excessive refunds for consumables. There is no public data available. I suspect Apple would not grant a user a second refund for a consumable IAP - again, they understand the scam.
5. If Apple does not provide PII (personally identifiable information), what can we do to dispute or block bad actors.
You have no need to block a bad actor. Write your code to grant consumables only if the app receives a call to updatedTransactions with a valid receipt. If anyone complains tell them to contact Apple because there is nothing you can do. OR....ask them to send you their emailed confirmation billing receipt from the App Store that will indicate a purchase made by 'them'. In 10 years I have had only a few such 'complaints' and when asked to send the receipt most slither away. The few that sent me something I comped in some way. I recall one person insisting I send them a check for $0.99. I did, it was never cashed!!!!
6. Is Apple leveraging the Server to Server communication for Consumable Products (from their docs, seems to be only subscriptions). Can we be informed about refunds real-time?
7. Whichever report we get (monthly or earlier), what is the granularity of data? do we come to know the returns by customer?
No - Apple protects its customer base. You can put something in the app to send you information when a user makes a purchase. But you can't require the user to share personal information with you. You can get a unique identifier for the user's device and for the user's Apple ID Account using identifierForVendor, writing something to the keychain, writing something to iCloud or relying on the CloudKit user record.
Thanks for your answers, I suspected most of them. In term of thresholds/limits, right now as we are using Credit Cards, we have daily, weekly and monthly add fund limits for users who are less than 90 days old on our platform. This is to prevent chargebacks. We have a refund policy on our web site and current app which would also go against Apple's refund policies. BUT as you stated refunds are very rare on Consumable products, so we could be good. However a user that gets refunded by Apple would also possibly get refunded by us if such user gets in touch directly with us.
We are planning to do local validation of receipt per Apple recommendation as well as remote using our secure server and store receipt on the server.
In term of providing monthly reports, how do you reconcile the money that is paid by Apple and the money we would give to our life coaches? (I had previously posted the real time nature of our chat service that has been blocked by Apple because we are using Credit Cards). Would you do a manual download process from their site and import the data in our system? I assume Apple does not provide an API for pulling data. Any example Apple or anyone can provide so we are prepared on format...?
Again, what about Fraud on Credit Card associated with an AppleId? If a user spend $5000 via IAP and Apple then realizes that the card is fraudulent, is the cost of the fraud passed on to us or would Apple pay for it? I susuapect ther are constantly runninch checks, but no public data is available.
> However a user that gets refunded by Apple would also possibly get refunded by us if such user gets in touch directly with us.
Nope - tell all users who ask for a refund that you can't do that - they need to get the refund from Apple.
Do you really have that many refunds that this is an issue or are you overthinking what-ifs?
>In term of providing monthly reports, how do you reconcile the money that is paid by Apple and the money we would give to our life coaches?
You don't. The app figures out who is owed money and how much based on what the app knows it did. AND - AS I RESPONDED IN YOUR OTHER POST - you don't (aka can't) use IAP to charge for real world services. Tell App Review that the chat functionality is separately charged through IAP. The services are paid through your third party credit card system (or Apple Pay).
>what about Fraud on Credit Card associated with an AppleId? If a user spend $5000 via IAP
I suspect they would issue a cancellation_date receipt and not disburse the payment to you. But since all you are doing is selling access to the code in an app you will not be out very much. That is unless you use IAP to charge for real world services. And again, credit card fraud is very rare. You may be overthinking a what-if.
Why do you care so much? If you are anticipating a high level of refunds, then you risk being thrown out of the app store altogether. Apple isn't any different than other merchant providers in this regard. Any legitimate ones have a low tolerance for fraud. If Apple has to do extra work to deal with your customer complaints and refund requests, they may decide that your business isn't worth their effort.
Generally speaking, you have no access to any customer information of any kind. The transaction numbers that customers see are different than the ones that you can get out of a receipt. All you get are totals sales (or refunds) subtotaled by country two months later.