The Trapp Store
10 min read

The Trapp Store

The ability for a company to viably offer their services outside of the App Store all hinged on one thing.
The Trapp Store

Up until roughly a week ago a partner had more choice when it came to launching an app. We covered what comes with the App Store in an earlier post, mostly from the standpoint of positive things, but we hoped to make the case that there are trade-offs. Then the rules changed and it wasn’t totally clear if this alternative approach was possible or not.

In the interest of closing the loop, there are 3 main sacrifices a partner would have made when they chose to go through the App Store.

Billing API and Revenue Share

Shopify has long required that partners pay up for what they call a ‘fair exchange of value’. The premise was that if the App Store is the source of discovery for a partner’s new customer, then Shopify can make claim to 20% of revenue. Not profit. Revenue.

This isn’t uncharacteristic for any app marketplace, but if the partner is trying to grow a legitimate company, a defacto hit of one fifth of all revenue certainly induces sweat. Add the fact that for some business models, this simply doesn’t work - consider shipping label resale. Margins in these businesses can be slim and sometimes negative on a per-transaction basis. In these cases, twenty percent eats all of the margin and leaves the partner without enough revenue to cover the cost of the label.

For situations like these, Shopify has become more flexible in working out agreements that maintain a business’ viability, which is welcomed, but that agreement comes after submitting to the App Store. This means a huge amount of good faith on the part of the partner must be invested prior to reaching the agreement, as a huge amount of time and resources must be invested in the app before knowing what the economics will ultimately be.

Additionally, the means to collect revenue from customers is rigid as well. If a partner operates on the App Store, they must use the Billing APIs. There are benefits to using the Billing APIs, such as easier retention (discussed in our last piece), but that requires them to mold their charge model to what the Billing APIs enable.

Further, if they sell any services with a true cost of goods sold (such as the shipping label example or print on demand goods), they’ll necessarily carry risk because partners can’t collect instantly. Instead, they create the charge and that will appear on the merchant’s next bill from Shopify. When Shopify collects from the merchant, it’s a few days after that before the partner will see the money hit their account.

This whole process can take longer than a month to reconcile, so the partner needs to be prepared to foot the bill and possibly see the money not come in at all. This is rare, but if a merchant churns or defaults, Shopify gets paid first, then the partner.


This one is pretty straight forward: you can’t use Shopify keywords. This substantially kneecaps a partner’s ability to market their product outside of the App Store and effectively ties their success to traffic generated through it.

The logic behind this is understandable; with Shopify owning the trademarks it makes little sense for partner to effectively drive up the cost of bidding. Shopify has its own interests in using those keywords to generate business. The challenge is then reconciling growth outside of the App Store while being on the App Store.

You see, until the recent changes, the revenue share associated with ‘fair exchange of value’ was largely based on business generation and discovery. If a partner could prove that the merchant lead came from outside of the App Store they could make the case that the revenue from said merchant should not be subject to revenue share.

If a partner’s marketing team is confident in their ability to drive traffic and not be dependent on the App Store for discovery, they could have saved a fifth of possible revenue by avoiding the revenue share.

Bad Leads

When a partner launches on the App Store, they’ll almost certainly get traffic on their listing and subsequently installs. This sounds good, but consider this a warning: not all customers are equal, and in fact some are downright bad for business.

As a downside of the organic discovery that has largely been enabled by Shopify, some of the merchants that will click the install button on an app listing page are straight up bad fits.

Sometimes this is because they don’t wholly evaluate a service before they try it. Sometimes it’s because they see a single tag line used in the listing, think ‘that’s me’, and don’t appreciate that the app itself probably does much more than that single thing, with the single thing they need being a less obvious to execute from a UX standpoint. Sometimes they have no intention to pay and are just cruising free trials. Sometimes they aren’t at a scale or don’t have the volume of data needed to make a service useful. Sometimes they’re perpetually victims and are fully prepared to fly off the handle at any service that doesn’t make them an overnight success.

In all of these examples, partners can count on the risk that hurts them most: bad reviews. With each review, Shopify considers your suitability and quality for stores, and when a partner can’t curate who they’re engaging, there’s bound to be decently consequential bad fits. Fortunately, Shopify’s enabled the ability for partners to reply to negative reviews and it appears those interactions carry meaningful weight among the merchants partners want to engage.

None of this matters anymore

The ability for a company to viably offer their services outside of the App Store all hinged on one thing, which was altered by both policy and product by Shopify on December 9th: the API client.

Subsequent to our previous post, we were going to discuss how using the API client was not contingent on being published. We were going to state that unpublished apps didn’t require meeting the standards of the App Store and then discuss how that came with benefits.

In the pre-December 9, 2019 era, partners could generate API clients and create an app listing with the same install button. This did not require you to be published meaning approved by the Apps Team. The caveat is that your listing would not appear on the App Store via search or any other discovery methods - instead it would only be found with a direct link. Further, when someone views the app a banner would appear stating that it was not reviewed by Shopify, and a further warning would happen during the install process.

This meant that partners had the option of selling the app through their own website, bypassing the Shopify listing altogether. This was relatively common for apps that are full platforms in their own right, but offered a Shopify integration, such as Front. It was also used, less commonly but to great effect, by apps like CartHook and Bold Cashier that were focused on Shopify but sold exclusively through their own channels.

If the tradeoffs of not being in the App Store were tolerable, the benefits to this could be significant. A partner could create a listing, market the listing, and avoid any revenue share or stringent requirements of Shopify by owning their own destiny (and overcoming the warnings of not being app store approved).

But none of this matters anymore.

