# Refunds API

Refund any integrated EFTPOS transaction back to the customer's original payment method, without requiring the card to be re-presented.

## What is it?

The Refunds API processes card-not-present refunds for integrated EFTPOS transactions. Every refund is a **referenced refund** — it must reference the original transaction via a `transactionReference` — so funds always return to the same card or account used for the original payment.

## Requirements

| Requirement | Description |
|  --- | --- |
| **Integration type** | Business operations (refunds) |
| **Webhooks** | None — refunds are a single synchronous request/response call |
| **Setup steps** | Standard JWT authentication — you'll also need the `transactionReference` of the original transaction, see [Finding a transaction reference](/docs/business-operations/refunds/finding-a-transaction-reference) |
| **Limitations** | Only POS-integrated, AUD-settled transactions from 28 March 2025 onward are eligible — see [Conditions and limitations below](#conditions-and-limitations) |
| **API reference** | [Jump to API reference](#api-reference) |


## Key features

* **Funds return to the original payment method**: Refunds are always credited back to the same card or account used for the original payment, not as cash or to another card.
* **Card-not-present refunds**: Customers don't need to present their card again at the terminal.
* **Partial refunds**: Supports multiple partial refunds, provided the total refunded amount doesn't exceed the original transaction amount.
* **Simpler reconciliation**: Every refund references the original transaction, giving you a complete audit trail across full and partial refunds.
* **Fraud protection**: Tying refunds to the original payment method reduces risks such as receipt fraud, stolen merchandise returns, or cross-retailer return fraud.


## Prerequisites

* You must know the `originChannel` - the sales channel where the original transaction was processed.
* You must pass the `transactionReference` generated for that transaction — how you find it depends on the channel, see [Finding a transaction reference](/docs/business-operations/refunds/finding-a-transaction-reference).
* Some POS providers don't guarantee globally unique transaction references — in that case, also include the `rrn` (Retrieval Reference Number) with the refund request to ensure accurate matching.


## Key concepts

**Transaction reference** — the identifier of the original transaction, generated by the POS system or online system. Where to find it depends on the channel the payment was made through.

**RRN** — the Retrieval Reference Number of the original transaction. Required alongside the transaction reference when the reference alone isn't guaranteed unique.

## How it works

1. **Identify the original transaction** — Find the `transactionReference` (and `rrn`, if needed) using [this guide](/docs/business-operations/refunds/finding-a-transaction-reference).
2. **Create the refund** — Call [Create a refund](/api-explorer/refunds/1.0/other/search-and-refund) with the transaction reference, origin channel, and amount to refund.
3. **Check the remaining balance** — The response includes `amountAvailableForRefund`, so you can validate a follow-up partial refund before making it.


## Conditions and limitations

* **Effective date**: Refunds are available only for transactions made on or after 28 March 2025.
* **Supported transactions**: Only POS integrated transactions are eligible. Online/eCommerce transactions are not currently supported.
* **Currency support**: Only transactions settled in AUD are supported at this time.
* **Pre-authorisations not supported**: Refunds cannot be processed against pre-authorised transactions.
* **Unsupported payment methods**: Refunds for Alipay transactions are not supported.
* **Required identifier**: You must pass the transaction reference generated by the POS at the time of sale.
* **Uniqueness considerations**: Some POS providers don't guarantee globally unique transaction references. In these cases, also include the RRN with the refund request to ensure accurate matching.


## Getting started

[Testing](/docs/business-operations/refunds/testing) covers simulating refund responses — successes, declines, and edge cases — in the sandbox before you process a live refund.

## API reference

| Endpoint | Description |
|  --- | --- |
| [`POST /refunds/search-and-refund`](/api-explorer/refunds/1.0/other/search-and-refund) | Create a refund |


Full request and response schemas, including error responses, are in the [API Explorer](/api-explorer/refunds/1.0/other/search-and-refund).