SDK Core for iOS

Overview

Introduction

Mobile SDK Core for iOS is a software development kit that can be used to integrate iOs applications with the ecommpay payment platform.

SDK Core for iOS ensures the interaction of a mobile application with the payment platform for sending and receiving necessary information during payment processing. With that, SDK Core for iOS does not insure customer interaction with the user interface—this allows the merchant to use their in-house payment interface during the work with this development kit.

This article provides the information about working with SDK Core for iOS with the description of the interaction workflow, payment processing scenarios, and additional capabilities with code examples in the Swift language.

SDK Core for iOS can be embedded in mobile applications developed for iOS version 11 or later. The libraries of SDK Core for iOS and code examples are provided on GitHub at the following URLs:

Capabilities

SDK Core for iOS supports the work with payment cards and the Apple Pay alternative payment method. The following functional capabilities are supported by SDK Core for iOS:

  • Processing purchases with immediate debiting of funds.
  • Placing an authorisation hold on funds for subsequent debiting of the funds after a certain period expiration or based on the corresponding request from the merchant (sent via the interface Gate or Dashboard).
  • Verifying payment cards for their subsequent use.
  • Registering COF purchases.
  • Saving payment data for subsequent processing of purchases.

During payment processing, additional actions can be required from customers, for example, for performing 3‑D Secure authentication and specifying the details about the owner of the payment instrument. The applicability of these actions usually depends on the protocols and rules of the providers and payment systems, however, in some cases, can depend on the merchant's preferences as well. The following procedures and additional capabilities are supported by SDK Core for iOS:

  • 3‑D Secure authentication—the procedure of customer authentication with the use of the3‑D Secure protocols.
  • Cascade payment processing—additional payment processing attempts (used when necessary) without changing the payment method.
  • Submission of additional payment information—the procedure of specifying additional data that can be required by payment systems in certain cases.
  • Collection of customer data—getting and providing additional customer information that can be relevant for processing subsequent payments.

Setting up the capabilities of cascade payment processing and customer data collection should be coordinated with the ecommpay specialists.

Workflow

Generally, purchases with the use of SDK Core for iOS are processed according to the following workflow.

  1. The customer initiates a purchase in the user interface of a mobile application by clicking the payment button or by another method set up on the merchant side.
  2. In the mobile application, a set of parameters for creating the payment session is generated. Then, with the help of SDK Core for iOS, this set is converted into a string for signing the parameters and the string is sent to the server side of the merchant's web service.
  3. On the server side of the merchant's web service, the parameters can be checked and supplemented if necessary, and the signature to the final parameter set is generated, after that, the prepared data is sent back toSDK Core for iOS.
  4. With the help of SDK Core for iOS, the payment session creation is initiated in the payment platform.
  5. On the payment platform side, based on the project and customer identifiers, the lists of the available payment methods and saved payment data are sent to SDK Core for iOS.
  6. In the mobile application, the information received from SDK Core for iOS is processed and prepared to be further displayed to the customer.
  7. The customer chooses a payment method (if no method has been set during the payment session opening), specifies the necessary information, and confirms the purchase.
  8. In the mobile application, a certain scenario of work with SDK Core for iOS is called—with regard to all actions performed by the customer.
  9. The request for processing the purchase according to the called scenario is sent from SDK Core for iOS to the payment platform.
  10. On the payment platform side, the payment is registered and all necessary technical actions are performed; these actions include sending the required data to the payment environment—to the providers and payment systems.
  11. The payment is processed in the payment environment; then the payment result information is received in the payment platform.
  12. In the payment platform, the information about the payment result is processed and sent to the server side of the web service.
  13. The information about the purchase result is sent from the payment platform to SDK Core for iOS.
  14. The notification with the result information is sent from SDK Core for iOS to the mobile application and then is displayed to the customer.

Setup

Integration steps

