What is Shopify app billing?
Billing methods for Shopify apps can be broadly divided into two types: payments within Shopify and payments outside Shopify.
When payment is made within Shopify, merchants pay Shopify for the Shopify app fee, and Shopify pays the app vendor the amount after taxes and fees are deducted.
The biggest advantage of payment within Shopify is that merchants do not need to enter credit card information or similar details when paying, which lowers the barrier to billing.
The disadvantage is that you need to pay fees to Shopify. However, at present, unless you build an app that earns a very large amount, it is not something to worry about too much, so I think it is better to process payments within Shopify.
When payment is made outside Shopify, the app vendor needs to prepare its own payment flow. I will not cover that this time. Everything below explains billing within Shopify.
Shopify app billing flow
Shopify provides all the tools needed to charge for Shopify apps. Therefore, Shopify apps can charge easily by simply implementing the predefined pattern.
Shopify app billing roughly follows the flow below.
- [App] The user clicks the billing button placed in the Shopify app screen
- [Server] Send a request to the Shopify GraphQL API based on the billing type (types are described later), billing amount, plan name, and so on
- [Server] Receive data from the API that includes the URL for charging the user, and pass it to the app
- [App] Redirect to the billing URL
If the user chooses to pay on the billing page displayed in step 4, billing is performed. (Of course, the user may choose to cancel and leave.)
Billing types
There are several billing methods on Shopify.
The first is a flat-rate plan (fixed-amount plan). For flat-rate billing, you can choose either monthly or annual payment.
The second is a usage-based plan, commonly called pay-as-you-go billing. The app can decide what usage to base charges on and how much to charge. (For an app that sends emails, this could be the number of emails delivered; for an app related to product sales, this could be the value of products sold, and so on.)
The third is a plan that combines 1 and 2. Annual payment for the flat-rate portion cannot be selected here, so only the combination of monthly payment + pay-as-you-go billing is available.
The last one is a one-time purchase. Once a merchant purchases it, they can use it indefinitely, but perhaps from a profitability perspective, it does not seem to be adopted very often.
- Flat-rate plan (fixed amount)
- Monthly payment
- Annual payment
- Usage-based plan (pay-as-you-go billing)
- Monthly payment + pay-as-you-go billing (annual payment + pay-as-you-go billing is not possible)
* Although it is not a subscription, a one-time purchase is also possible.
Please also refer to the official Shopify reference.
Designing a subscription model
I think many apps will adopt a flat-rate or usage-based subscription model. In a subscription model, I think the questions we worry about are “What price is appropriate?” and “What kind of plan design will encourage upgrades?”
I do not think there is a single correct answer for designing a subscription model, but there are two important constraints to consider. The first is that each merchant can have only one subscription. Regardless of the billing type described above, a merchant can have only one subscription. For example, if a merchant who already has subscription A signs up for subscription B, subscription A is automatically canceled and subscription B is contracted.
Please note that the “plan that combines flat-rate billing and pay-as-you-go billing” described under billing types is not a contract for both a flat-rate plan and a pay-as-you-go plan. It is a contract for one plan that combines flat-rate billing and pay-as-you-go billing.
The second is that “the contents of the subscription at the time of billing cannot be changed later.” (* The capped amount required for pay-as-you-go billing can be changed.) This may have felt a little surprising only because I had imagined something like subscription master data.
Looking at this from the other side, it means the app can present whatever plan contents it wants at any time to merchants who sign up for a new subscription. If you see this as an advantage, flexible subscription design such as limited-time sales becomes possible.
Webhooks related to billing
There are several billing-related webhooks, and by handling each of them properly, you can make the billing process run smoothly.
This is a webhook related to flat-rate plans and usage-based plans. It is received when a subscription is contracted or canceled. By checking the status, you can also determine whether the user left the payment screen.
By the way, the order in which webhooks are received is not guaranteed, so please note that the webhook for canceling the old subscription and the webhook for contracting the new subscription may not always arrive in that order.
app_subscriptions/approaching_capped_amount
This is received when the usage-based billing capped amount is being approached. Let the merchant know that they are approaching the usage-based billing cap and encourage them to update the capped amount.
This is a webhook related to one-time purchase plans. Like subscriptions, it includes status and other information.
Summary
This time, I introduced how to charge for Shopify apps and how to design subscriptions. Shopify app billing has a predefined pattern, so I hope this showed that it can be implemented easily. Subscription design is also very difficult, but I think being particular about this will also lead to refining the app's features, so let's work on it without compromise!
I plan to add information about “refunds for Shopify apps” in the future because it is related to billing. Please look forward to it!