Hey Bill: Some more thoughts since I didn't answer all your questions.
In-app purchases will get you more subscribers than making them enter a credit card online so there is an advantage you should consider may make up the difference of the cut Apple takes. You are transferring the pain of payment from the user to you. You go here and sign up and enter your merchant account info, and then you don't need to think about it anymore, payments will end up in your account. https://developer.apple.com/in-app-purchase/ <https://developer.apple.com/in-app-purchase/> Something to think about. And no, you can't use Stripe with your in-app purchases with Apple unless it's just a merchant account you can supply to Apple. That would be convenient for sure. Anyway, read about the in-app purchases at that link, and then read the docs on the ANE as you will find it's pretty simple. Like a half-day or so of effort. Cheers, Erik On Oct 20, 2018, at 11:09 AM, Erik Thomas <erikjtho...@icloud.com> wrote: Hi Bill: I'm assuming you expose your sign-up functionality for the Apple reviewer and that's how they know what you're doing. The reason Apple is giving you a hard time is they want their cut of your money and will do whatever they can to make you use in-app purchases for your subscription model. I'm sure this requirement is buried in your Apple developer account agreement small print somewhere, so it's not illegal, but is it ethical? #2 doesn't necessarily get you past the Apple reviewer if they can click your sign-up link and go to Stripe. The difference between signing up in an embedded WebView hosted signup page and doing so through Safari isn't any difference in the eyes of Apple. I think you're stuck with using in-app billing for Apple anyway. I use Distriqt ANEs and recommend this one--which will get you Android and iOS in-app purchases with a single API: https://airnativeextensions.com/extension/com.distriqt.InAppBilling <https://airnativeextensions.com/extension/com.distriqt.InAppBilling> You'll still have to implement a separate sign-up channel for the desktop AIR versions since the Distriqt ANE doesn't do AIR desktop. There may be an AIR desktop ANE out there somewhere but I suggest you use your existing Stripe for desktop, and use an ANE for iOS and Android. That is unless you use Mac App Store to distribute your AIR desktop app because you will likely run into this same issue for the Mac App. I also recommend hosting your Mac and Windows installers on your own website and NOT distribute through Microsoft store or Apple Store. And if you haven't done Microsoft store yet, plan on a LOT of work to make that happen. Not worth it, IMHO. Erik On Oct 19, 2018, at 4:27 PM, bilbosax <waspenc...@comcast.net <mailto:waspenc...@comcast.net>> wrote: I know that this is an odd place to ask this, but there are relatively few active forums to ask about Adobe Air. Although it had passed app review twice, I had an app rejected recently from Apple's App Store because it does not use the in-app purchase API. My app is a real estate app that you can log into, or if you don't have an account, you can create it in the app and pay for a monthly subscription. Since it is a cross-platform app for Android, Apple, and desktop, I wanted just one payment solution to make it simple, so I chose Stripe. I open a webview in the app to pay for the subscription. Apple claims that my content is locked until payment is made, so I am required to use the in-app purchase API to unlock the content. Now that I am so far into development, this could be a huge change that adds a lot of time to my actual release. I have two options as I see it: 1) Implement in-app purchase API somehow into my code 2) Give the user the option to Sign Up or Log In. If they choose to sign up, redirect them to my website in safari to sign up and use Stripe as I have already laid out. Once they have signed up they can then move back to the app and simply Log In. I know absolutely nothing about in-app purchases. I always thought that they used Apple Pay, which I would prefer not to do. Can the in-app purchase API work with my Stripe Account and subscription products that I created there, or would I be forced to transform my whole workflow? Of the two options I listed above, which would you choose? Any ANE recommendations? Thanks for any insights! -- Sent from: http://apache-flex-users.2333346.n4.nabble.com/ <http://apache-flex-users.2333346.n4.nabble.com/>
