ClickPay provides you with a collection of API endpoints which used to process all payments, regardless of if they are through either your own payment pages, the managed payment pages, or if you are using the hosted payment pages. 


In this article, we will take you on a journey to understand how ClickPay accept the payment you initiated/prepared in the previous step (Step 3 - PT2 API Endpoints | Initiating the payment), starting from receiving it from your side until it sends you the response (which you will handle in the next step) as shown below:


  • 1- Validating the Request
  • 2- Checking Request Applicability
  • 3- Performing the Transaction
  • 4- The Payment Page Processing
  • 5- 3DSecure Authentication & Processing
  • 6- Processing the Payment with the Acquirer Bank
  • 7- Payment Done Successfully 



1- Validating the Request


The first step is to validate the request JSON Payload to ensure that it's a valid JSON object and check for all required parameters, Also, ClickPay validate parameters values in this step, for example, a wrong profile_id which may not match the authorization (Server Key)

Parameters may vary based on the integration type (Hosted Payment Page, Managed Form, or Own Form) clarified in Step 3 - PT2 API Endpoints | Initiating the payment 


We highly recommend you check the parameter specification section regarding the integration type from our PT2 API Endpoints | Parameters folder.


Non-valid request results would be returned within the response, and the detailed reason can be found on ClickPay Dashboard under the inside Developers -> API Debug Logs. To know more, check our What are the API Debug Logs? solution article.



2- Checking Request Applicability


The next step will be to analyze the request and to check if ClickPay can proceed with this request's requirements or not regarding the merchant profile, for example: 


    - A request to pay with a credit card type that is not available for the merchant profile.

    - A request to pay with class recurring, which is not enabled for the merchant profile.

    - A request to Pay with ApplePay using an ApplePay token with a certificate that is not uploaded to 
        the merchant profile.


Those are considered Non-valid requests as well, which means results would be returned within the response, and the detailed reason can be found on ClickPay Dashboard under the inside Developers -> API Debug Logs. To know more, check our What are the API Debug Logs? solution article.


3- Performing the Transaction


The payment comes across this step ONLY with the create Payment Page request through passing the previous two steps, a [Temporary] transaction would be created, and the transaction ref will be returned within the response. The transaction state would be changed to [Permanent] after any action taken by the user (customer)


Temporary transactions CAN NOT be found on the ClickPay Dashboard, or by using query transaction request



4- The Payment Page Processing


The payment comes across this step ONLY with the create Payment Page request. At this phase, the transaction state is still [Temporary], waiting for any action from the user; this includes if the user opens the payment page and triggers the cancel button or enters the wrong card details. Only then would the state be changed.


After the Payment Page expiration time elapsed, which is 20 minutes, if no action had been taken from the user side, the page would be expired, and the transaction would be considered deleted from the ClickPay system.


Triggering the cancel button will NOT proceed the next steps, it will return directly to the Payment results 




5- 3DSecure Authentication & Processing

As per the response from the acquirer, the user will be redirected to the issuer 3DSecure page to fill in the required OTP. This phase  The 3DS2 process is managed entirely by the issuer bank side; ClickPay is not included. 


So what really happens backstage can be simplified as the issuer bank somehow asks ClickPay to inject the below HTML object within the ClickPay payment page. This code is managed by the ACS of the issuer, which handles the 3DS2 process between the customer’s device and the issuer.

However, after injecting this code and leaving the control to the issuer’s ACSs, some of the issuers stop responding or communicating with ClickPay with any updates. Hence the customer will be kept on the payment page looping in the loading screen, waiting for the issuer side to respond, communicate, or even redirect him. ClickPay has no upper hand or control over making a non-responding issuer respond. 



6- Processing the Payment with the Acquirer Bank


Passing the previous steps, the request will proceed to the acquirer side. At this step, the transaction state would be changed to a [Permanent]. Per the response from the acquirer, the 3DSecure may or may not be required.


7- Payment Done Successfully 


After receiving the results from the acquirer, the transaction status will be set according to our Response_code vs. the Response_status solution article, and all transaction details will be logged into it.