EML Transaction Simulator API

Transaction Scenarios

Normal Behaviour

Transaction processing – a summary of Dual Message transactions:

Transactions typically come in two parts, “auth” and “clearing” – this is common for all payment networks aside from eftpos. In transaction processing, this actually creates three transactions on the processor: auth, reversal of the auth, and clearing. This method allows for confirmation of what actually settles against the original auth, and therefore allows for uneven clearing which has some appropriate use cases. An example of normal clearing is:

  1. Transaction at point of sale, at time of transaction (T+0) is received in real time as an auth request. The purpose of this is to confirm to the merchant that funds are available on the card and will be safeguarded for that amount – if approved, purchase is complete at the merchant and the card is debited for the transaction amount as an “Authorisation” or “Pending Auth” by the Issuer (EML), awaiting settlement.
  2. When the transaction is completed by the merchant, the scheme (Mastercard) arrange settlement from EML to Merchant/Acquirer, and process this as a clearing transaction. The vast majority of transactions clear on T+1 or T+2 depending on the time of day of the auth, although depending on the merchant and nature of the purchase/transaction it can be anywhere up to T+180 before the scheme void the transaction auth (can no longer settle). Mastercard send a daily clearing file to EML, and EML process this file over a number of hours during the day – these are not real time transactions. Upon clearing, EML reverses the auth transaction amount as a “Clearing Credit Back”, momentarily leaving the transaction amount reversed.
  3. At the same time as the Clearing Credit back, EML posts a transaction to the card for the actual amount that settled as a “POS Clearing” transaction.

