SDK Core for Android

Overview

Introduction

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

SDK Core for Android ensures the interaction of a mobile application with the payment platform for sending and receiving necessary information during payment processing. That said, SDK Core for Android 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 Android. This information includes the description of the interaction workflow, payment processing scenarios, and additional capabilities with code examples in the Kotlin language.

SDK Core for Android can be embedded in mobile applications developed for Android version 5.0 or later. The libraries of SDK Core for Android and code examples are provided on GitHub, to access them, use the following URLs:

Capabilities

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

  • 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, it can depend on the merchant's preferences as well. The following procedures and additional capabilities are supported by SDK Core for Android:

  • 3‑D Secure authentication—the procedure of customer authentication with the use of the 3‑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 Android 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 a payment session is generated. Then, with the help of SDK Core for Android, this set is converted into a string for signing the parameters and the string is sent to the server side of the merchant web service.
  3. On the server side of the merchant 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 to SDK Core for Android.
  4. With the help of SDK Core for Android, creation of the payment session 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 Android.
  6. In the mobile application, the information received from SDK Core for Android 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 Android 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 Android 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 Android.
  14. The notification with the result information is sent from SDK Core for Android to the mobile application and then displayed to the customer.

Setup

Integration steps

To integrate the web service with the ecommpay payment platform by using SDK Core for Android, 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 Android and coordinate the procedure of testing and launching the functionality.
  2. Complete the following preliminary technical tasks:

    1. Download and link SDK Core for Android.
    2. Prepare the user interface and ensure the collection of data necessary for initiating a payment session. The minimum data set needed for the payment 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 Android 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 Android, if any, should be directed to the ecommpay technical support specialists (support@ecommpay.com).

Libraries installation

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

  1. Open the module build.gradle.kts in the application.
  2. Specify the mavenCentral repository in the repositories section:
    allprojects {
        repositories {
            google()
            mavenCentral()
        }
    }
  3. Add the following code in the dependencies section:
    implementation "com.ecommpay:msdk-core-android:LATEST_VERSION"

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 Android, 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 Google 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 module build.gradle.kts in the application.
  2. Specify the identifier (projectId) and the secret key (projectSecretKey) of the test project.
  3. Launch the synchronisation process gradle.

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 Android 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 a 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 Android are provided in the following sections of this article.

Procedure of performing targeted actions

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