As soon as the announcement was made, API clients were locked down and no app listing was generated. Instead, a partner has the ability to decide whether their app is listed or not, but only after they’ve been approved by the Apps Team. This means even the new unlisted apps on Shopify must be approved, and to be approved the lengthy checklist has to be met, including the use of the Billing API’s and any other scrutiny that can be applied.

Further, the Terms of Service extends a bit further now. In the past, it was the App Store and being published in it that bound a partner to certain requirements. Now that all apps require approval in order to make use of the API client, it’s the API client itself that comes with restrictions. Consider the following adjustments in verbiage.

From 2017:

‘The “App Plan” is a revenue sharing plan that allocates revenue between Shopify and an App Developer whose App has been selected to be listed in the Shopify App Store (each such App, a “Select App”). Unless otherwise agreed to by Shopify in writing, under the App Plan, an App Developer is entitled to eighty percent (80%) of the total revenues from the sale of, subscription to or charges relating to the Select App, with Shopify being entitled to the remaining twenty percent (20%)’

This fairly clearly creates the expectation that being published on the App Store is the instigating factor. Compare this to the newly updated terms as of Dec 2019:

‘The “App Plan” is a revenue sharing plan that allocates revenue between Shopify and an App Developer whose App has been selected to be listed in the Shopify App Store (each such App, a “Select App”). Unless otherwise indicated in this Agreement or agreed to by Shopify in writing, under the App Plan, an App Developer is entitled to eighty percent (80%) of the total revenues from the sale of, subscription to or charges relating to the Select App, with Shopify being entitled to the remaining twenty percent (20%).’

Indicated in this Agreement’. Pretty subtle change, but stay the course - it gets interesting.

Note: If you're a huge nerd, there's lots of fun to be had going through old versions of Shopify's partner terms with the Wayback Machine.

Part of the announcement last week was that all apps require public apps to be approved. Public means the app uses the API client, as opposed to a private app (replaced by 'custom' in the same announcement) which required a merchants API credentials on a store by store basis. A public app can be listed or unlisted - that’s a partner’s choice, but in the past, only listed apps required the approval. Today, both listed and unlisted apps require approval.

This means even apps that are unlisted require use of the Billing APIs. It goes like this:

  • If a partner wants to use an API client they must be an approved public app.
  • An approved public app must meet ‘Requirements for public apps on Shopify
  • Requirement 4.B - Billing: this page details the requirement for the Billing API to be in place to meet this standard.

Ok, now it can be said ‘the Billing APIs are distinct from the revenue share plan’. Sure, this would be true, but circle back to the Terms of Service, and see that Shopify includes a handy section additions putting the terms into plain language. Adjacent to the section mentioned above, you can see this:

‘WHICH MEANS: When an App Developer’s App is selected by Shopify to be published in the Shopify App Store, the App Developer is paid 80% of the total revenues for that App.’

Partners have the choice to toggle whether or not an app is listed, but that choice hinges on being published, which is squarely at the discretion of Shopify. In other words, plan for using the Billing APIs and account for revenue share. It’s new standard.

In No Uncertain Terms (of Service)

With the wave of a wand and a push of a publish button, Shopify has made this the new reality for all new app entrants to their partner program. Given that these changes live in the Terms of Service and are as well reflected by product changes around how API Clients are granted, this new world can confidently be accepted as the one we live in now.

With that being said, there are some lingering curiosities and residual questions. Two, in particular.

1. Class Systems and API Client After Market

The first references a statement in the announcement:

There are so many partners who have spun up API Clients and have not done anything with them, not to mention the partners that operate under the pre-December 9th status quo. This begs the question: how long until we see partners selling their unused clients?

Perhaps more importantly, how long until Shopify reconciles old API clients?

The Railspur bet: not long.

Shopify must know that this is an inequality being created, as surely as it deals with sweetheart legacy revenue share agreements. It also fails to address the fact that the change at this moment doesn’t affect nearly the entirety of existing apps and partners perpetuating this supposed problem. Hmm. On second thought, maybe this isn’t about trust at all?

2. The Trojan Horse of Trust?

This announcement isn’t applied to a single active API client in the ecosystem generated before December 9th. This means that any existing instance that this change is designed to correct remains unaffected. Suspicious.

Then again, what does this do for trust anyway? Presumably partners recognize the effect those 'app-not-reviewed' warnings can have. The partners that proceed down this path must see it as the lesser of evils versus doing what ever it takes to get published. Surely they still see sufficient adoption by merchants, and merchants, in seeing the warning make their own decisions to install them.

The underlying message behind the word “trust” in this context is security, which has always been a problem with Shopify Apps. The nature of web apps is that they can change at any time – the app that was published after a review is very likely to be built on, modified, and changed in the days, weeks, and months after publication. Once a merchant’s data is inside an app, Shopify has no control over how that developer (mis)uses it. Their ability to security check apps is abysmal.

The problem with Shopify using this trust angle is that they’re perceptually taking on a lot of risk – merchants read trust and believe Shopify has vetted that these apps are secure – when Shopify has almost no ability to say that the app is, in fact, safe. It’s taking ownership over a piece of the merchant decision-making puzzle that they’re in no way capable of verifying. Shopify knows this, so why might they be playing up this trust angle?

This does nothing for trust and stands to invoke skepticism around of any partner facing narratives that Shopify puts out. It begs questions of transparency, as to whether or not this is a red herring for something else. Partners depend on levels of transparency to plan their own businesses, so communicating the motivations for any changes should reinforce that trust, not raise questions.

Altogether it feels much more like a Trojan horse where the horse is ‘trust’, but the secret inside is revenue. It’s nearly impossible to believe that partners currently unaffected by this will be exempt in perpetuity, and what better way to create compliance other than seeding the need for changes. If you treat someone as special one day, you can ask more of them the next, like asking them to adopt new practices.

Let’s talk about this more in 2020.