This describes normal behaviour, with steps 2 and 3 happening at the same time. For clients using ControlPay, step 1 is within the delegated authorisations processing (real time), steps 1, 2 and 3 are notified via webhooks once they have been processed. Notifications will also be received for Just In Time Transactions (1720) which are required to transfer funds from the disbursement or benefit account in which the transaction is being funded and will occur any time there is a credit or debit to the account (even clearing doesn't require JITs to occur as the clearing credit back funds the clearing transaction)

Transaction Types, Descriptions and their accompanying codes can be found in the Transaction Codes section.

Even Clearing

Over 99% of transactions clear for the same amount as the original auth message and do so within 1-2 business days. This is because usually there is certainty of the amount (e.g. the clothes I bought today have a known value), and the merchant wants to receive the funds as soon as possible. For example:

  1. POS Authorisation Purchase (1118 transaction code) on T+0 for $100 - card debited for this amount
  2. Clearing Credit Back (1117) on T+2 - card credited for $100 amount as a Clearing Credit back
  3. POS Clearing (1115) on T+2 - card debited for $100 as POS Clearing. Net effect is card debited for $100 as it was on T+0 (clearing evenly against the auth)

Exceptions and Edge Case behaviour

Uneven clearing – lesser amount

In some scenarios, a merchant with perform an auth and then clear for a lesser amount – this is most common for hotels (taking a deposit at check-in for room expenses), car hire (security deposit for damages or other expenses) and vending machines (auth for the most expensive item in the machine to allow customer choice of any item). Due to the nature of the transaction, clearing may happen more than 1-2 days later (when the car hire is returned for example). To use the hotel example:

  1. POS Authorisation Purchase (1118) on T+0 for $100 - card debited for this amount
  2. Clearing Credit Back (1117) on T+5 - card credited for $100 amount as a Clearing Credit back
  3. POS Clearing (1115) on T+5 - card debited for $40 as POS Clearing. Net effect is card debited for $40 as that’s the amount of expenses actually incurred

Uneven clearing – greater amount

In an extremely small set of cases, the clearing amount may exceed the auth amount. This is not expected behaviour although if it does occur, in the event of a successfully disputed transaction there is a liability shift towards the merchant. Again, using the hotel example, where the room expenses have actually exceeded the auth:

  1. POS Authorisation Purchase (1118) on T+0 for $100 - card debited for this amount
  2. Clearing Credit Back (1117) on T+5 - card credited for $100 amount as a Clearing Credit back
  3. POS Clearing (1115) on T+5 - card debited for $270 as POS Clearing. Net effect is card debited for $270 as that’s the amount of expenses actually incurred

Authorisation Reversals

A reversal is the unwinding of a transaction, normally due to technical issues such as a transaction timing out at POS, or the merchant declining a transaction that the issuer has approved.

  1. POS Authorisation Purchase (1118) on T+0 for $100 - card debited for this amount
  2. POS Authorisation Purchase Reversal (1120) on T+0 (normally within seconds) - card credited for $100 amount as an auth reversal. Net effect is no cost to the card

Refunds

A refund occurs when a customer returns goods to a merchant or the transaction is refunded for any other reason as agreed between the merchant and cardholder. This may be for the full amount or a partial amount. It is important to note that a refund transaction makes no reference or link to the original transaction – we expect that there is a transaction in the transaction history on the card (and at that merchant) but the POS terminal does not pass through the original transaction ID. Refunds are received and processed in one of two ways:

  • An on-line auth message to EML. The transaction will show on the card as a POS Credit Authorisation (1168), then reversed and cleared when the clearing transaction comes in as a POS Credit (1116).
  • An offline refund where the merchant processes at POS, but the acquirer and Mastercard do not pass a transaction in real-time to EML. EML receive a clearing file on T1-T2 and process as a “forced post” POS Credit (1116), crediting to the card.

Expired Auths

In the even that an auth transaction is processed but a clearing transaction is not received within a specified time, it is common for the Issuer to reverse the auth so that funds are no longer locked and become accessible for the customer to use. This is done on an assumption that after a period of time, it is likely that a clearing transaction will never be received. The timing of an Auth reversal differs between Issuers – EML expire/reverse an auth after 9 days. An expired auth is simply the crediting back of the originally authorised amount:

  1. POS Authorisation Purchase (1118) on T+0 for $100 - card debited for this amount
  2. The auth is expired by EML on T+9 - card credited for $100 amount as an Expired Auth (1118) / Auth Cancelled. Net effect is no cost to the card

It should be noted that the merchant has up to 180 days to clear a transaction (albeit extremely rare since merchants tend to clear as soon as possible) so there is risk that an expired auth will then be presented either clearing transaction as follows:

  1. POS Authorisation Purchase (1118) on T+0 for $100 - card debited for this amount
  2. The auth is expired by EML on T+9 - card credited for $100 amount as an Expired Auth (1118)/ Auth reversal.
  3. POS Clearing (1115) on T+65 - card debited for $100 as a "Forced Post" POS Clearing. Since there is no un-reversed auth, only the clearing amount is posted, with a net effect of card debited for $100 as the cleared cost of the transaction

Multiple Clearing

In very rare cases, a merchant may process an auth and then process clearing in components. For example, I buy multiple items from Apple (a laptop, an iPhone and an iPad), they process the transaction as one amount, but settle only when the individual items are shipped. Because EML as the issuer have no visibility over shipping, this is initially processed as per an uneven clearing transaction, followed by additional clearing events processed as “forced post”:

  1. POS Authorisation Purchase (1118) on T+0 for $3000 - card debited for this amount
  2. Clearing Credit Back (1117) on T+1 - card credited for $3000 amount as a Clearing Credit Back
  3. POS Clearing (1115) on T+1 - card debited for $800 as POS Clearing. iPhone item has shipped, card has been debited for the cost of that item.
  4. POS Clearing (1115) on T+5 - card debited for $600 as POS Clearing / Forced Post. iPad has shipped. Since there is no un-reversed auth, only the clearing amount is posted, with card debited for another $600
  5. POS Clearing (1115) on T+8 - card debited for $1600 as POS Clearing / Forced Post. Laptop has shipped. Since there is no un-reversed auth, only the clearing amount is posted, with card debited for another $1600. Net cost to card is a total of $3000

Auth Advice / Auth Adjustment:

In rare cases, a merchant may process an auth transaction and then adjust it. In practice most merchants would reverse the auth and start the transaction all over again (EML receive the reversal and notify via webhooks where enabled), but in some cases they present another transaction with the same Auth ID, for a different amount. For an auth adjustment EML process this by creating an artificial reversal and creating a new auth:

  1. POS Authorisation Purchase (1118) on T+0 for $100 - card debited for this amount
  2. POS Authorisation Purchase (1118) on T+0 (or later, any time before clearing) for $120 using same Auth ID. EML reverse initial auth (card credited for $100), create a new one (sent to client if using ControlPay) advice adjustments don’t go through delegation– card debited for $120
  3. Clearing Credit Back (1117) on T+2 - card credited for $120 amount as a Clearing Credit Back
  4. POS Clearing (1115) on T+2 - card debited for $120 as POS Clearing. Net effect is card debited for $120 as it was on T+0 for the adjusted auth (assume it will clear evenly since the auth was adjusted to be correct)