Transaction Model and Lifecycle

Introduction

This document attempts to explain and demystify some of the complexities present when processing transactions. This is a companion document to the Webhook Message Reference. It should help you to interpret Transaction Messages which you receive at your webhook.

Workflows

There are two different models for transaction lifecycle which are employed.

1. Payment network transactions
   • Identified by "lifecycle": "payment_network" in transaction messages.
   • This describes cardholder transactions originating from Visa, Mastercard or EFTPOS. It includes ATM, POS and Online/E-commerce transactions. Most cardholder activity will use this workflow.
2. Simple transactions
   • Identified by "lifecycle": "simple" in transaction messages.
   • Transactions generated internally by EML, and other simple transactions.

These lifecycles are explored in more detail below.

Payment Network Transactions

State names in webhook messages

new, requested, authorized, cleared, declined, cancelled, reversed

The new state

Although it is not labelled on this diagram, there is a new state, which may be listed as the value of old_state within the state_change of a brand new transaction.

For payment network transactions, you will only observe this in conjunction with a Forced Post. For an authorization, the old_state of the first message will always be requested.

To help you navigate this, the is_new property of state_change will be true if old_state is either new, requested, or posted (for simple transactions).

Simple Transactions

State names in webhook messages

new, posted, reversed, declined