The anti-fraud integration described on this page is available only with Full balance integrations. For Zero balance integration, see Zero balance anti-fraud and validations integration.

For anti-fraud integration for banking transactions, see Client anti-fraud webhook for banking transactions.

📘

Client webhook specifications

The Client webhooks guide contains detailed specifications for ALL anti-fraud webhooks you can code to interact with Pismo platform operations.

📘

3DS/ACS validation

For card-not-present transactions, Pismo recommends, but does not require, that a third-party 3DS/ACS validator be used. Pismo provides an endpoint - Send pre-authentication info - for third-party validators to get encrypted card information they can use during the validation process.

The Pismo platform can integrate with third-party fraud prevention systems to enable additional security checks whenever customers carry out new transactions. An issuer can implement anti-fraud integration to enforce additional risk constraints. When the anti-fraud integration is enabled during setup, the Pismo platform sends all transactions that are subject to authorization to the anti-fraud system to confirm the approval or, in the case of fraud detection, to decline the transaction and to block the card.

The anti-fraud call to Full balance and Zero balance customers' webhook occurs during step 5 in the Full and zero balance workflows.

📘

Optional integration

Note that this integration is totally optional for Full balance issuers. If not present, Pismo responds to the network with its own results.

Workflow

The Pismo authorization process performs all stateless and stateful validations, assembles a request with the transaction data, and makes an HTTPS call to the webhook URL you specified during setup.

📘

Webhook request URL

To change the URL at any time, open a Service Desk request.

The response you need to send to the Pismo platform is defined in the Full balance anti-fraud integrationwebhook request specification, so that the platform can interpret and use the anti-fraud system's decision. This functionality enables you to integrate with any risk analysis provider at authorization time, making it possible to deny a purchase the platform approved.

🚧

Anti-fraud timeout - 2 seconds

If the Pismo platform does not receive a valid response from your anti-fraud system within two seconds, the request times out. In this case, the authorization proceeds with Pismo's validation, which is then considered final.

Per-program settings

The following settings can be defined on a program level. The settings below impact transactions that use a card related to a program. To activate these settings, open a Service Desk ticket with Pismo.

📘

Program anti-fraud

You can configure a different anti-fraud webhook for each program you create.

Overwrite the card network response code

When the anti-fraud system denies a purchase as indicated in the response_code field, the platform uses the provided response_code without any additional processing. When the Pismo platform denies the authorization, the following occurs:

• If the overwrite response code setting is active and your anti-fraud system does not send a response_code, the platform uses the response_code that it calculated during authorization to respond to the card network.
• If the overwrite response code setting is active and the anti-fraud system sends a response_code, the platform uses the anti-fraud system's response_code to respond to the card network.
• If the overwrite response code setting is not active, the platform uses the response_code that it calculated during authorization to respond to the card network.

Overwrite the Pismo platform decision

If the overwrite Pismo platform decision setting is active, your anti-fraud system's decision is final. In this case, the only restriction is that it must be a Pismo-managed card. If the card is not found in the Pismo database, there is no way to approve this transaction.

To enable this setting, you must open a service request with the authorization team. After enabling this setting, the final decision about approving or declining the purchase is always the anti-fraud response.

❗️

This overwrite platform decision setting must be analyzed thoroughly before being enabled since it allows the anti-fraud system to reverse an authorization denied by any of the validations performed by the Pismo platform.

If the overwrite platform decision setting is active, the authorization process performed by the Pismo platform denies the transaction, but the anti-fraud system approves the transaction, then the Pismo platform responds that the transaction is approved.

📘

Forced approval and ledger update

If you force an approval. the ledger_update_id field is not sent in the network authorization events because the ledger update is being do in parallel.

Overwrite the Pismo platform decision only for the current request

Your anti-fraud system can also overwrite a Pismo platform decision to force an approval for a specific transaction. This feature allows the anti-fraud system to approve an operation that Pismo previously declined in a more granular manner, since it only applies to the current transaction. This feature doesn't require any parameter to be enabled in the platform and doesn't impact all requests, giving the anti-fraud system the option to decide when to overwrite a decision at the request level.

When forcing an approval, the authorization system responds to the request as approved even if Pismo declines it. Forcing an approval impacts the account limit and makes it negative if the available funds are not sufficient to cover the requested amount.

To force an approval, your anti-fraud system must set approve and force_approve to true in the response. Setting approve to true does not override a Pismo-declined transaction, so both fields are necessary.

📘

Note about forced approval

If the platform declines an operation because a card is not found, this operation can't be force approved since the platform can't connect this request with any account. In this case, the operation will remain declined even with the force_approve flag in the response.

Anti-fraud webhook

If you choose to implement anti-fraud integration, you need to register an anti-fraud webhook for this purpose during setup. The webhook enables you to send a response to an authorization that adheres to the standards detailed in the Full balance anti-fraud request webhook specification.

Example response

Below is an example of a response that Pismo receives from an anti-fraud system:

{
    "approve": true,
    "force_approve": false,
    "referral": true,
    "response_code": "00",
    "metadata": {
        "custom_field_1": null,
        "custom_field_2": true,
        "custom_field_3": "Test",
        "custom_field_4": "2021-05-14 23:10:59",
        "custom_field_5": 10,
        "custom_field_6": {
          "custom_field_6_sf1": 10,
          "custom_field_6_sf2": false,
          "custom_field_6_sf3": null,
          "custom_field_6_sfN": "custom_field_6_sfN"
        },
        "custom_field_7": [
          "VALUE_1",
          "VALUE_2",
          "VALUE_N"
        ],
        "custom_field_N": ""
     },
}