Step 5 - Handle the payment response
PayTabs provides you with the backend packages that make the integrating with PayTabs payment gateway very easy by providing ready-made classes that handle the payment process.
This article is dedicated to walking you through how to handle the direct payment response sent from PayTabs after the payment. Handling the response right will empower you to handle the user experience according to the payment status as well as and updating the order status in your database.
To get the best out of this article, it's highly recommended to check our Five ways of receiving transaction response solution article.
via The Return URL response
The return URL is the URL that PayTabs will redirect the customer to after he finishes the payment process (whether it's authenticated or not). It will redirect the customer with a POST response that is sent with the client/cardholder redirection through his browser containing the basic transaction information once the payment process comes to an end (whether the customer cancels, paid, or failed to pay), as shown below. It depends on the customer's actions, which means if the customer closes the browser right after the payment without waiting to be redirected back to your system, you will not receive this response.
"acquirerMessage=&acquirerRRN=&cartId=cart_11111&customerEmail=wajih%40domain.com&respCode=G77803&respMessage=Authorised&respStatus=A&token=&tranRef=TST202860000xxxx"
The "acquirerRPN", "respCode", ... will be different on your Live profiles because they are sent from the bank side.
If the return URL passed as HTTP (Not HTTPS) it will sent as GET response instead with empty payload, to know more please check our What is the Return URL vs the Callback URL? solution article.
What you need to do is to manage the return URL, and for that, you need to check our step 3 - Manage the Return and Callback URLs solution article. The next main step would be to initiate a route to receive this [POST] response according to your business needs.
You should know that since the request is coming from an external system, the CSRF token needs to be excepted. You can either add your previous route to the VerifyCsrfToken middleware $except array Or by initiating this return route in the api.php route file, not the web.php one.
As previously mentioned, the return response will empower you to handle the reduction for the customer who is returning from the payment page, either with an authenticated transaction or an unauthenticated transaction. The respCode, respStatus, and respMessage are also considered an indicator of whether exactly what the transaction status is.
You can know more about Response Codes and Response Statuses from our What is: Response_code vs the Response_status? solution article.
Verify the Return Response
It's highly recommended to verify the Return response first. Verifying the received object is a mandatory step to ensure that the request source is PayTabs itself. To know how to perform this, kindly check our How to verify the response received from PayTabs? (Signature Verification) solution article.
However, we highly recommend you to NOT only rely on this response as it might be affected bu the customer behavior and to rely entirely on the post payment responses clarified in the next step.