In Auth Transaction Decisioning

Purpose

The In Auth Transaction Decisioning Solution (In Auth) allows clients to participate in the decisioning of their customers' debit card authorization and transaction activity.

With customers' full financial profiles and data from their interactions with the program, clients can use In Auth to decision authorization and transaction messages based on:

• Their ability to evaluate the customer's entire financial profile

• The customer’s recent device or web activity

• One or more data points in the message data payload, based on customer or merchant insights

Overview

The In Auth process begins after initial Visa DPS transaction decisioning, Risk Services Manager decisioning, and Managed Real-Time filters have been applied, and before decisioning of an authorization or financial transaction request message is completed.

Once a message passes Visa DPS, Helix sends a predefined program message and waits for the program response in an allotted time frame. Helix processes the message based on the program decision and sends the applicable response to Visa DPS. Any response past the allocated time will not be honored and will follow normal Helix decisioning.

Refer to the following diagram for transaction decisioning hierarchy and the denial codes used in each stage of the decisioning process:

Requirements for use

Approval

Prior to using In Auth, clients must obtain bank of record approval and sign a sales order. Contact your Client Success Manager (CSM) for more information.

Webhook endpoint

To use this feature, programs must provide a webhook endpoint to allow Helix to call and establish a connection for message transmissions.

The webhook must have the following configurations:

• HTTPS with a Mutual Transport Layer Security (mTLS) certificate

• Payload signing

  • For every request to the webhook endpoint, Helix signs the payload using a pre-exchanged public/private key pair to ensure the authenticity of the payload. The signature is included in the header of the request in a Base64UrlEncoded format.

  • If HTTPS with mTLS is an acceptable security communication for the client, no additional authentication token in the header transmission is required. However, one of the following is preferred:

    1. Token per customer:

       A token for each customer, preferably a JSON Web Token (JWT), is saved in Helix during initial setup and is included in the Helix request payload to the webhook endpoint for the client to validate the request.

    2. Token per program:

       A token for the entire program, preferably a JWT, is saved in Helix during initial setup and is included in the Helix request payload to the webhook endpoint for the client to validate the request.

• A processing time that meets an agreed-upon SLA time frame. Helix specifies a time limit for the client to provide a response back from the webhook call, and any response past the allocated time is discarded.

Helix webhook request

After the client evaluates the payload, the client returns a response message to Helix indicating their decision for Helix to perform.

For more information on the payload and an example response, see In Auth Payload in the Helix API documentation.

Response message

After decisioning the transaction, the program will return a response message to Helix, indicating the result. Based on the decision result, the response adheres to the structure of one of the following examples:

Hard approval

{
"correlationId": "9a5498da-c3bb-450a-aaa9-26e7bdbec6f4",
"response": {
"result": "approve",
"hardApproval": true
}
}

Soft Approval

{
"correlationId": "9a5498da-c3bb-450a-aaa9-26e7bdbec6f4",
"response": {
"result": "approve",
"hardApproval": false
}
}

Deny

{
"correlationId": "9a5498da-c3bb-450a-aaa9-26e7bdbec6f4",
"response": {
"result": "deny",
"reasonCode": "{client-provided data}"
}
}

Refer to the following table for all possible program decision results and configurations:

Visa DPS

Helix will send one of the following return codes to Visa DPS if it is responsible for decisioning:

Otherwise, Helix will send the applicable reason code for its decisioning outcome.

Data received by client

Helix provides detailed information via realtime events and debit card event notifications. Realtime event file payload types impacted by In Auth are:

• Debit Card Deposit Payload (400)

• Debit Card Withdrawal Payload (402)

• Debit Card Withdrawal Authorization Payload (403)

• Debit Card Declined Payload (410)

Additional In Auth property values in realtime events and files are:

• InAuthProgramResult, the client's response from the initial payload, which can be:

  • 1: Approve

  • 2: Decline

  • 3: Abstain

• InAuthHelixResult, the result of the payload communication, which can be:

  • 1: Success

  • 2: Error

  • 3: Timeout

  • 4: Customer token not set

• InAuthProgramResponseDurationinMS, the total time (including program response time) from payload send to receive

For more information on realtime events and transaction files, see the following in the Helix API documentation:

• Realtime Events

• Card Event Notification File

• Card Transaction File

Helix Admin Console

View transaction results

Decisioning results of In Auth transactions are visible to users in Helix Admin Console. For more information, see In Auth transaction results in Card.

In Auth reports

Detailed reports for In Auth transactions, as well as a summarized version of the report, are available in Helix Admin Console. For more information, see In Auth Decisioning and In Auth Decisioning Summary in Card Reports.