Why is the authorizationId, passed up front during createOrder, not returned by the payment engine?

Answer

While creating an order, the authorizationId in payment details is being passed. The com.yantra.yfs.japi.ue.YFSCollectionCreditCardUE is called by the PAYMENT_EXECUTION agent. It is noticed that the authorizationId being fetched from YFSExtnPaymentCollectionInputStruct object is blank.

Since the authorizing id is passed up front during create order, and not during authorizing/charging manually, or through the payment execution API's/services, the system does not store it in the DB.

This gets stored only when the order is explicitly authorized/charged in a separate transaction and the call is made to the collection credit card UE. The UE would now have the authorization id in the input structure and it can be used. The business use case behind this is that, during authorization, the id would be generated or passed on by the payment engines and it would be passed on to the output of the UE. But in the case where the authorization id is generated (and passed to the input of the UE), a separate charge record ‘CLOSED’ should be created. This does not happen when the authorization is done up front during order creation.

As a workaround, pass the authorization id to one of the paymentReferences or the internalReturnMessage, and use it in the UE to return it in the output structure authorizationId.