PayTabs Laravel Package makes integration with the PayTabs payment gateway very easy by providing a ready-made payment class that handles the card entry and, billing & shipping information and completes the missing details.
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.
In this article, you will be going to know how to handle the payment response:
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 3.6 - 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 entirly on the post payment responses clarified in the next step.
⌂ To get familiar with the whole process and the other steps, kindly navigate to our "The Laravel Packge Integration Manual" solution article.
⇦ And to get familiar with the rest of the steps regarding the previuos step "Step 4 - Accepting the payment" click here.
⇨ And to navigate to the next step in the integration process "Step 6 - Handle the post payment responses" kindly click here.