How to Invoke the Risk Inquiry Service

There are two methods in which the Risk Inquiry Service can be invoked: pre-authorization and post-authorization. Each unique method requires a different flow for implementation, shown below.

Pre-Authorization: Query Kount before attempting an authorization from the payment gateway

  • Allows the merchant to avoid processing fees on orders set to decline by the merchant.

  • All credit card information can be sent to Kount.

  • An update RIS call (MODE=U) must be made to update order number and status of payment authorization, including AUTH, AVST, AVSZ, and CVVR data provided by payment gateway. For pre-authorization queries, the MACK=Y and AUTH=A fields are hardcoded until the Mode=U update call is made to update the appropriate MACK and AUTH values.

  • Cost considerations – the merchant will be paying for inquiries to Kount even for AUTH=D orders. Orders that are declined by a business rule are never sent to the Payment Processor alleviating extra payment processor fees.


Post-Authorization: Query Kount after the payment gateway has been contacted

  • All payment gateway information can be passed to Kount (Authorization, AVS, CVV) allowing rules to be created regarding AVS and CVV data.

  • Some payment gateways do not pass credit card data once they have received it (this will prevent any linking on Payment Token across the Kount Network).

  • Single RIS query, no update is necessary.

  • Cost considerations – the merchant will be paying for inquiries the payment processor even for AUTH=D orders. Only AUTH-A orders are posting in Kount.



This may not be dictated by the merchant if they are using a plugin, cartridge, or extension. You must check to ensure that there is not a platform or internal constraint that will predicate how this will occur. Extensive testing in the TEST environment are needed if they do not know their internal configuration.

Was this article helpful?
1 out of 2 found this helpful