There are two methods in which the RIS 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.