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

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.
• 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.
2. Create the refund — Call Create a 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 covers simulating refund responses — successes, declines, and edge cases — in the sandbox before you process a live refund.

API reference

Full request and response schemas, including error responses, are in the API Explorer.