Taking iOS payments in-house? Here’s how to measure it with your MMP

Planning to take iOS payments in-house? Great, but now you also need to know how to measure off-App-Store payments with your MMP.

Here’s how …

Paying for in-app purchases via third-party or your own e-commerce solution is now fully legal for iOS apps in the United States, thanks to Epic Games’ lawsuit against Apple. (If you’re thinking about doing just that, here’s a framework to use to help you decide) But savvy marketers know that before they can celebrate with a ticker-tape parade down main street in Cupertino, they need to ensure that they can tie revenue from users to their costs so they can continue to run smart user acquisition campaigns. 

Otherwise you are flying blind. You’ve broken your ad campaign optimization feedback cycle because you can’t connect costs and commerce.

So here’s how you connect MMP measurement to taking iOS payments in-house.

3 options for iOS payments now

There are essentially three ways to take iOS payments now, including the legacy way of just letting Apple manage it for you.

1. App Store iOS payments
   Same old same old … in-app purchases mediated by Apple. Simple, friction-free, and 15-30% commission to pay.
2. Web store iOS payments
   Usually for web2app acquisition flows or for dip-outs … popping users out of their in-app context, into a web-based store, executing the purchase, and flipping them back into your app with a deep link. This can also be done prior to app install, which is common in many web2app subscription app flows, and completely independently of any app session.
3. Webview iOS payments
   Though technically it’s close to #2 above, it’s not exactly equivalent. Webview is popping open a browser instance in-app, thereby keeping your users in context as much as possible.

In the App Store model, Apple takes the payment but also does something else very important: notifying the app that yes, a user paid for X so you can now release X to them in the app.

In the web store model, a payment processor like a Stripe or a PayPal, or a service like RevenueCat (which now offers paywalls), takes payment and then issues a callback, often via an SDK, so that your app knows to release the product. The big positive of the web store model is that it’s a full browser experience with full access to existing cookies and logins. So if a user pays for something once, creating an account, their payment information can be stored and re-used without re-entry for subsequent purchases. In addition, at least theoretically, users could go on a different device — such as their laptop — to complete a purchase there, then see the benefit in your app.

The webview model is the best in terms of keeping users in context of your app, but there is a potential downside. Webviews on both iOS (WKWebView) and Android (WebView) are sandboxed. That means the web content is isolated from the native app’s internal data and other system resources, but also that in some cases, you can’t access a user’s existing cookies and logins.

(Exception: when you actually ship an in-app browser, such as SFSafariViewController, which is essentially a full Safari instance inside your app.)

That means that even if users have existing accounts with Stripe or PayPal or RevenueCat, they may not be accessible without a login process, which adds friction. And, if users don’t have existing accounts with payment processors, they may need to take that dreaded next step of hauling out a wallet, finding a credit card, and tediously inputting all their details.

(Never mind having to potentially 2FA a transaction with a suspicious card issuer who sees an unknown store attempting to charge a card.)

That’s where hard-core friction could happen.

Important: keep your channels clean

Channel confusion used to be something only CPG vendors needed to worry about. Was it a TV ad, the store flyer, an influencer, or some other distribution or marketing channel that influenced a sale?

No more: now app publishers need to think about it as well.

If we generalize “channels” to where a product is sold, for mobile app payments, you’d clearly have 3 specific channel possibilities: the ones above.

But are there really 3? Isn’t it just 2, because Web store and Webview essentially will use identical functionality behind the scenes in terms of payment processing and data sharing back to your app? In a way, yes, but it can get confusing. 

It’s early days, but at Singular we’d argue that in-app purchases should be thought of as in-app purchases, wherever they actually occur. That’s an app-centric way of looking at your revenue because your key deliverables are in your app.

And what that means is that at the end of the day, any “off-app” iOS payment or purchase that is completed should be reported and tied back to the mobile user/device itself. Ultimately it has to, because you have actually deliver the purchased item or service to your user, customer, or subscriber. In addition, this ensures that revenue remains connected to user acquisition, which keeps ROI/ROAS/LTV calculations clean.

(The other option, of course, is tracking these off-app-store payments as web events or cross-device revenue … which would be challenging in any case because the payment portals are probably owned by your payment vendor and not you, the app publisher and marketer.)

Connecting iOS payments to people

There are a variety of technical ways to get the web payment associated with the mobile user/device, and they’ll have some different pluses or minuses in terms of in-app integration and challenges from the payment process side.

1. Direct integration with each payment vendor and the event with the device ID and/or customVendorID via server-to-server communication
2. Callback of “successful payment” from payment vendor SDK/API either server-side, or back in the client, then forwarding the revenue event back to Singular in the Singular SDK

Eventually there will be super-clear and simple options, but #2 is currently extremely doable.

The big question will be how the big payment platforms iterate around this. Ultimately marketers need to measure in-house purchases as in-app purchases, not web, to avoid channel confusion and make ROI/ROAS trackable, and Singular will support that.

What about Android and in-house payments?

The interesting thing is that with all this happening on iOS payments, it’s easy to forget about Android.

Over the past few years Android has been undergoing significant changes regarding third-party billing options, both through Google’s initiatives and legal mandates. For example, Google’s “User Choice Billing” pilot allows eligible developers to offer an alternative billing system alongside Google Play’s billing system. This program is currently active in over 35 countries, including the U.S., U.K., Canada, Australia, Brazil, Japan, and the European Economic Area (EEA).

The problem is much like the one that prompted Judge Yvonne Gonzalez Rogers to order Apple to drop any commissions or fees on out-of-app payments.

Google’s commissions don’t go away … they just drop a little. A very little: developers receive a 4% reduction in service fees for transactions processed through alternative billing systems. And, you must use Google’s alternative billing APIs to participate, so Google sees all your revenue.

This could change, however, and for the same reason that Apple changed.

Epic didn’t just sue Apple, they also sued Google.

In October 2024, a U.S. federal judge ruled in favor of Epic Games in an antitrust lawsuit against Google, declaring that Google’s Android app store holds an illegal monopoly. The court ordered Google to make significant changes to its Play Store operations to foster competition. 

Those mandated changes include:

• Allowing third-party app stores to be distributed within Google Play
• Permitting developers to inform users about alternative payment methods and download options outside Google Play
• Prohibiting Google from requiring the use of Google Play Billing for apps distributed on the Play Store
• Restricting Google from offering incentives to developers or device manufacturers to favor Google Play over rival stores

Those changes were to have taken effect in November of 2024 … but Google has filed an appeal and requested a stay on enforcement of the injunction. 

So there it sits, for now.

Talk to us … we can help

If you are thinking of taking in-app purchases in-house, talk to us. We can help you walk through the process of doing exactly that while also keeping your measurement, analytics, and campaign optimization intact.

Book some time today.