HomeSolutionsCheckout Extension Payments API

Checkout Extension Payments API

Checkout Extension Payments API

A checkout extension payments API for teams building installable extensions that need safe collection actions, hosted fallback, and order-backed payment context.

Teams searching checkout extension payment APIs usually need a way to plug into buyer collection flows without losing the order state, hosted fallback options, and post-payment meaning behind the checkout.

Flint gives checkout extensions a stronger backend model because hosted checkout, embedded flows, payment links, and refunds all stay on one order-backed platform.

Extensions can install through the public partner-app model and then operate against concrete checkout and order objects rather than approximating the sale from frontend events alone.

The same platform can support in-checkout behavior and later hosted recovery or support actions without switching systems.

Use This Platform Shape When

Platform 1

Your extension needs to influence buyer collection flows while still depending on a durable order and payment model underneath.

Platform 2

The checkout extension may need hosted fallback, remote collection, or post-purchase recovery without leaving the same platform.

Platform 3

You want installable extension auth plus checkout-state visibility to live on one public API family.

Scenario 1

Hosted checkout extension logic

Build extension behavior around checkout sessions that already belong to one specific order instead of trying to infer the sale from frontend signals alone.

Scenario 2

Embedded checkout plus extension hooks

Keep the buyer on the merchant frontend while the extension still relies on Flint's backend order and payment model for the hard parts.

Scenario 3

Fallback after checkout drop-off

Hand an abandoned or interrupted buyer into payment links or other hosted recovery paths without changing the underlying workflow model.

Scenario 4

Install, observe, act

Use partner-app install plus app-owned webhooks so the extension can react to the checkout and payment lifecycle cleanly after merchant approval.

Choose Something Narrower When

Use the payment-links-vs-hosted-checkout comparison when the main question is only which hosted surface to show buyers.
Use embedded-payments pages when the concern is custom frontend checkout implementation rather than installable extension behavior.
Use the broader ecommerce-plugin page when the plugin spans much more than checkout-specific actions.

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.