Transaction types

To detect fraudulent transactions and merchants with greater precision, Fraudio requires a diverse range of transaction types. In addition to regular payment data, we also benefit from receiving:

• Bank transfers
• Wallet transfers
• Withdrawals
• Payouts
• Other relevant deposits

This allows us to analyse a merchant's behaviour more thoroughly and accurately, enhancing our ability to identify potential fraudulent activity and providing our clients with more effective fraud detection and prevention measures.

Payment data

In payment transactions, there are typically a series of related events that occur in sequence. These events can include an authorisation request, authentication/authorisation response, capture, and refund.

To ensure accurate tracking and analysis of payment data, it's essential that we receive all of these transaction events as separate entries.

Authorisations

There are typically two stages to an authorisation process:

• Pre-authentication/authorisation
• Post-authentication/authorisation

To provide you with the most accurate fraud scores, Fraudio requires both pre- and post-authorisation stages. While the authorisation request specifies which authentication and authorisation checks will be used, the results of these checks are not known until they are completed.

Example 1: Transaction

Please find below an example (1) of an auth transaction data type, which contains only pre-authentication / authorisation information as demonstrated in the example.

{
"transactionid" : "4583409307",
"transactiontype" : "auth",
"cvvused": true,
"threedsused": true,
#rest of the fields
}

Example 2: Authentication / authorisation response

After processing the authorisation request, an authentication/authorisation response should follow. For both batch and live data, we ask that you aggregate the authentication and authorisation response into one transaction event for both batch and live data. This response should have the same transaction ID as the original authorisation request.

Please see example 2 below to better understand how authentication and authorisation events have been aggregated into a single transaction event.

{
  "transactionid": "4583409307",
  "avsresult": "A",
  "cvvresult": "S",
  "eci": "02",
  "responsecode": "05",
  "success": "true",
  "timestamp": 1646063615,
  "authresult": "success",
  "cavvresult": "5",
  "ddresult": "ZXC* Site Access 800-123-4567",
  "gatewaydeclinereason": "Card Disabled",
  "ucafindicator": "2"
}

info

For live transactions, the authorisation response can be sent to the post-authorisation backfill endpoint.

Captures, reversals, refunds, voids and top ups

To ensure accurate record-keeping, it is important to link transaction events such as captures, reversals, refunds, voids, and top-ups to the original authorisation request using the parenttransactionid. To do this, you should use the transactionid of the corresponding transaction of type auth or auth_capture as the parenttransactionid.

In addition, the specific transaction type should be specified in the transactiontype field.

Example 3: auth

To illustrate this, an example JSON payload of an auth transaction is provided below.

{
"transactionid" : "4583409307",
"transactiontype" : "auth",
"parenttransactionid" : "none",
#rest of the fields
}

Example 4: capture

The JSON payload example (4) provided below shows a transaction of type capture, which is a follow-up to the above-mentioned authorisation request.

{
"transactionid" : "5752161401",
"transactiontype" : "capture",
"parenttransactionid" : "4583409307",
#rest of the fields
}

Inter-Account Transfers

info

This section is relevant if you handle transactions involving funds moving between merchants' bank or wallet accounts.

You can send historical transfers as a separate table, while live transfers can be submitted via the inter-account transfers endpoint. Keep in mind that inter-account transfers always occur from the merchant's perspective.

Example 5: Inter-Account Transfers

Below, you'll find a minimal JSON payload example (5) illustrating an inter-account transfer.

{
"transactionid" : "5752161401",
"transactiontype" : "outgoing_wallet_transfer",
#rest of the fields
}

Example 6: sistertransactionid

In instances where transfers occur between two known entities, such as a merchant sending funds to another recognized merchant, the transfer can be mirrored using the sistertransactionid field. Below, there is a JSON payload example (6) of a mirrored inter-account transfer, which is linked to the previous transfer via the sistertransactionid field.

{
"transactionid" : "18394736",
"transactiontype" : "outgoing_wallet_transfer",
"sistertransactionid": "5752161401"
#rest of the fields
}

Fraud Notifications

To ensure the accuracy of our scores and enhance our AI's learning capabilities, please consistently provide updates on any chargebacks or fraud reports you experience.

Chargebacks

• A chargeback occurs when a cardholder who has been a victim of fraud requests a refund from the merchant's bank.

Fraud reports

• A fraud report is filed when a transaction is suspected to be fraudulent, even if it hasn't been charged back.

Sharing this information is crucial for optimizing our product's fraud detection capabilities.

Other Transaction Types

We also process other transaction types, such as payouts and withdrawals. For more information on these and the previously discussed transaction types, including data types, descriptions, and example values, please refer to our API endpoints section to familiarize yourself with Fraudio's schemas.