Does a split-billing model satisfy 1.2.1? (Shopify-origin installs -> Billing API; pre-existing platform customers -> direct billing)

Shopify App Store
,
1

Hi, I’m looking for guidance on whether a billing structure we’re planning satisfies requirement 1.2.1 before we build it.

Context:

We run a creator-marketing platform: brands sign up on our website, work with creators, and we charge the brand a small commission (3% of attributed sales + 1.5% service fee) when a creator drives a sale. Our Shopify app (unlisted, public) connects a brand’s store for order attribution and sample fulfillment. Brands can also use the platform with no Shopify store at all (Amazon/Meta channels).

The app is currently suspended under 1.2.1. In an earlier review round a reviewer instructed us to check the “I have approval to charge merchants outside of the Shopify Billing API” option; a later round correctly identified that we hold no such exemption. We are not requesting an exemption and we’re unchecking that option. We want to fix the structure itself.

The design we plan to build:

1. Shopify-origin installs (merchant finds/installs the app before having any account on our platform): on connect, the merchant is put on the Shopify Billing API, a $0 recurring app subscription with a usage-based line item and a merchant-approved capped amount. All our fees for these merchants are billed as usage records through Shopify. These merchants never reach our external (Stripe) billing flow, it is structurally unreachable for them, not just hidden.

2. Pre-existing platform customers (brand signed up on our website first, then later connects their Shopify store): their existing direct billing relationship with us continues unchanged.

3. The billing rail is fixed per merchant at connect time based on which relationship existed first: no switching, no choice presented in-app.

Questions:

1. Does this split satisfy 1.2.1 for an unlisted public app, with no exemption involved?

2. Where exactly is the “pre-existing customer” line for a free-signup platform? Is it enough that the account existed before the install, or does the merchant need a card on file / fees already paid before installing for direct billing to be acceptable?

3. For a Shopify-origin merchant, do fees arising from non-Shopify channels (e.g. our Amazon or Meta attribution for the same brand) also need to go through the usage line item? Our conservative default is yes, everything for that merchant goes through Shopify Billing, but we’d like to confirm whether 1.2.1’s scope is store-related charges or all charges to that merchant.

Thanks, we’d rather get this right in writing before building than iterate through review again.

2

Hey @Kiran_Nara - thanks for reaching out :waving_hand: . Based on the guidance in a couple of similar discussions, your proposed structure generally lines up with requirement 1.2.1:

  • Merchants who discover and install through Shopify should use Shopify App Pricing or the Billing API for subscriptions and usage.
  • Customers with an existing paid billing relationship before connecting Shopify can generally keep their direct billing. I’d tie this to an existing paid subscription/billing relationship, rather than simply an account that was created for free.
  • The billing path should be fixed and fully separated, so Shopify-origin merchants can’t reach your Stripe checkout, pricing, credit purchase, or upgrade flows.

These related threads may be helpful:

For fees generated through other channels, routing everything for a Shopify-origin merchant through Shopify Billing is the safest approach. There isn’t a precise public boundary for whether Amazon/Meta-related usage would be considered separate from the app, so I’d avoid exposing any off-platform billing path for that merchant.

The approval option should not be needed solely because an existing paid customer is retaining their pre-existing billing relationship, provided Shopify-origin merchants cannot access that flow.

That said, approval will ultimately depend on the exact implementation and the paths available to each account type. App Review would make the final decision based on how these flows work in practice, so I can’t guarantee approval from the architecture description alone.

Hope this helps!

3

Hi Alan, thanks for the detailed answer on this thread. We’ve now built the split against those three points and wanted to lay out what we actually implemented, in case anything stands out as wrong before we resubmit.

Shopify-origin merchants → Billing API, 100%. On install we provision an appSubscriptionCreate with a $0 recurring line item plus a usage line item and a merchant-approved capped amount. All fees post as appUsageRecordCreate against that subscription. This covers every channel we bill for, including fees originating from non-Shopify channels: per your note that routing everything through Shopify Billing is the safest approach.

Pre-existing customers → direct billing, but tied to a paid relationship. Following your point that this should be an existing paid billing relationship rather than a free account, we inverted our original rule. A merchant only stays on direct billing if they had a card on file and an accepted fee agreement timestamped before the install. We’re usage-based rather than subscription-based, so there’s no recurring plan to point at: the paid relationship is card-on-file plus an active signed fee agreement.

The paths are separated server-side, not just in the UI. The rail is decided once at install and is immutable (enforced by a database trigger). Every external-billing route: payment method setup, saved-card confirmation, billing portal, plan changes, returns a 403 for Shopify-origin merchants rather than being hidden. A Shopify-origin merchant has no reachable path to external billing at any layer.

We’ve also unchecked the approval attestation and declared the usage charges in our listing pricing. We’re not requesting an exemption.

Just one question: Is card-on-file plus an accepted fee agreement, both predating the install, a reasonable reading of “existing paid billing relationship” for a usage-based platform with no subscription tier? Or does the bar require fees actually charged before the install?

4

Hey @Kiran_Nara - thanks for the followup here

One clarification on my earlier reply: “existing paid billing relationship” was based on the existing-customer scenarios discussed in those linked threads, rather than a published test for usage-based platforms. The clearest example involved a customer already paying through Stripe before installing the Shopify app.

A card on file plus an accepted fee agreement gives you more evidence of a pre-existing billing arrangement than a free account alone. What I can’t confirm from the published guidance is whether that’s sufficient before the first charge, or whether a completed payment is required. I wouldn’t want you to make another billing change based on an assumption either way.

Since you already have an App Review conversation open, I’d raise that exact distinction there and include the timestamped agreement/payment-method setup details privately, alongside testing instructions for both billing paths. That gives the reviewer the specifics needed to assess your usage-based model rather than a subscription example.

Let me know if I can clarify anything further here as always!

5

Hi Alan, thanks for the detailed reply, that was helpful, and the point about the linked threads being subscription scenarios rather than a published test is a useful clarification.

We’re preparing to resubmit after our suspension lifts, and we’ve built split billing in the meantime. Merchants who install from the App Store are billed entirely through the Billing API, as usage charges on a zero dollar subscription with a merchant approved cap, and that covers all fees including ones from other sales channels. That’s what we’ll be submitting.

Separately, I wanted to ask about the approval option for billing outside the Billing API. We ticked that box on an earlier submission after a reviewer suggested it, but we didn’t have an approval on file, and that was part of what led to the suspension. I’ve never been clear on how a developer actually requests that approval in the first place. Is there a formal process, and if so what does it involve and who decides?

For context on why I’m asking, Creative Scale is a multi channel platform. Brands sign up with us directly and run creator campaigns across Amazon, Meta and TikTok, and Shopify is one integration among several rather than the entry point. My understanding is that some platforms with that shape have external billing noted on their listing, so I wanted to find out whether that route is open to us or whether it’s limited to specific cases.

I also couldn’t find a way to raise any of this with the review team directly. While the app is suspended our Distribution page only shows the listing and App Store visibility, with no requirement tracker or notes section, so I’m not sure whether questions like this should go in the submission notes when we resubmit or somewhere else.

To be clear, we’re not asking you to weigh in on whether we’d qualify, and we’re proceeding with the Billing API implementation regardless. I mainly want to know the process so we’re asking the right team in the right way.