Authorization Optimizer adds one step to the Payments Fraud pre-authorization workflow. After Payments Fraud returns a risk decision, we send a data payload about the transaction to the issuer network before your authorization request reaches the issuer.
-
The cardholder places an order on your website or app. The Device Data Collector (DDC) collects device data during the session.
-
Your server sends the order to the Payments Fraud Orders API for a risk inquiry, before you request payment authorization.
-
Payments Fraud evaluates the order and returns a decision of APPROVE, DECLINE, or REVIEW.
-
Authorization Optimizer compares the card BIN with the list of participating BINs. If the transaction matches, we send the Additional Auth Data payload to the issuer network.
-
For approved orders, you send the authorization request to your payment processor, as you do today.
-
The issuer matches your authorization request to the Authorization Optimizer data and evaluates the transaction with the additional context.
Note
If Payments Fraud returns a DECLINE decision, do not send the transaction for payment authorization.
We send data to issuers for orders with an APPROVE decision and for orders with a DECLINE decision.
-
Approved orders: You send these orders for authorization, so the issuer uses the data to make the authorization decision. Only approved orders receive higher approval rates.
-
Declined orders: You do not send these orders for authorization. Issuers use the data to improve their fraud models.
Authorization Optimizer evaluates the BIN of every order that you send to Payments Fraud. We update the list of participating BINs as issuers add BINs to the program, so you do not maintain BIN lists.
If a transaction does not match a participating BIN, we do not send data to the issuer network. Your Payments Fraud workflow does not change.
To establish an initial match, issuers require exact alignment across all of the following data points:
-
BIN and last four digits of the card
-
Transaction amount
-
Currency
-
Timestamp
Customer details (such as name, email, phone number, and address) are not used for initial matching. Instead, issuers apply customer details only after a successful match is established to support their decision-making.
During the first 30 days of your contract, issuers calibrate their models with your transaction data. Authorization Optimizer sends data during this period, but issuers do not apply optimizations until the calibration period ends.
We send the payload immediately after the risk decision so that the data reaches the issuer before your authorization request. Authorization Optimizer runs in the background and does not add a step to your checkout or delay the Payments Fraud response.
If the issuer network returns a server error (HTTP 5xx status code), we retry the delivery one time immediately. If the retry fails, we record the event for reconciliation. A failed delivery does not delay your Payments Fraud response or your authorization request. The issuer evaluates the transaction with the standard authorization data only.
Comments
0 comments
Article is closed for comments.