When you make the initial call to the authorise sim, you can send in a parameter in the additionalData called executeThreeD. If this is set to "true", the 3D secure flow will kick in, and your response will contain the necessary parameters and information to complete the call to the bank's verification page.
Once you got the issuerUrl, md and paRequest back from the authorise sim, you need to send a POST request with them. The target will be the issuerUrl, with paRequest and md as the parameters. You also need a TermUrl in that POST parameters. This is the URL where you will receive the callback after the customer finished with the bank's verifications.
Then you need to follow the steps there to complete the payment request.
This is usually called 'Verified by Visa' or 'MasterCard Secure Code'. In essence they are the same things - they are there to conduct 1 or 2 challenges on behalf of the issuer bank to verify the customer's identity. It is used for a so called 'liability shift' from the issuer side to the merchant, thus reducing the number of chargebacks coming from customers through the merchant.
Our version is a dumbed down version of these bank pages, only showing you the sent parameters and letting you check once more before sending the customer back to the TermUrl of your choice.
Once you click 'Continue' on our bank sim page, you will be sent back to your own domain. This is when Testing Pays (in real life the bank) will make a POST request to the TermUrl sent in the initial request with the following parameters:
At this stage you call the authorise3d endpoint with some of the original parameters like reference or amount. Make sure you include the paResponse that you got back from the bank page - or in this case Testing Pays' bank sim.
Calling authorise3d after you have returned from the bank's interface.