Wix business solutions run prebuilt flows for things like calculating tax, quoting shipping, and validating a checkout. A service plugin is a backend extension that lets you inject your own code into one of those flows at a specific decision point.
For example, an app can implement the Additional Fees service plugin to add a packaging fee to every cart. When a customer checks out on a Wix site that has the app installed, Wix asks the app for any additional fees and shows the response in the order summary.
Common use cases include custom shipping providers, payment providers, tax calculators, and checkout validators.
Service plugins invert the usual call pattern. Your code doesn't initiate the call. Wix initiates it during one of its own flows. The request describes the current state, like the cart or the checkout. Your response feeds back into the rest of the flow.
You implement the interface methods that the platform calls. Each interface defines its own request and response contract, and your response must match the contract exactly for Wix to use it. For how Wix handles timeouts and errors during a plugin call, see Custom Business Logic.
Wix exposes a range of service plugin interfaces across its business solutions, covering things like checkout validations, shipping rates, payment processing, tax calculation, and form submissions. The available set depends on the development path.
A service plugin runs with no caller identity. Wix invokes it on its own during a host flow, so there's no Wix user, member, or visitor identity attached, and the SDK's default auth in this context is null. To call Wix APIs from the plugin, you must use elevation.
What elevated calls can do is bounded:
The inbound request from Wix is signed so the plugin can verify it actually came from Wix. The Wix CLI handles this verification automatically. Self-managed implementations verify it explicitly.
The development path determines how you implement a service plugin:
Last updated: 2 August 2026