The Refund vulnerability of AS2805 and EFTPOS

Transactions are normally validated, matched then processed. This is very common to ensure that requests sent to a payments switch are associated with its responses before delivering responses to a terminal. Now for all transaction types this process in true, except for refunds. Well, at least it’s not matched for most financial institutions in Australia.

Below is a few descriptions of transactions that might be processed through a typical switch in Australia:

---

 

Authorization / Cash Out

The Authorization transaction is typically used by a merchant to obtain the authorization of a transaction amount as a pre-approval for the purchase of goods or services later during the fulfillment process. Authorization transactions are typically submitted for authorization and then funds are held by the issuer until that transaction is captured or the authorization is reversed or expires. An example can be found with online retailers who initiate an Authorization transaction to guaranteed funding by the card issuer prior to the shipment/delivery (i.e. fulfillment) of the goods. An “Authorization” is also referred to as an Auth-Only transaction.

Sale / Purchase

A “Sale” transaction is used by merchants for the immediate purchase of goods or services. This transaction completes both the authorization and capture in a single transaction request. The Sale transaction is an Authorization and Capture transaction that if approved is automatically included for settlement.

---

 

Forced Sale

A “Forced Sale” is a transaction initiated by a merchant with the intent of forcing the posting of the transaction against the customer account without receiving prior authorization by the card issuer, or receiving a voice authorization code from the merchant acquiring call center. An example would be when a merchant’s terminal is offline, requiring the purchase of goods being completed without receiving online authorization by the card issuer. Or they received a Voice Approval. In these cases the merchant would enter the transaction details and forward this Forced Sale transaction to the card issuer with the expectation of receiving funding for the goods or services rendered. A forced sale does not require a matching authorization. Forced Sales are also known as Off-Line Sales.

Refund

A Refund allows a merchant to refund a previously settled transaction and submit the refund for processing. Refunds are only allowed for financial transactions (Sale and Captured) and are typically limited to the original authorization amount, or a lesser amount, in some cases, multiple partial refunds up to the original transaction amount. Some systems incorporate a feature called Matched Refunds. Matched Refunds must match back to an original transaction to help control fraud. “ Refunds” are also sometimes referred to as a “Credit” transaction.

Void

Void transactions can reverse transactions that have been previously authorized or approved by the card issuer and are pending settlement. Merchants will only be allowed to void transactions that are in an open batch (pending settlement). Sale or Refund transactions are the most commonly voided transaction types.

Capture

The Capture transaction will allow merchants to capture a previously authorized transaction that is pending settlement, and submit it for clearing and settlement. An example is when online retailers who initiate an Authorization transaction to reserve funds by the card issuer prior to the shipment/delivery (i.e. fulfillment) of the goods, and then once fulfillment has been completed the transaction will be captured and submitted for settlement. A “Capture” is also referred to as a Pre-Authorization Completion transaction.

---

 

Now According to the AS2805 Specifications,   The refund is not matched to the transaction during the refund authorization, and will approve by default, you need to match the Refund to an Authorization or Sale when doing settlement.

This appears not implemented in Australia for some reason, and some financial institutions will actually admit it.

I have tried this on a EFTPOS machine, you should try this as well. Simply do a refund on a EFTPOS terminal without doing a transaction. All you would need is a 4 digit password to access the refund function (in some cases  refunds are not password protected) , these default passwords are published by the terminal manufacturers.

In every case that I’ve tried this, the refund is processed and the funds appeared in my account. This is surely a massive risk for fraud!!!!

Strange enough, the banks are not worried about this as the funds are tied to the merchant account, and it’s not a risk for the bank but for the Merchant. These are some clause in the contracts that absolve them from the risk.

So if you have a EFTPOS terminal, ask for the refund function to be disabled or you could be out of pocket!