Step 4 - Accepting the payment
In this manual, we will guide you through the process of how PayTabs accepts the payment you initiated or prepared in the previous step Step 3 - Initiating the payment. We will start from the moment PayTabs receives the payment request from your side and continue until it sends you the response, which you will handle in the next step. Follow along as we break down each stage of this process:
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, PayTabs 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 as clarified in Step 3 of this manual.
Non-valid request results would be returned within the response, and the detailed reason can be found on PayTabs Dashboard under the inside Developers - API Debug Logs. To know more, check ourWhat is the API Debug Logs?tutorial article. article.
2- Checking Request Applicability
The next step will be to analyze the request and to check if PayTabs 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 PayTabs Dashboard under ourWhat is the API Debug Logs?tutorial 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)
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 PayTabssystem.
5- 3DSecure Authentication & Processing
If the payment method requires 3DSecure authentication, the customer will be redirected to the 3DSecure page to complete the authentication process. Once completed, the customer will be redirected back to the hosted payment page.
6- Processing the Payment with the Acquirer Bank
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; PayTabs is not included.
So what really happens backstage can be simplified as the issuer bank somehow asks PayTabs to inject the below HTML object within the PayTabs 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 PayTabs 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. PayTabs has no upper hand or control over making a non-responding issuer respond.
7- Payment Done Successfully
Once the payment is successfully processed by the acquirer bank, PayTabs will send the payment response back to your system. You can then handle the response as needed in the next step. For a better understanding you can check the resources onWhat is: Response_code vs the Response_status?