HomeSolutionsReturns and Refunds Plugin API

Returns and Refunds Plugin API

Returns and Refunds Plugin API

A returns and refunds plugin API for teams building post-purchase extensions on top of order-backed refunds and hosted recovery flows.

Teams searching returns and refunds plugin APIs usually need an installable extension model plus refund workflows that stay attached to the underlying order and payment context.

Flint's refund surface stays linked to order and payment context, which is much stronger for post-purchase extensions than a refund amount with minimal business history.

Extensions can install through the partner-app model and then act on order-backed refunds, invoice follow-up, or hosted recovery paths without switching systems.

The same public API gives plugins refund operations, invoice collection, and hosted payment surfaces when a return turns into a balance change instead of a simple refund.

Use This Platform Shape When

Platform 1

The plugin needs post-purchase logic that depends on refund state, order history, and later collection or invoice paths.

Platform 2

Your team wants return and refund extensions to act on one business workflow record instead of a raw refund amount with limited context.

Platform 3

The merchant-installed app may need to combine refund actions with support, receivables, or other post-purchase recovery flows.

Scenario 1

Order-backed refund actions

Issue or inspect refunds against the same order and payment context the merchant and support team already rely on.

Scenario 2

Returns that become balance changes

Pair refund or return logic with invoice or hosted collection flows when a post-purchase change becomes more complex than a simple money-back action.

Scenario 3

Merchant-installed post-purchase app

Use partner-app install, app-owned webhooks, and refund APIs together so the extension can react to lifecycle changes after install.

Scenario 4

Safer support and finance context

Keep refund and return behavior attached to the order record instead of spreading the workflow across processor refunds and separate plugin-side ledgers.

Choose Something Narrower When

Use the refunds API page when the core technical question is Flint's direct refund model rather than plugin architecture around it.
Use the order-management plugin page when the extension owns broader post-purchase order workflows than refund-specific behavior.
Use the support-agent page when the same post-purchase workflow is more automation-driven than extension-driven.

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.