To integrate the web service with the ecommpay payment platform by using SDK Core for iOS, proceed as follows:

  1. Address the following organisational issues of interaction with ecommpay:

    1. If the company has not obtained a project identifier and a secret key for interacting with ecommpay, submit the application for connecting to the ecommpay payment platform.
    2. If the company has obtained a project identifier and a secret key for interacting with ecommpay, inform the technical support specialists about the company's intention to integrate by using SDK Core for iOS and coordinate the procedure of testing and launching the functionality.
  2. Complete the following preliminary technical tasks:

    1. Download and link SDK Core for iOS.
    2. Prepare the user interface and ensure the collection of data necessary for initiating the payment session. The minimum data set needed for the data session creation consists of the project, payment, and customer identifiers as well as of the payment amount and currency.
    3. Ensure signature generation for the data on the server side of the mobile application.
    4. Ensure the receipt of and the response to the notification from SDK Core for iOS as well as the receipt of and the response to the callbacks from the payment platform on the web service side.
  3. Coordinate the procedures and dates of integrating, testing (including testing available payment methods), and launching the solution.

    1. For testing, the test project identifier and the test cards details should be used.
    2. For switching to the production mode, the value of the test project identifier should be changed to the value of the production project identifier received from ecommpay.

The questions about working with SDK Core for iOS, if any, should be directed to the ecommpay technical support specialists (support@ecommpay.com).

Libraries installation

For the mobile applications developed for iOS version 11 or later linking the SDK Core for iOS libraries via CocoaPods is supported. To link the libraries, proceed as follows:

  1. Open the Podfile module and add the following code to the module:
    target 'App' do
        pod 'MsdkCore'
    end
  2. Run the pod install command.
  3. Import the library by running the import MsdkCore command.

Signature generation

Data signing should be performed on the server side of the web service with the use of the secret key received from ecommpay. To work with the signature, the merchant can use ready-to-use components, such as SDKs for web services in different programming languages (details) or the merchant's in-house solutions. The procedure of working with the signature is provided in the section Signature generation and verification.

Testing

