In my role as a Sales Engineer at Zuora, I’m often asked about how to acquire subscribers and take payments from a mobile device – and whether it is necessary to pay the 30% margin to the app stores run by Apple, Google or Amazon.
This article aims to provide an answer.
How do I acquire subscribers and take payments from a mobile device?
Many Zuora customers use us to power their mobile experience. This includes companies such as Box, Lynda.com, Shutterfly and Fairfax Media, an Australian media company that publishes several major papers, including the Sydney Morning Herald.
You can deliver Zuora’s functionality (such as signing up a new subscriber and taking payment details, or allowing an existing subscriber to manage or upgrade their plans) on a mobile device via two approaches.
1. Create an app that can be downloaded from the Google or Apple app store.
These apps run on the native mobile phone operating system (iOS or Android), so they’re called “native” apps. In this approach you might call the Zuora REST or SOAP APIs through the code you use to create mobile app. You might also take advantage of the web browser built into modern smart-phones to embed web pages inside the native app. These embedded web pages can also call Zuora’s APIs, the same as you would on your normal web site (which leads to option 2).
2. Create a version of your web site that is optimized for use on mobile device.
These mobile sites often use a web development technique called “responsive design” to create a mobile-friendly site. The mobile site may also mirror the experience of a native app. For example, Gmail and LinkedIn both have mobile sites that look and behave very similar to the native mobile apps. However, the key difference is that these mobile sites are not available for download in an app store.
Regardless of the approach, you would usually use Zuora’s Hosted Payment Method (HPM) pages to capture credit card or bank account details in a PCI compliant way. HPM page can be rendered in any web browser and support responsive design, so they display well on a small screen.
Given the distribution power of the various app stores run by Apple, Amazon and Google Play, you will probably want to use the first approach and create a native mobile app for download. The good news is there is absolutely no technical reason why you can’t acquire or upgrade subscribers, and take payment details, from within a native mobile app.
So what’s the problem?
Unfortunately, there may be legal reasons you can’t sign up and upgrade subscribers or take payment details from within an native app created through the first approach. This is because of the terms of service imposed by Apple, Amazon or Google. For instance, the limitations imposed by Apple are found within section 11 of the Apple developer guidelines:
11.1 Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected
11.2 Apps utilizing a system other than the In-App Purchase API (IAP) to purchase content, functionality, or services in an App will be rejected
11.3 Apps using IAP to purchase physical goods or goods and services used outside of the App will be rejected
[…]
11.12 Apps offering subscriptions must do so using IAP, Apple will share the same 70/30 revenue split with developers for these purchases, as set forth in the Program License Agreement
11.13 Apps that link to external mechanisms for purchases or subscriptions to be used in the App, such as a “buy” button that goes to a web site to purchase a digital book, will be rejected
Put simply, Apple (and Amazon & Google) require you to acquire subscribers via their app store and take payments via their In-App Purchase capability, so they can collect the money through the customer’s Apple / Amazon / Google account and take their margin – usually around 30%.
Do I have to pay that margin?
As a result of these legal limitations, some Zuora customers simply don’t allow their user to sign up or upgrade from within the native app. Similarly, they don’t collect payment within the app, or even put a direct link to a purchase page on their mobile site.
Instead, these companies typically offer some form of encouragement (external to the app) for users to go to the web site, where they can sign up and enter their payment details. For example, the Lynda.com iPhone app lets you watch some videos and login to watch more, but it doesn’t let you sign up to become a member. Instead the user has to go to the Lynda.com website and sign up there.
There is an important escape clause: Apple’s guideline indicate that you only have to use In-App Purchase “to purchase content, functionality, or services in an App.” Section 11.3 actually prevents you from using In-App Purchase to buy real-world goods or services, such a physical box of products or a roadside assistance service. As a result, some Zuora customers, who provide services outside the app, can use the first approach to acquire subscribers and take payment details from within the native app.
What if I’m okay with paying the margin?
In some situations, you might be okay with paying the margin, because it means you can reach more subscribers through the app store. Unfortunately, Apple, Amazon and Google won’t let you invoice and take payment for the full amount, and then rebate the margin. Instead, your subscriber would need to use In-App Purchase as discussed above. In this situation, your app should also trigger the API calls to create the subscription within Zuora, as source of truth for the subscriber identity and entitlements.
Implementing this type of integration means that data about these external subscriptions can flow from Zuora through to other systems such as your CRM or provisioning solution, the same as all other subscriptions managed by Zuora. By having the external subscriber within Zuora, you will be able to better handle multi-channel interactions, such as where the subscriber calls your service center or goes to your website to upgrade, rather than doing it in the app. When this happens you can start to bill the subscriber directly without having to pay the margin.
This integration would also let you communicate with the external subscriber, for instance to send them your own invoice or statement as a way of confirming they have subscribed to your product. If you do want to send the customer your own invoice, there are two options you might consider when creating the subscription in Zuora:
1. Put the subscriber on a plan with the same charge as seen on app store (eg $10 per month).
Your invoice would show this charge along with a matching payment ($10 again), so that the invoice is marked as fully paid. This $10 payment, made through In-App Purchase, would be recorded as an external payment via Zuora’s APIs. The advantage of this option is that you’ll get an accurate picture of subscriber value and Zuora can give more your complete subscription finance data.
Of course, you’d have to allow for the margin when you reconcile payments received as part of the accounting close process. This is because you would have an Accounts Receivable (AR) amount of $10 and a payment of $10 recorded against the invoice, but Apple, Amazon or Google would only transfer $7 to your bank account after they take their 30% margin.
2. Put the subscriber on a no-cost plan.
Since the plan has a $0 charge, your invoice will also show the total due is zero. This approach is easier to set up, as it means that no Accounts Receivable (AR) is raised and no external payment needs to be recorded. However, it does mean that Zuora won’t be able to give you a complete picture of your subscription finances and you’ll get an inaccurate view of the true value of your external subscribers. For instance, the Monthly Recurring Revenue (MRR) value of these subscribers would show as zero.
Of course, if you don’t need to send the subscriber your own invoice or statement, you can simply sign them up to a plan with charges set to 70% of the public price. That way your AR will be consistent with the payments sent to you by the app store.
If these options are a bit daunting, don’t worry. Zuora’s Global Services team can work with you during the implementation process to work out which option makes the most sense for your business.
The Takeaway
There may be legal (rather than technical) constraints that prevent you from acquiring subscribers and taking payments from within a native mobile app. However, there are ways around this for companies who offer physical goods or who can get subscribers to sign up directly.
However, if you do want to let Apple, Amazon or Google to manage the subscription and take the payment (and their 30% margin), you can, and should, still use Zuora as the source of truth. That way you can have a single place to manage all your subscribers and handle the changes that will occur as part of the subscription lifecycle.
If you’d like to know more, feel free to drop me a line at tym.lawrence@zuora.com or get in touch with Zuora.