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 authorization request, authentication/authorization 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.

Authorizations

There are typically two stages to an authorization process:

• Pre-authentication/authorization
• Post-authentication/authorization

To provide you with the most accurate fraud scores, Fraudio requires both pre- and post-authorization stages. While the authorization request specifies which authentication and authorization 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 / authorization information as demonstrated in the example.

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

Example 2: Authentication / authorization response

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

Please see example 2 below to better understand how authentication and authorization 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 authorization response can be sent to the post-authorization 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 authorization 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 authorization 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.