PayTabs SDK makes the integration with the PayTabs payment gateway very easy by providing a ready-made payment screen that handles the card entry, and billing & shipping information and completes the missing details.
This article is dedicated to walking you through the business aspect of how to accept the payment that you already initiated in the previous step ( Step 3 - Native IOS SDK | Initiating the payment).
Accepting any payments will be categorized into two phases:
Phase I - The Type of the Payment
This phase would be already handled technically in the second step (Step 2 - Configure the integration method)
- There are three main transaction types provided by PayTabs which are "Sale", "Auth", and "Refund" and two transaction classes which are "Ecom" and "Recurring". All of them are supported in our SDKs except the "Refund" transaction type which is not supported to be handled/managed via this SDK.
You will need just to pass the with either .sale or .auth value as shown in the below example:
configuration.transactionType = .sale
To know more about the different values of the TransactionType Enum object, please check our 2.3 Native IOS SDK | Enums solution article.
Till we support handlign refind via this SDK you will have to either handle the refund from your PayTabs dashboard such as. Or you can use our PT2 API Endpoints direct within your code to perform it. To know more about all the supported transaction types and classes in PayTabs please check our What is the "tran_type" (transaction type)? and What is the "tran_class" (transaction class)? solution articles.
- As for the recurring option please follow the (2.7 Native IOS SDK | Tokenisation (Recurring)) manual to walk you through how it will be handled and managed via this SDK.
Phase II - How are you going to accept/handle customers' card details?
This phase would be already handled technically in the third step (Step 3 - Initiating the payment)
In our SDKs, we follow our mechanism called "Own Form" which implies that payments will be performed within your mobile application itself, however, assuming you are not a PCI Certified merchant, we kept the handling of the credit card information part internally without any interference from your side. In other words, you will not have any access to the customers' credit card details.
Only APMs (Alternative Payment Methods) such Knet and Meeza will be displayed in WebView within our SDK using our Hosted Payment Page mechanism to be managed on our side instead.
This may cause a different in the user experience and fields previewed in the payment form between the APMs and the other payment methods handled in the SDK' own form.
⌂ To get familiar with the whole process and the other steps, kindly navigate to our "The Native IOS SDK Integration Manual" solution article. ⇦ And to navigate to the previous step in the integration process "Step 3 - Initiating the payment" kindly click here. ⇨ Or you can navigate to the next step in the integration process "Step 5 - Handle the payment response" kindly click here.