Trust Payments (Secure Trading) recommends sending transactions as settle status 0, how do I ensure that is the case?

We've had a few cases where Customers asked us why we seem to deviate from Trust Payments (Secure Trading) recommendations for their internal fraud checks.
Please read the below article and hopefully, that will shed some light on why that might be and how you need to handle things for optimal compliance with their recommendations.

1.- iPayment is not sending settle status 0 for authorizations. Is the status 2-Suspended the accurate one for the Authorisation process and if it is, why does Trust Payments think otherwise?
Yes, settle status 2 is the correct one to send for what we call an 'authorization' in iPayment.
This is due to the fact that authorization in iPayment is something where action needs to happen before the authorization is settled. Settle status 2 is the only settle status that allows for this behavior.
Settle status 0 and 1 both schedule the authorization for settlement on the coming settlement processing cycle from Secure Trading.

Our best guess as to why Trust Payments recommends the others is that they want the users to avoid having long-standing authorizations that might potentially go unsettled if not handled by the users.

2.- How do I ensure that the internal fraud checks from Trust Payments are performed on my transactions?
To answer this question we first need to look at how the Trust Payments internal fraud checks are performed.
These fraud checks are not performed in real-time, but rather on a schedule as follows:
--- Feedback from Secure Trading ---
We perform fraud checks throughout the day, they are not in real-time. Please see below times (in GMT) when fraud checks are run;
00:05, 09:00, 12:00, 16:30, 20:05, 21:00, 22:00
-----------------------------------------
Essentially, what this means is that even if you do a direct settlement (settle status 0) you are not ensured to have their fraud check performed.
For this to happen, one of these schedule cycles needs to happen between you performing the settlement and the time where the settlement is actually processed by Trust Payments.

The option to send settle status 0, rather than the default of 1 which bypasses the fraud checking, allows these fraud checks to be performed on the pending settlement (either a 'direct' settlement or an authorization scheduled for settlement) according to the schedule above.
The main problem, and the reason why we sent settle status 1 as default in the past, is that if the Trust Payments fraud check fails, the settlement will be updated to settle status 2 (suspended), which then requires manual action. The problem here is that iPayment won't reflect this change, and thus will consider the transaction as settled with no way to know that the transaction has been suspended and, as a result, no way to settle it.

3.- What is the optimal way to have the fraud checks performed, and what will I do if a transaction fails the check?
Based on previous talks with Trust Payments and the schedule details outlined above, the best way for iPayment and TRust Payments to work together and have the fraud checks performed is:
- Switch to using the settle status 0 option.
- Ensure that your direct settlements and settlements on authorizations are settled at a point in time where you are sure that at least one of these fraud check schedule cycles happen before the actual settlement of the transaction is processed.
- Any fraud checks that result in a suspended transaction will need to be handled outside of iPayment, which means:
     - You'll need to be notified by Trust Payments (email or otherwise) since iPayment isn't automatically notified.
     - You'll then need to handle the transaction manually, either by canceling the documents in SAP and creating new ones to process a new transaction, or handling the collection of the payment manually in the Trust Payments interface.