Skip to main content
Checkout handles the buyer flow. Refunds handle money moving back after a payment has completed.

​
Create a refund

Create refunds from your backend or support tooling. Send an idempotency key so duplicate button clicks or retries do not create duplicate refunds. On Node, npm install @ionicfi/sdk gives you typed calls for every request below; the server SDK guide has details. Each example also shows raw curl.
Use a partial amount when refunding less than the original payment. Omit amount for a full refund when supported by the payment state.

​
List refunds

Use refund listing to review refund history or build a dashboard.

​
Retrieve a refund

​
Best practices

  • Store your own order ID in checkout session metadata.
  • Keep the mapping from a refund to its support ticket or return authorization in your own system, keyed by the refund id; refunds carry a reason but no free-form metadata.
  • Treat refund creation as a money-moving operation and always retry with the same Idempotency-Key.
  • Check the refund’s API status before telling a buyer it is complete.

​
Manual capture

By default, payments capture automatically on confirmation. Create the payment intent with capture_method: "manual" to authorize first and move the money later — useful when you ship before you charge, or need a final review step. A confirmed manual-capture intent sits in requires_capture. Capture it to move it to succeeded:
Capture takes no body and captures the full authorized amount. Authorizations don’t hold forever — card networks expire them after a period set by the issuer, so capture promptly once you’re ready.

​
Cancel an uncaptured payment

An intent that hasn’t been captured can be canceled instead, releasing the buyer’s authorization hold:
The body is optional — an absent body cancels with no reason. Canceling is simpler for the buyer than capture-then-refund: the hold drops off their statement instead of a charge appearing and reversing. Before capture, cancel an intent. After capture, refund it.