Before processing real payments via SDK Core for iOS, it is recommended to test payment processing in the test project. The merchant can obtain the identifier and the secret key of the test project when accessing the ecommpay test environment (this can be done via the company's website). Along with that, upon the coordination with the ecommpay specialists, it is possible to test the usage of the Apple Pay method and additional capabilities, such as cascade payment processing and collection of customer data.

To switch to the test mode, proceed as follows:

  1. Open the project folder and run the pod install command.
  2. Open the project via iosApp.xcworkspace.
  3. In the Info.plist file, specify the identifier (PROJECTID) and the secret key (PROJECT_SECRET_KEY) of the test project.

To switch to the production mode, change the test values (the identifier and the secret key of the test project) to the production ones.

Usage

SDK Core for iOS supports various targeted actions and, for each of these actions, a certain parameter set is required. The required minimum of parameters is sent in the initial request for creating a payment session; the rest of the parameters can be requested from the customer and received from the payment platform. Based on the received parameters, the request for creating the payment according to one of the available scenarios is generated.

The scenarios, procedures of performing targeted actions, and the set of the parameters available during the work with SDK Core for iOS are provided in the following sections of this article.

Procedure of performing targeted actions

SDK Core for iOS supports targeted actions with the direct use of cards and with the use of the Apple Pay alternative method (details). To work with the Apple Pay payment method, the merchant should first contact the ecommpay technical support specialists to coordinate the method setup.

Warning: Starting August 12, 2024, Visa Rules will be updated to expand the set of parameters mandatory for processing Visa card payments with the 3‑D Secure authentication. In such cases it will be required to specify the customer's phone number or email. At least one of these parameters must be specified in the request for creating the payment session.

However, it is also recommended that these and a number of other parameters (with the billing address information) are specified for payments made with cards of other card schemes. According to Visa, rigorous use of these parameters can significantly increase payment acceptance rates (up to 6 %) and drastically decrease the number of operations flagged as fraudulent after they have been processed (up to 65 %).

Generally, to process purchases via SDK Core for iOS, the merchant should do the following:

  1. Create the MSDKCoreSession object.
    let msdkConfig = MSDKCoreSessionConfig.companion.debug(apiHost: "API HOST", wsApiHost: "WS API HOST")
    let msdkSession = MSDKCoreSession(config: msdkConfig)
  2. Create the PaymentInfo object with the parameters of payment processing. This object should contain the required minimum of parameters (the project identifier, the payment identifier, the payment amount, and the payment currency), additionally, other parameters can be submitted (details).
    let paymentInfo = PaymentInfo.companion.create // payment information
    (
    projectId: 553,             // project identifier
    paymentId: "payment_21",    // payment identifier
    customerId: "12",           // cutomer identifier
    paymentAmount: 400,         // payment amount
    paymentCurrency: "EUR"      // payment currency code
    )
    
  3. Receive the string for signing the parameters and send it to the server side of the application.
    paymentInfo.getParamsForSignature(),
  4. On the server side of the application, sign the final set of parameters and send it to the client side.
  5. Add the signature to the PaymentInfo object.
  6. Send the request for creating the payment session. For this, call the getInitInteractor method.

    At this point, specify the parameters for 3‑D Secure if they are required. You may need to specify the customer's email (customerEmail) or phone number (customerPhone). In addition, it is also recommended that you pass the customer's billing address information:

    • billingCountry—the country of the customer's billing address in the ISO 3166-1 alpha-2 format (details)
    • billingPostal—the postcode of the customer's billing address
    • billingCity—the city of the customer's billing address
    • billingAddress—the street of the customer's billing address
    let request = InitRequest(
         paymentInfo: paymentInfo,
         recurrentInfo: nil,      
         additionalFields: [  //list of fields for collecting additional information
            "customerEmail": customerEmail,
            "customerPhone": customerPhone
         ] as [String: Any]
    )
    msdkSession.getInitInteractor().execute(
        request: request,
        callback: self
    )
  7. Receive the notification with the information about the payment session creation and the lists of the available payment methods and saved payment data that are relevant for the project in use and a particular customer.
    func onInitReceived(paymentMethods: [PaymentMethod], savedAccounts: [SavedAccount]) {
        let stringResourceManager = msdkSession.getStringResourceManager()
        let title = stringResourceManager?.payment.methodsTitle
              
        let secureLogoResourceManager = msdkSession.getSecureLogoResourceManager()
        let visaIconUrl = secureLogoResourceManager?.getLogoUrl(key: "visa")
              
        let paymentMethods = msdkSession.getPaymentMethods()    // receiving payment method list
        let savedAccounts = msdkSession.getSavedAccounts()    // receivig saved payment data list
    }
  8. Process the received data and display the payment form to the customer.
  9. To process a purchase via Apple Pay, proceed as follows:
    • Receive a token from Apple Pay. For this, you can use the PKPaymentRequest class that allows interacting with PassKit.
      let supportedPaymentNetworks = [PKPaymentNetwork.visa, PKPaymentNetwork.masterCard]
      let paymentItem = PKPaymentSummaryItem(label: "MSDK Pay", amount: NSDecimalNumber(value: 1.23))
       
      if PKPaymentAuthorizationViewController.canMakePayments(usingNetworks: supportedPaymentNetworks) {
          let request = PKPaymentRequest()
          request.currencyCode = "EUR"
          request.countryCode = "GB"
          request.merchantIdentifier = "merchant_id"
          request.merchantCapabilities = PKMerchantCapability.capability3DS
          request.supportedNetworks = supportedPaymentNetworks
          request.paymentSummaryItems = [paymentItem]
           
          guard let paymentVC = PKPaymentAuthorizationViewController(paymentRequest: request) else {
              return
          }
          paymentVC.delegate = self
          self.present(paymentVC, animated: true, completion: nil)
      }
    • Receive a token in the PKPaymentAuthorizationViewControllerDelegate notification.

      var completion: ((PKPaymentAuthorizationResult) -> Void)?
       
      func paymentAuthorizationViewController(_ controller: PKPaymentAuthorizationViewController, 
      didAuthorizePayment payment: PKPayment, handler completion: 
      @escaping (PKPaymentAuthorizationResult) -> Void) {
          self.completion = completion
          let token = String(decoding: payment.token.paymentData, as: UTF8.self)
          }
  10. Send the request for payment creation based on the data received from the customer. For this, call the getPayInteractor method.
    // purchase with the use of a card
        override func viewDidLoad() 
    {
        super.viewDidLoad()
        // scenario of purchase processing with the use of a card
        AppDelegate.msdkSession?.getPayInteractor().execute
            (request: NewCardSaleRequest    
                (   cvv: "123",
                    pan: "5413330000000019",
                    expiryDate = CardDate(month = 1, year = 2025),
                    cardHolder: "John Doe",
                    saveCard: false
                ), 
        callback: self)
    }
         
        // purchase with the use of the Apple Pay method    
        AppDelegate.msdkSession?.getPayInteractor().execute
            (request: ApplePaySaleRequest.init
                (    token: token    // token received from Apple Pay
                    ), 
        callback: self
  11. Receive a range of notifications from SDK Core for iOS—about the payment creation and the payment status change. If relevant, also accept the notifications stating that the submission of additional payment information and 3‑D Secure authentication are required and perform the needed actions.
  12. Receive the notification with the payment information result and display this information to the customer.

During the processing of certain payments, the merchant and the customer are required to perform a range of actions for carrying out certain procedures. The work with such procedures is described in the following sections of this article.

Parameters of work with SDK Core for iOS

Actions with payment cards

For performing targeted actions with the direct use of cards, such as purchase processing (NewCardSaleRequest), authorisation holds on funds (CardAuthRequest), and card verification (CardVerifyRequest), the following data sets are used.

Payment session creation Payment creation
  • project_id (integer)—project identifier received from ecommpay
  • payment_id (string)—payment identifier unique within the project
  • payment_amount (integer)—payment amount in minor currency units (for card verification use the value 0)
  • payment_currency (string)—payment currency code in the format of ISO 4217 alpha-3
  • customer_id (string)—customer identifier unique within the project
  • register (boolean)—indicator of the COF purchases registration for which the value true should be used. The information about the parameters available for registering COF purchases is provided in the separate article
  • cvv (string)—card verification value
  • pan (string)—card number (without spaces)
  • year (integer)—card expiration year
  • month (integer)—card expiration month
  • cardHolder (string)—cardholder name specified on the card
  • saveCard (boolean)—indicator showing whether the payment card data has been saved

Tokenisation

SDK Core for iOS supports tokenisation of payment data. When the scenario of tokenisation (CardTokenizeRequest) is running, no financial operations are performed but a secure identifier associated with the data of a particular payment card is generated. The information about generating and using tokens is provided in the corresponding articles—Tokenization and Payments by using tokens.

For generating tokens via SDK Core for iOS, the following data sets are required.

Payment session creation Tokenisation
  • project_id (integer)—project identifier received from ecommpay
  • customer_id (string)—customer identifier unique within the project
  • pan (string)—card number (without spaces)
  • year (integer—card expiration year
  • month (integer)—card expiration month
  • cardHolder (string)—cardholder name specified on the card

Usage of saved payment data

SDK Core for iOS supports the capability of saving payment data on the customer initiative and by generating tokens. It also supports using this data for payment processing. With saved payment data and tokens, it is possible to process purchases and place authorisation holds on funds via certain scenarios. In case of saved data, these scenarios are: SavedCardSaleRequest (for processing purchases) and SavedCardAuthRequest (for placing holds on funds); in case of tokens, these scenarios are CardSaleTokenizeRequest (for processing purchases) and CardAuthTokenizeRequest (for placing holds on funds).

Payment session creation Payment creation
  • project_id (integer)—project identifier received from ecommpay
  • payment_id (string)—payment identifier unique within the project
  • payment_amount (integer)—payment amount in minor currency units
  • payment_currency (string)—payment currency code in the format of ISO 4217 alpha-3
  • customer_id (string)—customer identifier unique within the project
  • account_token (string)—payment data token (for the scenarios where a token is used)
  • cvv (string)—card verification value
  • accountId (integer)—saved payment data identifier received in the notification about the payment session creation

Purchases by using alternative methods

SDK Core for iOS supports processing purchases (ApplePaySaleRequest) and placing holds on funds (ApplePayAuthRequest) by using the Apple Pay method.

To process purchases with the use of the Apple Pay method, proceed as follows:

  1. In the Apple service, register the merchant identifier (Merchant ID) which allows accepting payments by using the Apple Pay method. This identifier remains valid indefinitely and can be used for various web sites and iOS applications. The information about registering this identifier is provided in the Apple documentation: Create a merchant identifier.
  2. Generate an Apple certificate for payment processing (Payment Processing Certificate). This certificate is used together with the merchant identifier and ensures the safety of payment data during payment processing via the Apple Pay method. The information about the certificate generation is provided in the Apple documentation: Create a payment processing certificate.
  3. Provide the ecommpay technical support specialists with the payment processing certificate by using the coordinated methods of protection.
  4. Set up the support of Apple Pay for the mobile application project in the development environment in use.
Payment session creation Payment creation
  • project_id (integer)—project identifier received from ecommpay
  • payment_id (string)—payment identifier unique within the project
  • payment_amount (integer)—payment amount in minor currency units
  • payment_currency (string)—payment currency code in the format of ISO 4217 alpha-3
  • customer_id (string)—customer identifier unique within the project
  • token—token received from Apple Pay
  • recepientInfo (used for the scenario ApplePayAuthRequest)—object with the customer details; this object is used for purchases initiated for debt repayment

Usage of additional parameters

Besides the required minimum of parameters, the additional ones can be used in requests.

  • recurrentInfo—object with the COF purchase information (details).
  • paymentDescription (string)—payment description.
  • regionCode (string)—country code in the format of ISO 3166 alpha-2.
  • token (string)—payment data token.
  • forcePaymentMethod (string)—code of the preselected payment method. The codes of payment methods are provided in the corresponding reference.
  • hideSavedWallets (boolean)—parameter that allows setting whether the payment instruments are displayed or not displayed to the customer. Possible values:
    • true—saved payment instruments are not displayed to the customer.
    • false—saved payment instruments are displayed to the customer.

Additional capabilities

Saving payment data

During the work with SDK Core for iOS, it is possible to save customer payment data for further processing of payments, without this data being re-entered by customers. Payment data can be saved on the customer's initiative or with the use of the tokenisation scenario (CardTokenizeRequest). While tokenisation is the default capability within the project, the capability of saving payment data on the customer's initiative needs to be set up. To set up the capability of saving payment data address the ecommpay technical support specialists and ensure that the toggle switch for saving data is displayed in the user interface.

As a result of saving payment data on the customer's initiative, a separate identifier (account_id) is generated for each payment instrument. This identifier is associated with the identifier of a particular customer (customer_id). These payment instrument identifiers can be received in the notification from SDK Core for iOS about the payment session creation and used in the request for payment creation.

If the payment data was saved as a result of the CardTokenizeRequest scenario, a token is generated for a certain card of the customer. This token can be received in the notification stating that the token has been generated in the Payment object and further specified in payment requests. For executing the tokenisation scenario, the request for creating a session in SDK Core for iOS (initiated on the merchant's side) should contain the project and customer identifiers, the rest of the details for token generation (the number and expiration date of the payment card and cardholder name) should be requested from the customer.

Figure: Example of saved payment data

"SavedAccounts":
{
  "number": "541333******0019",
  "token": "0bd983f99878381dce27d20478829458d19df7c88f287ad8753092d...", // payment data token
  "id": 12353661,   // saved payment data identifier (accountId)
  "last_deposit_date": "2022-04-22 06:22:33",
  "last_tokenize_date": null,
  "type": "card",
  "additional": {
    "email": "john@example.com",
    "phone": "+440202267709",
    "country": "GB",
    "recurring_enable": false,
    "card": {
      "holder": "Jonh Doe",
      "country": "GB",
      "bank_name": "CIAGROUP",
      "type": "mastercard",
      "product_name": "PREPAID",
      "expiry": "02/24"
    }
  },

3‑D Secure authentication

When the customer 3‑D Secure authentication is required for payment processing, proceed as follows:

  1. Receive the notification onThreeDSecure stating that displaying the authentication page to the customer is required. This notification contains the acsPage object with the parameters of displaying the authentication page and the link for redirecting the customer after the authentication.
  2. Display the authentication page to the customer.
  3. Wait for the customer to be redirected from the authentication page and call the threeDSecureHandled method.
func onThreeDSecure(acsPage: AcsPage, isCascading: Bool, payment: Payment)
{
    interactor.threeDSecureHandled()    // calling method
}

Cascade payment processing

In case of a payment attempt failure, the capability of cascade payment processing can be used (details). This capability implies a sequence of payment attempts via alternative providers without the payment method change and can be set up upon coordination with the ecommpay specialists.

With this capability set up for the project in use and after the first unsuccessful attempt, a notification is received from SDK Core for iOS. This notification contains the isCascading object with the value true which means that an additional attempt is available as part of the cascade payment processing. If the customer authentication is required for processing the payment, the merchant should display the error information to the customer, obtain the customer's confirmation to make another attempt, and retry the payment. If the authentication is not required, no additional actions are performed on the merchant's side.

func onThreeDSecure(acsPage: AcsPage, isCascading: true, payment: Payment)
{
    interactor.threeDSecureHandled()  
}

Submission of additional payment information

Generally, for processing a payment, it is enough to send a set of parameters that are mandatory for initiating this payment. Still in some cases, a payment system or a provider can require additional data necessary for processing a particular payment. This can be due to region-specific requirements, the need for an additional anti-fraud check, or other factors. The information about submitting additional payment data is provided in the separate article.

The final set of required parameters can vary depending on a particular provider or payment system. The list of parameters relevant for a particular payment is received in the notification from SDK Core for iOS after the request for payment creation (GetPayInteractor) has been sent. The merchant should ensure that the fields to be filled with the required data are displayed to the customer and then send the obtained values to SDK Core for iOS.

func onClarificationFields(clarificationFields: [ClarificationField], payment: Payment) { // receiving the list of required data
    interactor.sendClarificationFields(clarificationFields) // sending the data received from the customer
}

Collection of customer data

In some cases, alongside the mandatory parameters, it can be relevant to require the additional ones (such as phone numbers and email addresses) from the customers. To have this capability set up, the merchant should decide which data should be requested and mandatory to be specified by the customers, then provide this information to the technical support specialists. For more information about using the capability of collecting additional data, see the separate article.

After receiving the notification with the list of the required parameters from SDK Core for iOS, the merchant should display the fields to be filled by the customer in the payment form, send the obtained data to SDK Core for iOS, and continue payment processing.

func onCustomerFields(customerFields: [CustomerField]) { // receiving the list of required data
    interactor.sendCustomerFields(customerFields) // sending the data received from the customer
}

Notification receipt

Informing about payment session

SDK Core for iOS supports sending notifications with the payment session information. Intermediate notifications which are sent during the payment session creation fall under the InitDelegate group and provide information about various events and possible errors that can happen before the request for payment creation is sent. Such notifications include the following ones:

  • onInitReceived—the payment session has been created in the ecommpay payment platform.
    func onInitReceived(paymentMethods: [PaymentMethod], savedAccounts: [SavedAccount]) {
        let stringResourceManager = msdkSession.getStringResourceManager()
        let title = stringResourceManager?.payment.methodsTitle
             
        let secureLogoResourceManager = msdkSession.getSecureLogoResourceManager()
        let visaIconUrl = secureLogoResourceManager?.getLogoUrl(key: "visa")
             
        let paymentMethods = msdkSession.getPaymentMethods()
        let savedAccounts = msdkSession.getSavedAccounts() ?? []
    }
  • onPaymentRestored—the payment session has been created with the use of a payment identifier used previously. If the payment has not been assigned a final status yet, you can use the PaymentRestoreRequest method and continue processing the previously initiated payment.
    override func viewDidLoad() {
            super.viewDidLoad()
            AppDelegate.msdkSession?.getPayInteractor().execute(request: PaymentRestoreRequest(), callback: self)
        }
  • onError—an error has occurred.
    override fun onError(code: "Network & Server API", 
    message: "{"status":"validation","code":"501",
    "errors":{"sid":"Make payment before check status"}}")

Informing about payment

Intermediate and final notifications sent during payment creation fall under the PayDelegate group. Such notifications can contain the information about a payment status, the requirement of performing additional actions, and arising errors.

  • onPaymentCreated—the payment has been created.
  • onStatusChanged— the payment status has been changed.
  • onCustomerFields—additional customer data is required.
  • onThreeDSecure3‑D Secure authentication is required.
  • onClarificationFields—additional payment information is required.
  • onCompleteWithSuccess—the payment has been completed.
  • onCompleteWithFail—the payment has been rejected.
  • onCompleteWithDecline—the payment has been declined.
  • onError—an error has occurred.
    override fun onError(code: "Network & Server API", 
    message: "{"status":"validation","code":"501",
    "errors":{"sid":"Make payment before check status"}}")

Error handling

In case of errors during request processing, the corresponding notifications are received from SDK Core for iOS. Possible errors, their reasons, and actions recommended for the merchant in such cases are provided in the following table.

Error Possible error Recommended actions
CLARIFICATION_FIELDS_ERROR Incorrect data was sent during the submission of additional payment information Resubmit additional information
CUSTOMER_ID_NOT_EXIST The required parameter customerId was not sent in the request for tokenisation or payment card verification Correct the request
ILLEGAL_ARGUMENTS Incorrect values were sent in the request Correct the request
INTERACTOR_NOT_RUNNING An action available within payment processing was attempted before the payment initiation (for example, the customer additional data was submitted before the request for payment creation was sent) Send the request for payment creation
NETWORK_ERROR A connection error occurred Contact the technical support specialists
NETWORK_IS_NOT_AVAILABLE The network is unreachable Retry the request later
NETWORK_TIMEOUT The request processing was declined since a timeout occurred Retry the request later
PAYMENT_ALREADY_EXIST The request processing was declined because the request contains the payment identifier that had been used previously Specify the identifier that is unique within the project and retry the request
PAYMENT_HAS_FINAL_STATUS The request processing was declined because the request contains the identifier of the payment that had been already assigned a final status Specify the identifier that is unique within the project and retry the request
PAYMENT_METHOD_NOT_AVAILABLE The request processing was declined because the request contains the code of a payment method unavailable within the project in use Specify a payment method available within the project and retry the request
PAYMENT_NOT_FOUND The Payment object was not found Retry the request. In case of an error, contact the technical support specialists
PAYMENT_TOKEN_NOT_EXIST The request for purchase processing or payment card verification with the use of a token does not contain the token of the payment data Specify the payment data token and retry the request
SERVER_API_ERROR An error occurred on the SDK Core for iOS side Contact the technical support specialists
SESSION_NOT_INITIALIZED The request processing was declined due to the attempt of executing a scenario before the payment session creation Initiate the creation of a payment session (InitInteractor)
SERVER_CONTENT_PARSING_ERROR A server response could not be parsed Correct the request
SERVER_METHOD_NOT_FOUND A method unavailable for the work with SDK Core for iOS was called Correct the request
SERVER_UNAUTHORIZED A connection error occurred Retry the request later