--- title: 'Monetization, IAP, and Support Obligations | Shopware Community Hub' description: >- Understand monetization models, in-app purchases, external fee considerations, Technology Partner relevance, and support responsibilities. canonical_url: >- https://hub.shopware.comhttps://hub.shopware.com/learn/unit/monetization-iap-and-support-obligations --- # Monetization, IAP, and Support Obligations - Assess suitable monetization models for an extension. - Plan in-app purchases in a structured and transparent way. - Consider possible Technology Partner requirements early. - Set up support processes as part of a professional extension offering. - Understand quality, support, and monetization as connected product responsibilities. # Monetization, IAP, and Support Obligations Monetization is not only a pricing decision. It shapes how merchants evaluate the extension, what they expect after purchase, and which responsibilities the partner must be ready to handle. An extension can be free, paid, subscription-based, connected to in-app purchases, or tied to external service fees. Each model affects the product promise, the Store listing, support expectations, and sometimes additional agreement requirements. In this unit, you will learn how to think about monetization, in-app purchases, external fee models, and support as connected parts of a professional extension offering. ## Monetization Should Match the Product Promise Extensions can be monetized through different models in the Shopware Store, depending on the product and the value it provides. Common models include: - paid extensions - subscription-based extensions - in-app purchases - commission-based or transaction-based integrations - free extensions with paid premium features The right model depends on the value, target audience, support effort, and ongoing maintenance needs of the extension. The important mental model is this: > Monetization should match what the extension delivers and what the partner can support over time. A complex integration with ongoing service costs may need a different model than a small utility extension. A free extension with premium add-ons needs clear boundaries between included and paid functionality. ## In-App Purchases Add Flexibility In-app purchases allow partners to lock specific features behind additional purchases within the same extension. They make it possible to combine a free version with limited functionality and paid tiers that unlock additional capabilities. This option is available for Shopware 6.6.9.0 and later. To use In-app purchases, partners must create at least one subscription group. Each group can contain one or more tiers that represent the available purchase options. Partners should plan: - which features are included by default - which features require an in-app purchase - whether tiers are needed - whether pricing is monthly, annual, or both - how the merchant sees what is included - how the extension behaves when a purchase is active or inactive The purchase flow itself is provided by Shopware. The extension triggers the purchase process and then needs to verify and react to the purchase state correctly. ## IAP Requires Clear Product Boundaries In-app purchases can be useful, but they can also confuse merchants if the boundaries are unclear. A merchant should understand: - what they get with the base extension - which features are locked - what changes after purchase - whether the purchase is tied to a subscription tier - how pricing is shown - what happens if a subscription is changed or cancelled This should be reflected in the extension UI, Store listing, and support communication. If the extension advertises a feature, but that feature requires an additional purchase, the listing and in-extension messaging should make that clear. The goal is not only technical correctness. The goal is commercial transparency. ## External Fees and Technology Partner Relevance Some extensions connect to services that charge merchants outside the Store purchase itself. Examples can include transaction-based fees, service fees, or downstream costs from an external platform. The Extension Partner Account documentation explains that a Technology Partner agreement may be required when an extension is a software interface with downstream costs, transaction fees, or service fees for the customer. Partners should identify this early. It affects both the commercial model and the approval path. Before publication, ask: - Does the extension connect to an external paid service? - Does the merchant need a separate contract? - Are transaction fees involved? - Are service fees charged outside the Store? - Does the extension generate commission-based revenue? - Does this require a Technology Partner agreement? If these questions are answered too late, the launch can be delayed even if the code is ready. ## Support Is Part of the Commercial Offer Monetized extensions create expectations. If a merchant pays for an extension or a premium feature, they expect the partner to support it professionally. Support remains part of the overall product offering. Extension-related tickets are managed in the Extension Partner area, where partners can review the ticket history, customer details, Shopware version, affected extension and version, and current support status. Support is therefore not separate from monetization. It is part of the offer. Partners should plan: - who monitors support tickets - which email receives support notifications - how quickly support requests are answered - how bugs are prioritized - who handles support during holidays or absence - how paid or premium features affect support scope - how technical information is collected for investigation The support documentation also describes response expectations and visible signals such as fast response labels. This means support quality can influence merchant trust and partner reputation. ## Quality, Support, and Monetization Belong Together A monetization model only works when the extension quality and support model can sustain it. For example: - A subscription-based extension needs ongoing maintenance and predictable updates. - An in-app purchase needs clear feature boundaries and reliable purchase-state handling. - A transaction-based integration needs transparent external fee communication. - A free extension with premium upgrades still needs support expectations. This is why partners should not design pricing in isolation. Pricing, Store listing, support process, technical architecture, and lifecycle planning should all tell the same story. ## Example: Free Extension With Premium Automation Imagine a partner offers a free extension that provides basic order export functionality. The partner wants to add premium automation through in-app purchases: - basic manual export is included - scheduled export is part of a paid tier - advanced filtering is part of a higher tier - purchase is triggered inside the administration - active purchases are verified securely For this to work well, the partner needs more than the technical IAP integration. They also need to explain the difference between free and premium functionality, handle support questions about locked features, verify purchase state reliably, and update the Store listing so merchants understand the model before installation. The monetization model becomes part of the product experience. ## Common Pitfalls ### Choosing a Monetization Model Too Late Pricing and feature boundaries affect architecture, Store listing content, support expectations, and approval requirements. ### Hiding Paid Feature Boundaries Merchants should not discover only after installation that an advertised feature requires an additional purchase. ### Treating IAP as Only a Button In-app purchases also require purchase-state handling, feature gating, clear tiers, and support communication. ### Missing Technology Partner Relevance External fees, transaction fees, or downstream service costs may require additional agreements. Check this early. ### Underestimating Support Effort Paid extensions and premium features create stronger expectations for reliable support and maintenance. ## Summary - Monetization should match the extension's value, target audience, and long-term support model. - In-app purchases can support premium features, tiers, and subscriptions, but require clear product boundaries. - External fees, transaction-based revenue, or service costs can create Technology Partner relevance. - Support is part of the professional extension offering, especially for paid or premium functionality. - Quality, monetization, Store listing clarity, and support responsibilities should be planned together. Next, you will see how these launch, lifecycle, and monetization topics come together in the course overview.