To add some context to the other reply: Apple doesn't take ANY cut of Apple Pay payments, even on native mobile apps. Apple does, however, require that app store apps ONLY allow the purchase of physical or similar goods with Apple Pay. For instance, they'll reject an app that uses Apple Pay to allow the purchase of eBooks, instead of the in-app-purchase API (which does take a 30% cut). This is why Kindle forces you to the web to buy eBooks, but allows you to buy physical amazon goods in the native app.
Similarly how you can use Apple Pay to call an Uber/Lyft in-app.
That said, Apple Pay is just a layer between you and the user's credit card - there's no functional difference at the transaction layer between accepting Apple Pay and having a credit card form in your App. This is why Stripe/Paypal et al. all 'support' Apple Pay. You still need a payment processor who can take the Apple Pay token and turn it into a transaction that puts money into your account.
The in-app-purchase API, however, directly charge's the user's credit card on file with Apple and is credited to your developer account as a payment.
TL;DR Apple Pay is a layer between customer and payment processor, IAPs are a layer between customer and merchant. Apple takes 30% of IAP. Payment processors of Apple Pay take a cut before passing payment on to merchant (Stripe is 2.9% + 30c/transaction, for instance).
You sure about those TOS requirements? Last I checked all you needed was a separate website providing equivalent service. If you charged for a subscription on the website, and you have an app too, then the user should be able to use your app since they've already paid the subscription.
Sorry, I may have been unclear. If you've already paid outside of the native app Apple won't prevent users from accessing the content (Netflix is an example of this). The rule only applies to purchasing within the app itself. Apple requires that if your app allows a user to purchase digital goods it must be via an IAP. There's no restriction on users accessing content they've already payed for elsewhere.
Somewhat related: It doesn't seem to be the case anymore but I have the distinct recollection of paying for Hulu through the iPad app as an IAP at a subscription price of $13.99/month only to discover Hulu was charging $11.99/month if purchased through their site. I think Apple cracked down on folks with different IAP pricing vs. direct subscription pricing, but for a while it was a very frustrating effect of the 30% cut that you're forced to give to Apple if you want to allow any in-app subscription on an Apple device.
Edit: I was right, they just recently dropped it when they rolled out their redesign
Similarly how you can use Apple Pay to call an Uber/Lyft in-app.
That said, Apple Pay is just a layer between you and the user's credit card - there's no functional difference at the transaction layer between accepting Apple Pay and having a credit card form in your App. This is why Stripe/Paypal et al. all 'support' Apple Pay. You still need a payment processor who can take the Apple Pay token and turn it into a transaction that puts money into your account.
The in-app-purchase API, however, directly charge's the user's credit card on file with Apple and is credited to your developer account as a payment.
TL;DR Apple Pay is a layer between customer and payment processor, IAPs are a layer between customer and merchant. Apple takes 30% of IAP. Payment processors of Apple Pay take a cut before passing payment on to merchant (Stripe is 2.9% + 30c/transaction, for instance).