> For the complete documentation index, see [llms.txt](https://ftcoders.first-tech.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ftcoders.first-tech.com/first-tech-ttp-sdk/developer-zone/troubleshooting-during-testing-and-production.md). # Troubleshooting During Testing and Production The errors listed below typically occur during the **Proof of Concept (POC) process**, the **initial integration attempts**, or the **deployment of the SDK** in **staging and production environments**. For each **transaction process stage**, we will present the **most common errors**, along with a **structured troubleshooting path** and the necessary **checks for each situation**. This **systematic approach** facilitates the **identification and resolution of issues**, ensuring a **smoother transition** between the **development, staging, and production** phases. ### **How to Activate the Terminal** Terminal activation, as discussed in previous sections, is a **critical step** that requires compliance with **specific prerequisites** in the **production environment** of the **Android operating system**. During the **terminal creation process**, if these prerequisites are **not met**, the SDK will return an **error from the** `TerminalInitializingErrorViewData` **class**, with the description **`DEVICE_STATE_FAILED`**, indicating that the activation was **unsuccessful**. Below, we outline the **main reasons** that may cause this failure. #### **1. Required Permissions to Operate the SDK within the Application** Initially, it is necessary to verify if the application has access to the following Android permissions:
FeaturePermission
NFCandroid.Manifest.permission.NFC
Vibrateandroid.Manifest.permission.VIBRATE
Internetandroid.permission.INTERNET
Network Stateandroid.permission.ACCESS_NETWORK_STATE
Access Notification Policyandroid.permission.ACCESS_NOTIFICATION_POLICY
Accurate Locationandroid.permission.ACCESS_FINE_LOCATION
Approximate Locationandroid.permission.ACCESS_COARSE_LOCATION
To verify if the permissions have been requested, open the **AndroidManifest.xml** file, which should be accessed by the **Android project developer**. In this file, some permissions are **automatically configured**, while others need to be **explicitly declared** according to **Android's security policy**. Additionally, you can request a **screenshot from the developer** to confirm the permissions directly on the device.

Figure 23: Screenshot of the AndroidManifest.xml File from a React Native Project Using the TTP SDK

Even if the permissions are implemented in the application, in the **production environment** (when the app is downloaded from the store), **Android will request user confirmation** to access certain features, such as the **camera** or **microphone**. It is essential to **verify** whether the application has made these requests and if the **user has granted permission** for these features. If there are any doubts regarding **permission grants**, recommend **reinstalling the application**. This will allow the necessary steps to be repeated, ensuring that **permissions**, such as **microphone** and **NFC**, are **requested and granted** at the appropriate time. *** 2. **Root Mode** If the **superuser** is logged in and enabled on Android, the **SDK will not be able to complete the terminal creation phase**, either in **staging** or **production**. To check if the device is in **root mode**, follow a process similar to the one described in **Section 2** for **log collection**: 1. **Ask the application developer** to configure the **build variants** in **Android Studio** for the **staging environment (hml)** while using the **staging SDK**. 2. With the project open in **Android Studio**, **access the console window** by pressing **Alt + F12**. * If the developer is unfamiliar with **build variants**, recommend reading **Section 4: Environment Preparation to Get Started**. 3. **Connect the mobile device** to the computer using a **USB cable** and enter the following command: ``` adb shell ``` Next, check if it is possible to access the **Android superuser** on the mobile device: ``` su ``` If the device **requests permission** or **switches to superuser (root) mode**, it indicates that **root access is enabled**. On the other hand, if the command returns a message like **"command not found"**, the device **does not have root access**. *** 3. **Developer Mode** **Developer mode** is **allowed only for the staging SDK**, but **not for the production SDK**. If you are in **production** and encounter the **`DEVICE_STATE_FAILURE`** error during the **terminal creation step**, you must **disable developer mode** on the **Android device** where the application is installed. #### **To disable developer mode, follow these steps:** 1. Open the **Settings menu** on Android and look for **Developer Options** or **Programmer Options**, depending on the device model and Android version. 2. If this submenu is **not found**, it means that **developer mode has never been enabled**. #### **To confirm if developer mode is active:** 1. Go to the **About Phone** submenu in the **Settings menu**. 2. Tap **seven times** on the **Build Number** field. After this, Android will display a message confirming that **Developer Options have been enabled**. 3. Open the newly created **Developer Options menu** and **disable developer mode**. This action will ensure that the device is properly configured for the **production environment**. *** 4. **Potentially Malicious Applications** Another reason for the **`DEVICE_STATE_FAILURE`** error during the **terminal creation phase** is the presence of **applications that can monitor data exchange between apps, enable root mode, or collect sensitive data**, compromising the **security of payment data read via NFC**. This verification takes place in **both staging and production modes**. Below is a list of **known applications** that may cause this error (**not limited to these, as variations with similar effects may exist**): * Magisk * Frida * Cydia Substrate * SuperSU * Xposed If any of these applications are found on the device, we **strongly recommend** performing a **factory reset**. This ensures that **tests are restarted in a clean environment**, preventing **potential residual interference** with the integrity of the **operating system**, even after these applications have been removed. *** 5. **Apps Installed Outside the Store** In the **production environment**, applications installed **outside the official store** may be flagged by **Play Integrity**, marking the **device as unsafe for transactions**. If there is suspicion of such apps, **uninstall them** and **attempt to create the terminal again**. The **SDK continuously performs security checks** to ensure that the **device is always classified as safe**, maintaining the **integrity and security of transactions**. #### **Other less complex issues** returned by the `TerminalInitializingErrorViewData` view during the **initialization phase** may include: | Error Returned by the View | Cause | Solution | | --------------------------------- | ---------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | UNSUPPORTED\_ANDROID\_OS\_VERSION |

The Android version on the device is not supported by the SDK.

|

Request a screenshot of the Android version on the device and verify whether it meets the minimum specifications described in this document.

Additionally, if possible, guide the customer to update the Android version. This option is more feasible for recent models or devices that have been restored to factory settings.

If the customer is unsure how to find this option, ask for the device model and provide instructions. While names and descriptions may vary, the Android version is usually found in the About submenu within the device's Settings app.

| | NETWORK\_CONNECTION\_ERROR | The device has no internet access during the terminal creation process. |

Ask the device holder to open a browser and access any website or use a speed test tool to check the connection quality.

Ideally, high-speed and low-latency networks should always be used, preferably by connecting to a reliable Wi-Fi network whenever possible.

| | TERMINAL\_NOT\_INITIALISED\_YET |

Internal SDK failure.

|

This is an internal product failure that currently has no mitigation procedure.

It is recommended to open a ticket with First Tech, attaching the collected logs for immediate investigation.

| | INTERNAL\_ERROR | Generic internal SDK error. |

This is an internal product failure that currently has no available mitigation procedure.

The error includes additional details in the exception field, which will be analyzed by the First Tech team.

It is recommended to open a ticket with First Tech, attaching the collected logs for immediate investigation.

| ### **How to Activate the Session** After **successfully completing** the **terminal integrity verification process**, the next step is **session creation**. At this stage, the **application is validated** based on its **credentials and certificates** in **Google Play**. If no issues are detected, the **SDK will proceed to the card request process**. The most common issues in this phase generally fall into **two categories**: 1. **Failure in Retrieving Application Data from the Store:** * #### The **developer must ensure** that all required information is **available and up to date**. 2. #### **Version Update Without Communication:** * #### When a **new version** of the application is published in the store, the **developer must officially request** the **release of this version in production** with **First Tech**. * #### This process ensures **authorized SDK usage control** on customer devices #### **To release the version, a support ticket must be opened with the following three essential details:** * **SHA-256 certificate fingerprint** * **Package Name** * **Version Code** #### **SHA-256 - Application Signing Certificate Fingerprint** The **SHA-256** is a **unique fingerprint** generated by the **application signing certificate** in **Google Play**. It is **public** and used to **authenticate the application**, ensuring its **exclusivity**. **First Tech requires this data only the first time** the application is distributed in the store. The **SHA-256 generation process** is managed by **Google** and involves several steps, which can be found in the **official documentation**. **To provide the required value, follow these steps:** * **Access the Google Play Console settings menu** ([**more details here**](https://support.google.com/googleplay/android-developer/answer/9842756?hl=pt-br)). * Navigate to **Setup > App Integrity > App Signing Key Certificate > SHA-256 Certificate Fingerprint**. * **Copy the displayed hexadecimal value** and **send it to First Tech**. This step is **essential** to **validate the integration** and allow the **authorized use of the SDK**.

Figure 24: App Integrity Configuration Screen within the Google Portal where the SHA-256 Certificate Fingerprint can be viewed

Exemplo de SHA-256 certificate Fingerprint ``` BD : 92 : 64 : B0 : 1A : B9 : 08 : 08 : FC : FE : 7F : 94 : B2 ``` #### **Package Name - Unique Identification Name of the Android Application** The **Package Name** is the **unique identifier** for an Android application, used to differentiate it from other apps installed on the device. This **naming convention** prevents conflicts between applications and is essential for both **system functionality** and **software testing**, whether manual or automated. Although the **Package Name** is automatically assigned when the app is submitted to Android, it can be **changed if necessary**. The format typically follows the pattern:\ **com.yourdomain.appname**. For example, if the developer's website is **meusite.com** and the app is called **MeuApp**, the **Package Name** could be **com.meusite.meuapp**. #### **How to locate the Package Name:** Ask the developer to access the **build.gradle** file of the app module. Inside the **defaultConfig** object, locate the **applicationId** variable, which will contain the **Package Name**. This value will be **unique** for each supported app. This information is **essential** for the **correct integration with the SDK** and for **accurately identifying the app** in the store and on devices.

Figure 25: Example app with the Build.Gradle file open and the applicationId variable highlighted

#### **Version Codes - Application Version Identification** The **Version Code** represents the version of the application and is used by **First Tech** to identify which product versions are valid for the **Tap to Phone SDK** during the **session creation phase**. This parameter is **cumulative**, meaning all valid versions must be sent, allowing multiple versions to be active simultaneously. #### **Important Notes about Version Code:** * The list of valid versions must include **all corresponding strings**, as only the **latest version** provided will be considered as the reference. * Clients can submit **future versions**, allowing app updates to be performed without the need to immediately open new support tickets. * It is a good practice to **notify First Tech** when older versions are no longer valid. This prevents transactions on those versions and forces end users to update the app, ensuring **greater security and compatibility**. **How to Identify the Version Code:** Follow the same procedure used to locate the **Package Name**, but look for the **versionCode** variable inside the **defaultConfig** object in the **build.gradle** file of the app module. Ensuring the correct submission of this information is **essential for secure and efficient operation**.

Figure 26: Example React Native app with the Build.Gradle file open and the versionCode variable displayed

**Example of Sending Data by Email to Enable Version in Production** > Dear First Tech Team, good morning! > > Could you please enable our app in production?\ > Here are the details: > > **SHA-256 of the app on the store:** BD : 92 : 64 : B0 : 1A : B9 : 08 : 08 : FC : FE : 7F : 94 : B2\ > **Package Name of the app:** com.notke.paymentapp\ > **Version Codes:** 20, 21, 22, 23, 24, and 25 For **Tap to Phone SDK versions** above **1.0.20**, the **application registration process** in production will return to the developer **three fields** that should be used **exclusively in the production environment**. These fields should be added in the SDK call within the **StartPayment** method. The variables are: {% code lineNumbers="true" %} ``` Client Id Cliente Secret Scope ``` {% endcode %} These variables must be included in the call along with the **CPF**, **CNPJ**, **Customer ID**, and other information that the SDK already requests from customers. They are **essential** to complete the **session creation process** and allow progression to the following steps. Additional details about these variables can be found in the **technical specifications** intended for the developer. If this step is not performed correctly, the **TerminalSessionCreatedErrorViewData** view will display the **DEVICE\_STATE\_FAILURE** error, which is the most common issue encountered during the **session activation** phase. Other minor and rarer issues may also occur during the **session activation process**. Below, we list these issues along with their possible solutions: | Error Returned by the View | Cause | Solution | | ---------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | INTERNAL\_ERROR | Generic Internal SDK Error |

This is an internal product failure that currently has no available mitigation procedure.

The error contains additional details in the exception field, which will be analyzed by the First Tech team. It is recommended to open a support ticket with First Tech, attaching the collected logs, to enable immediate investigation.

| | DEACTIVATED | The terminal was deactivated during the session creation process. |

This may occur due to a manual action taken by the acquirer, by First Tech in cases of suspected fraud, or at the merchant's request.

The customer should restart the application to attempt creating a new terminal. If the error persists, there may be an issue with the SDK, and it is recommended to open a support ticket for the First Tech team to investigate the cause.

| | CONFIGURATION\_VALIDATION\_HASH\_FAILURE | The EMV configuration file (known as EMV Config) has been invalidated for security reasons or is being updated by the First Tech team for all users of the client's application. |

The EMV configuration file defines the types of products and cards recognized during the TTP reading phase. Its update is automatically checked with each new transaction, and if necessary, it will be performed at that time.

Advise the customer to wait a few minutes and try the transaction again. If the error persists, open a support ticket for the First Tech team to investigate the issue immediately.

| | NFC\_ERROR | The NFC has been requested by another application for use or has been disabled on Android. | Ask the customer to **close all applications**, check if **NFC is enabled** on the Android device, and confirm if the device **supports NFC**. Once these issues are addressed, try performing the operation again. | | NETWORK\_ERROR | The app has no internet access or there was a failure in the back-end server. |

Guide the device holder to open a browser and access any website or use a speed test tool to check the connection quality.

Whenever possible, use high-speed and low-latency networks, preferably by connecting to a reliable Wi-Fi network.

If the problem persists even with internet connectivity, it is likely that the issue lies with the back-end. In this case, it is recommended to open a support ticket for First Tech to investigate the cause.

| ### **Bringing the Card Close and Starting the Transaction** If the terminal and session are successfully activated, the device will be ready to perform the **card proximity**. To avoid issues, it is recommended to refer to **Section 7: Troubleshooting During Testing and Production** for best practices on handling the device, ensuring that the application does not experience **read timeouts** caused by improper card positioning or difficulties with the NFC reader within the time allowed for the operation. Additionally, other important factors include: * **Stable network:** Ensure that the connection is reliable to prevent interruptions. * **Valid card:** Use an **active card**, not expired, with available balance or limit, and with the **proximity payment function** activated. * **Correct card mode:** Some **neobanks** have inverted debit and credit functions. For example, using a debit card as credit may result in the error "**No application selector for the card**". Another point of attention is during the **programming phase**. Ensure that the **PaymentType enums** are correctly configured, as **reversed values** can lead to similar failures. A **rarer, but possible situation** is the **difficulty in reading newer or less common cards** due to the absence of **Application IDs** in the **SDK database**. This problem may also generate the error "**No application selector for the card**." In this case, it will be necessary to **open a ticket** so that **First Tech**, in collaboration with the **acquirer**, can review the tables responsible for recognizing the card and implement the necessary updates. The **SDK will be automatically updated**, with no action required from the developer, on the next transaction attempt. At this point, the errors displayed in the **TerminalPaymentErrorViewData** view may have two distinct origins: * **Errors related to the SDK.** * **Errors related to authorization.** Here are the common errors related to the SDK and their possible solutions: | Error Returned by the View | Cause | Solution | | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | NETWORK\_CONNECTION\_ERROR | The device has no internet access during the terminal creation process. |

Ask the device holder to open a browser and access any website or use a speed test tool to check the connection quality.

Ideally, always use high-speed and low-latency networks, preferably by connecting to a reliable Wi-Fi network whenever possible.

| | MICROPHONE\_USAGE\_DETECTED | Another app or process is using the microphone hardware. | The microphone needs to be **blocked** during the use of apps that might potentially be using the resource. **Close all programs** and reopen the app for a new attempt. | |

CAMERA\_USAGE\_DETECTED

EXTERNAL\_CAMERA\_DETECTED

| Another app or process is using the front or external camera hardware of the phone. | The cameras need to be **blocked** during the use of apps that might potentially be using the resource. **Close all programs** and reopen the app for a new attempt. | | TOTAL\_ELAPSED\_TIMEOUT |

The total operation time from card reading to transaction approval has been exceeded.

|

The SDK is configured for a total transaction time of 60 seconds in these stages, and this time is set directly by First Tech in the EMV Config files, which are verified and updated with each transaction. This is a more than reasonable time to complete the entire process. This error appears when there has been no interaction from the customer to bring the card close, or the transaction authorization time is too long.

We recommend opening a support ticket with First Tech, including a video recording of the app's behavior to better understand the cause.

| | DISCOVERY\_TIMEOUT | The designated time for card reading has expired. |

This problem may be caused by an issue with device handling or difficulty in reading the card, which may be damaged or invalid.

We recommend the following:

  1. Test the same app on another device.
  2. Test the same device with a different card, preferably from the same network and in the same mode (debit/credit).
| |

PIN\_ENTRY\_ACCUMULATED\_TIMEOUT

PIN\_ENTRY\_TIMEOUT

| The time for displaying the PIN screen and entering the password has expired. |

The PIN screen is presented through a cryptographic process for its generation between the SDK and the back-end. In addition to this time, there is also the time it takes for the user to enter the card PIN. The combination of these two times may cause this error.

Test the transaction again to check if the behavior persists. If the issue occurs every two or three interactions, it may be necessary to increase the time for PIN entry or there might be a cryptographic error on the back-end. In this case, open a support ticket for First Tech to investigate.

| | AUTHORIZATION\_IN\_PROGRESS\_TIMEOUT |

The transaction cannot be authorized within the maximum time set for transaction authorization.

|

There is a delay greater than expected between the SDK back-end and the Acquirer.

If the client has access to the panel with their transactions, it is helpful to check if the transaction was registered and is awaiting confirmation.

If there is no visibility within the acquirer context, it is likely that there was a problem in the SDK back-end in sending this message. In this case, open a ticket with First Tech, including the transaction evidence that is available.

| | INTERNAL\_ERROR | Generic internal SDK error. |

This is an internal product failure that currently has no available mitigation procedure.
The error contains additional details in the exception field, which will be analyzed by the First Tech team.
It is recommended to open a support ticket with First Tech, attaching the collected logs, to enable immediate investigation.

| | HOST\_CALLBACK\_ERROR |

The SDK is not receiving the approved or denied transaction response from the back-end.

|

The Acquirer and First Tech need to verify the issue together.

If the transaction is indeed waiting for approval and there has been no response, the issue needs to be investigated with the acquirer by opening a specific support ticket.

If the transaction can be tracked on the acquirer’s console and already has a confirmed or denied status, then it is necessary to open a ticket with First Tech.

| | PIN\_PAD\_OBSCURED\_ERROR | An app with "appear on top of other apps" permission interfered with the PIN entry screen when it appeared. | Find the app with this behavior and **uninstall it** or **temporarily remove this permission**. Then, **close the app** and **open it again** to perform the transaction. | | PIN\_PAD\_DETACHED\_ERROR | The PIN screen process was manually closed on Android. | Close and reopen the app, then repeat the transaction. If the error persists, try to identify apps that might be causing this behavior. If that's not the case, **open a ticket with First Tech** to report the issue. | | PIN\_PAD\_LAUNCH\_TIMEOUT | The PIN screen took more than 2 seconds to display. | Try a new transaction. If the issue persists, **open a ticket with First Tech** to report the problem. | | NFC\_ERROR | NFC has been requested by another app for use or has been disabled on Android. | Ask the customer to **close all applications**, check if **NFC is enabled** on the Android device, and confirm if the device **supports NFC**. Once these issues are resolved, try performing the operation again. | The transaction can also be **denied due to authorization failures** with the acquirer. This is related to **card failures**, **fraud prevention rules**, **password issues**, and the **availability of the payment ecosystem**: authorization services from card networks, acquirer availability, and others. The returned errors are aligned with **ABECS Normative 21**, which can be found [here ](https://api.abecs.org.br/wp-content/uploads/2019/09/Normativo-021.pdf)for issues with the acquirer. It is important that these returns are displayed to customers, mimicking the behavior of a **common POS**, and providing visibility into errors that may or may not be retried. This helps protect the **merchant** from being charged fees for **misuse of authorization attempts** by the acquirer through the card networks (Visa, Mastercard, and Elo). To verify these errors, in addition to the response in the **TerminalPaymentSuccessViewData** and **TerminalPaymentErrorViewData** views, respectively for transaction approvals and denials, the **meta field** will return an object with the details of this transaction from the **acquirer side**, indicating the authorization processing. **Example of the Meta Field Filled if the Transaction is Denied** ```json { "providerResponse": { "mti": "2210", "processingCode": "002000", "amount": "9862000000000041", "transmitionDateTime": "20250123133118", "stan": "842379", "transactionDateTime": "20250123133117", "authorizerId": "16", "muxipayResponseCode": "8001", "authorizerResponseCode": "05", "terminalId": "00000007", "merchantId": "00595154000173", "emvTags": "8a023035", "customerId": "FIRSTTECH", "displayCustomerMessage": "TRANSACAO NEGADA\nCONTATE A\nCENTRAL DO SEU\nCARTAO", "trackingNumber": "020001419451", "muxipayUniversalId": "00ad54c01b8d064501e1ec6b34df8eac", "initializationRequired": "10", "hostStan": "000725", "error": { "code": "invalid operation", "message": "Error occurred on authorize message", "metadata": { "acquirer": "rejected", "authorizer": "do_not_honour" } } }, "error": { "type": "acquirer", "code": "invalid operation", "message": "Error occurred on authorize message", "metadata": { "acquirer": "rejected", "authorizer": "do_not_honour" } }, "status": "COMPLETED_WITH_ERROR", "reason": "OPERATION_ERROR" } ``` **Example of the Meta Field Filled if the Transaction is Authorized** ```json { "mti": "2210", "muxipayUniversalId": "67bea6f89c319638f35e2b9273739df5", "receipt": { "merchant": { "message": "DOCK - Via Loja\n\nFIRST CUSTOMER\nCNPJ: 10179118609\nTID: 020001419130\n\n*** *** **** 5461\nMASTERCARD\nAID: A0000000041010\n23/01/25 13:04\nCV: 855614\nValor: R$ 0,23\nForma de pagamento: Crédito\nÀ vista\nTerm: 00000486\n\nDADOS ORIGINAIS DA VENDA\nValor: R$ 0,23\nTerm: 00000486\nTransação autorizada pelo emissor\n" }, "customer": { "message": "DOCK - Via Cliente\n\nFIRST CUSTOMER\nCNPJ: 10179118609\nTID: 020001419130\n\n*** *** **** 5461\nMASTERCARD\nAID: A0000000041010\n23/01/25 13:04\nCV: 855614\nValor: R$ 0,23\nForma de pagamento: Crédito\nÀ vista\nTerm: 00000486\n\nDADOS ORIGINAIS DA VENDA\nValor: R$ 0,23\nTerm: 00000486\nTransação autorizada pelo emissor\n" } }, "displayMessages": { "customer": "TRANSACAO APROVADA" }, "providerResponse": { "mti": "2210", "processingCode": "003000", "amount": "9862000000000023", "transmitionDateTime": "20250123130431", "stan": "855614", "transactionDateTime": "20250123130429", "authorizerId": "16", "retrievalReferenceNumber": "020001419130", "authorizationCode": "043063", "muxipayResponseCode": "8000", "authorizerResponseCode": "00", "terminalId": "00000486", "merchantId": "10179118609", "emvTags": "8a023030", "customerId": "BIPPAGAMENTOS", "displayCustomerMessage": "TRANSACAO APROVADA", "trackingNumber": "020001419130", "muxipayUniversalId": "67bea6f89c319638f35e2b9273739df5", "initializationRequired": "10", "hostStan": "000012" }, "status": "COMPLETED_SUCCESSFULLY", "reason": "COMPLETED_SUCCESSFULLY" } ``` --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://ftcoders.first-tech.com/first-tech-ttp-sdk/developer-zone/troubleshooting-during-testing-and-production.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.