HomeSolutionsEcommerce Plugin Payments API

Ecommerce Plugin Payments API

Ecommerce Plugin Payments API

An ecommerce plugin payments API for teams building installable apps that need merchant installs, order state, hosted collection, and post-purchase workflow context.

Teams searching ecommerce plugin payment APIs usually need more than a generic payment endpoint. They need a merchant-install model, app-owned webhook flow, and order-backed commerce objects their extension can read and act on safely.

Flint already exposes partner-app registration, hosted OAuth install, environment grants, and partner-app webhooks as first-class public resources.

Plugins can operate against orders, checkout sessions, payment links, invoices, and refunds instead of being trapped on raw charge events with app-side reconstruction.

The same public API can support merchant install, app auth, and the commerce actions the plugin takes after installation.

Use This Platform Shape When

Platform 1

Your team is building an installable ecommerce extension that needs merchant approval, app-owned webhooks, and real commerce objects after install.

Platform 2

The plugin needs to interact with orders, hosted collection, refunds, or later billing without reconstructing business meaning from raw charge events.

Platform 3

You want one public platform for both the app-install model and the commerce actions the plugin takes after installation.

Scenario 1

Merchant-installed commerce app

Register the plugin, send merchants through hosted approval, and exchange install tokens before the app touches any order or billing workflow.

Scenario 2

Order-aware plugin actions

Read orders, launch hosted collection, or inspect refunds from a semantic workflow record instead of correlating frontend events and processor data manually.

Scenario 3

App-owned webhooks

Keep install lifecycle and commerce-related webhooks on the app itself instead of mixing extension events into merchant-level endpoints.

Scenario 4

Post-install monetization and support

Use one platform for merchant connect, plugin actions, and later billing or support-side commerce workflows after the initial install.

Choose Something Narrower When

Use the partner-apps page when the core evaluation is the installable-app platform itself rather than plugin payment workflows specifically.
Use checkout-extension pages when the plugin only needs to operate inside buyer checkout rather than across broader ecommerce workflows.
Use the ecommerce-platform page when the architecture decision is broader than extension or marketplace plugin behavior.

Next Step

Wire the platform boundary first

Define auth, merchant scope, and install flow first, then let the narrower payment and checkout pages sit underneath it.