Message scenarios

Below are simple transactions that use FAST messages.

🗒️
For a description of the data element (DE) fields in ISO-based messages, we recommend that you refer to the specification relevant to your card scheme.

Authorizations

A normal transaction may be approved or declined depending on the DE39 response from the client or the processor. Note that a declined status by any entity may not be overridden to an approved status by the other entity.

Most of the time, clients approve transactions. When a transaction is declined by the processor (Paymentology), the initial approved message from the client is overridden by Paymentology and a declined (05) response is sent to the client. In that scenario, an advisement is sent back to the client stating that the response code was overridden by the Paymentology system (as the transaction could have been declined on a different reason ground from Paymentology at first-hand).

Transaction Status	Processor DE39	Bank DE39	DE39 to Scheme
Approved	`00`	`00`	`00`
Declined (Processor)	`05`	`05`	`05`
Declined (Client)	`00`	`05`	`05`
Declined (Processor)	`05`	`00`	`05`

Authorization followed by a reversal

In this case, the transaction is approved both by the issuer processor and the client; however, following the approval, a reversal is received from the acquirer or the scheme.

Flow: Authorization followed by reversal

Authorization followed by an advisement

In this case, the transaction is approved (DE_39=00) by both the client and the issuer. However, once the authorization is sent to the Network, the Issuing processor receives a decline advice from the network.

Flow: Authorization followed by advisement

**Processor will reply to scheme with 0130 irrespective

Exceptional sequencing scenarios

When a reversal or advisement follows authorizations due to customer cancellation, it is considered an exceptional scenario.

Late reply from client

*If no reply in timeout period 0120 repeated every 10mins (configurable)

Acquirer fail – scheme issue reversal

Processor fails to respond to the scheme

Flow: Processor fails to respond to scheme

Processor timeout (0110 sent, but sent late)

Processor X110 format error

FAST interface timeout scenarios

In the instance where no response is received within the configurable response time (between 500ms and 60,000ms), the FAST interface will perform several retries by resending the message to the client at regular time intervals. The number of retries is three (3) by default but is configurable.

Below is a visual representation:

Transaction type examples

FAST message request and response examples for Authorizations are available for the respective scheme/networks through these links:

Mapping of Record ID and Transaction ID

Each transaction is assigned a transaction ID (TID) which represents the whole transaction, from the authorization stage to presentment and chargebacks.
The record ID (RID) is a unique identifier allocated to each message, and it represents one message type of the transaction, e.g. 0100 (authorisation), 0120 (advice), 0420 (reversal/reversal retry). Each message type will have its own unique RID, but all the message types will share the same TID.

These are explained further in TID and RID.

FAST message structure for Clearing Data

The clearing data can be sent in bulk at a single time. To preserve the standard structure and easy data parsing, the Settlement Objects are wrapped inside the array.