Generally, to process purchases via SDK Core for Android, proceed as follows:

  1. Create the MSDKCoreSession object.
    val config = MSDKCoreSessionConfig.debug("API HOST", "WS API HOST")
    val msdkSession = MSDKCoreSession(config)
  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).
    val paymentInfo = PaymentInfo(  // payment information
        projectId = 553,   // project identifier
        paymentId = "payment_21",   // payment identifier
        paymentAmount = 400,        // payment amount
        paymentCurrency = "EUR",    // payment currency code
        customerId = "12"           // customer identifier
    )
  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.
    val interactor = msdkSession.                                              
        InitRequest(paymentInfo, null, null),
        this
    )
  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.
    fun onInitReceived(
    paymentMethods: List<PaymentMethod>,
    savedAccounts: List<SavedAccount>
    ) {
    val stringResourceManager = msdkSession.getStringResourceManager()
    val title = stringResourceManager.payment.methodsTitle
     
    val setSecureLogoResourceManager = msdkSession.getSecureLogoResourceManager()
    val visaIconUrl = setSecureLogoResourceManager.getLogoUrl("visa")
     
    val paymentMethods = msdkSession.getPaymentMethods()  // receiving payment method list
    val savedAccounts = msdkSession.getSavedAccounts()   // receiving payment data list
    }
  8. Process the received data and display the payment form to the customer.
  9. To process a purchase via Google Pay, proceed as follows:
    • Receive a token from Google Pay, for this, the GooglePayHelper class can be used. Detailed information about setting up the application for the work with Google Pay is provided in the documentation.
      val googlePayHelper = GooglePayHelper("merchant Id")
      val googleJson = googlePayHelper.createPaymentDataRequest(BigDecimal.valueOf(12.34), "USD").toString()
      val gpayRequest = PaymentDataRequest.fromJson(googleJson)
       
      val client = Wallet.getPaymentsClient(
          this,
          Wallet.WalletOptions.Builder()
              .setEnvironment(WalletConstants.ENVIRONMENT_TEST)// test environment
              .setTheme(WalletConstants.THEME_LIGHT)
              .build()
      )
       
      AutoResolveHelper.resolveTask(
          client.loadPaymentData(gpayRequest),
          this,
          991
      )
    • Receive a token from Google Pay in the onActivityResult notification.
      override fun onActivityResult(requestCode: Int, resultCode: Int, data: Intent?) {
          super.onActivityResult(requestCode, resultCode, data)
          if (data == null) return
       
          val paymentData = PaymentData.getFromIntent(data)
          val paymentInformation = paymentData?.toJson() ?: return
          val paymentMethodData: JSONObject = JSONObject(paymentInformation).getJSONObject("paymentMethodData")
          val token = paymentMethodData.getJSONObject("tokenizationData").getString("token")
       
      }
  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
    interactor.execute(
                NewCardSaleRequest(          // scenario
                    cvv = "123",             // card verification value
                    pan = "5555555555554444",   // card number
                    year = 2025,             // card expiration year
                    month = 1,               // card expiration month
                    cardHolder = "John Doe"  // cardholder first and last name
                ),
                this
            )
     
    // purchase with the use of the Google Pay method
    interactor.execute(
                GooglePaySaleRequest(            // scenario
                    merchantId = merchant_321,   // merchant identifier
                    token = token,               // token received from Google Pay
                    environment = GooglePayEnvironment.TEST   // test environment
                ),
                this
            )
  11. Receive a range of notifications from SDK Core for Android—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 Android

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 Android 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 Android, 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 Android supports the capability of saving payment data on the customer's initiative and via tokenisation. 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 Android supports processing purchases (GooglePaySaleRequest) and placing holds on funds (GooglePayAuthRequest) by using the Google Pay method.

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

  1. Register in the Google Pay Business Console service and receive the merchant identifier in the Google Pay service (Google merchant ID).
  2. Accept and comply with the Acceptable Use Policy of Google Pay API and accept the Terms of Service of the Google Pay API.
  3. Embed the Google Pay button in the user interface following the brand guidelines and implement the process of receiving token with the customer card data from the Google Pay service.
  4. Add the following information to the AndroidManifest.xml file:
    <meta-data
        android:name="com.google.android.gms.wallet.api.enabled"
        android:value="true" />
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
  • merchantId (string)—merchant identifier in the Google Pay service (Google merchant ID)
  • token—token received from Google Pay
  • environment—environment (the test or the production one) in which the payment should be initiated (the possible values are: test and prod; if the test value is specified, the identifier of the merchant's test project should be used in the request; if the prod value is specified, the identifier of the merchant's production project should be used in the request)
  • recepientInfo (used for the scenario GooglePayAuthRequest)—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 Android, 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 via 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 Android 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 Android (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": "555555******4444",
  "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 Android. 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 Android 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 Android.

override fun onClarificationFields(clarificationFields: List<ClarificationField>, payment: Payment) { // receiving the list of the required parameters
    interactor.sendClarificationFields(clarificationFields) // sending the data obtained 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 Android, the merchant should display the fields to be filled by the customer in the payment form, send the obtained data to SDK Core for Android, and continue payment processing.

override fun onCustomerFields(customerFields: List<CustomerField>) {  // receiving the list of the required parameters
    interactor.sendCustomerFields(customFields) // sending the data received from the customer
}

Notification receipt

Informing about payment session

SDK Core for Android supports sending notifications with the payment session information. Intermediate notifications which are sent during 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.
    override fun onInitReceived() {
        val stringResourceManager = msdkSession.getStringResourceManager()
        val title = stringResourceManager.payment.methodsTitle
      
        val setSecureLogoResourceManager = msdkSession.getSecureLogoResourceManager()
        val visaIconUrl = setSecureLogoResourceManager.getLogoUrl("visa")
      
        val paymentMethods = msdkSession.getPaymentMethods()
        val savedAccounts = msdkSession.getSavedAccounts()
    }
  • onPaymentRestored—the payment session has been created with 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 fun onCreate(savedInstanceState: Bundle?) {
            super.onCreate(savedInstanceState)
            setContentView(R.layout.activity_payment_restore)
            progressDialog = ProgressDialog(this@PaymentRestoreActivity)
            progressDialog.setMessage("Payment restoring")
            progressDialog.setCancelable(false)
            progressDialog.show()
    
            interactor.execute(PaymentRestoreRequest(), this)
        }
  • 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 Android. Possible errors, their reasons, and actions recommended for the merchant in such cases are provided in the following table.

Error Possible reason 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 Android 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 Android was called Correct the request
SERVER_UNAUTHORIZED A connection error occurred Retry the request later