Typically Apple and Google will consider coins and credits a type of digital currency. Under their terms and services these types of products in an application must be transacted through the AppStore and Play Store so they get the 30% cut.

When I worked for Groupon, building their Android application, they were not required to use the IAP from either platform. This is because they were selling a product or service. As you stated - you're selling a service. You may need to change the wording from "Credits" to "Balance" (or something similar to that) and have that reflected as actual dollar amounts in the app. I would also be very clear that you are selling a service - not digital goods. If this is truly what you are doing (selling a service), then you should be in the clear.

Disclaimer: These TOS change all the time. The last time I dove in and read one end to end regarding IAP was about nine months ago. But I'm fairly certain the service and product thing still applies. You may want to consult your lawyer and review the TOS with them to be sure you're not in the grey area.

Succinctly, Apple is absolutely horrible to deal with for making apps, and they really do not like 'workarounds' and will ban your app if they get a hint of one.

That being said, here is a way you could potentially make it work out:

1) In your iOS app, charge more than in your android app, to cover the 30% take by Apple.

The creates another problem: it's too expensive.

2) To work around that problem use this: http://playseeds.com/
It's a new in-app-purchases model that cycles the payment money into microloans for people in developing countries, then you get the payback. I think you get the payment right away as if it's a normal payment (i.e. all the loan, and payback etc. happens in the background without you being affected). That payment model greatly increases user willingness to make a initial and repeated purchase.

Best of luck

Lee

Download Panda Helper

The use case I am describing is when a user’s purchased inventory is tied to an organizational user account and is tracked by an external service. For example, when a user buys a song from your mobile app on iOS or Android device, and then logs in to a web version of your app, the song should be instantly available to play in his/her collection. One of the in-app purchase types that is not compatible with cross-platform payments is the App Store’s non-consumable type. If your app sells non-consumable, auto-renewable subscription, or non-renewing subscription products, you must provide users with the ability to restore them. If you want to sell a cross-platform product that can only be purchased once, after reading the Apple definition, you may think that non-consumable type is the answer, but the additional requirement may confuse you. There is also one place where documentation mentions multi-platform services, but it does not say anything about non-consumable types. One of the features of App Store’s Store Kit is the ability to manage inventory of purchased items, meaning it will be responsible for filtering out items that were already purchased. This is handy if a user has lost or bought a new iOS device because it offers the ability to restore purchased items. However, when you let Apple manage your inventory, the purchased inventory will be tied to a user’s iTunes account and not your cross-platform user account. As soon as a user makes a purchase you top up his/her organizational account with content and consume the item. This inventory service is also used to filter out items that were already purchased because Apple is not a system of record anymore. Making all you are in-app purchase products consumables, even for items that can only be consumed once, might make you nervous, especially if you have not gone through the apple approval process before.
Besides if you do have any questions give me a call: https://clarity.fm/joy-brotonath