> 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/introduction/end-to-end-flow.md).
# End-to-End Flow
The SDK operates in **five key stages**. Understanding each stage is essential to ensure **a smooth integration, efficient troubleshooting, and a seamless payment experience**:
### The SDK Steps
{% stepper %}
{% step %}
### Terminal Initialization
The SDK performs a series of security checks to prepare the mobile device for a transaction. Errors at this stage are typically related to **device security**, with comprehensive verifications covering the **operating system status and hardware components**.\
\
**Responsible Parties:** Solution Developer and Product User.
{% endstep %}
{% step %}
### Session Initialization
After verifying the device's integrity, the application is validated through the **Google Play Integrity service**. This step ensures that the app remains **trusted** and was **downloaded from an authorized store** to process payments using our **Tap to Phone SDK**. Errors at this stage indicate **discrepancies between the declared information and the actual running code**. Once validated, the **transaction preparation process begins**.
**Responsible Parties:** Solution Developer and First Tech.
{% endstep %}
{% step %}
### Card Tap & Data Reading
The SDK is ready and waiting for the customer to **tap the card** and optionally **enter the PIN**. Potential errors at this stage may be related to:
* **Timeouts** when reading the card or digital wallet.
* **Security violations** in rendering the PIN entry screen.
* **Incorrect EMV tag configuration** for card data reading and transmission to the acquirer.
**Responsible Parties:** Solution Developer, SDK User, and First Tech.
{% endstep %}
{% step %}
### PIN Entry Device Generation
During card reading, with the transaction data already available, the SDK communicates with the **card chip** to determine whether **PIN entry is required**. If necessary, an **encrypted process** is triggered to generate a **secure digital PIN entry interface**, allowing the user to safely input their PIN.
It is important to note that this step is **optional** and depends on both the **transaction amount and the issuer's rules**. There is **no possibility of configuring parameters to force PIN entry**.
**Responsible Parties:** First Tech.
{% endstep %}
{% step %}
### Transaction Submission & Autorization
The transaction is sent to **backend services (outside the SDK)** and then forwarded to the **acquirer**, which is responsible for authorization.
Issues at this stage typically arise from:
* **Configuration mismatches** with the acquirer's authorization system.
* **Restrictions within the acquirer's ecosystem**.
In most cases, troubleshooting at this stage is the **acquirer's responsibility**. Once processing is complete, the SDK receives the **transaction response (approved or declined)** and forwards it to the application for display to the customer.
**Responsible Parties:** Acquirer and First Tech.
{% endstep %}
{% endstepper %}
### SDK Scopes
1. **The Device**
The SDK is included as a dependency within the application, which, during its operation, initiates a **contactless financial transaction**, either via a physical card or a digital wallet. In this context, the objectives are:
1. **Ensure that the application processes payments only in a secure environment**, free from security vulnerabilities, malicious software, or practices that compromise system integrity.
2. **Collect transaction data**, including the **amount, payment type (credit or debit), number of installments (if applicable), and metadata** for the backend. This metadata consists of **information that the application wishes to send along with the transaction and receive back as part of the approval or cancellation response**.
3. **Maintain a list of accepted products** and other **essential information** required to correctly interpret card data and relay it appropriately to the **acquirer**.
2. **Cloud-Based Contactless Kernel**
After ensuring the **operating system's security at the device level**, the SDK requests a series of instructions from the **Cloud Contactless Kernel** to:
1. **Verify if the application was downloaded from the Google Play Store**, ensuring it is **valid and authorized by the developer to operate with the First Tech TTP SDK**.
2. **Provide the SDK authentication credentials** to the **cloud-based contactless kernel**, ensuring that the SDK is **running a valid and active version**.
3. **Process transactions by encrypting card data and PINs** according to the security standards defined by **Visa Security 1.8.1 and MPOC**.
3. **First Tech Cloud**
This layer acts as the **processing core of the TTP SDK**, responsible for:
1. **Updating and providing the SDK with a unified acquirer-specific table**, containing the necessary **card reading parameters** and the appropriate **data exchange interpretations for both physical cards and digital wallets**.
2. **Receiving encrypted transactions and re-encrypting them in a secure environment**, following standards accepted by acquirers. In **Brazil**, these standards often differ from international **TTP technology protocols**, covering both **card data (number and expiration date) and PIN data**.
3. **Routing transactions to the acquirer's native authorization environment**, performing **necessary field conversions and providing external feedback** to the SDK on the transaction status. This layer also enables **transaction recovery** in cases of **power or network failure**, restoring the **device state** when needed.
4. **Authorizer**
This is the **acquirer's environment**, responsible for **receiving the transaction from the First Tech Cloud layer, executing the necessary operations to approve or decline the transaction, and returning the response**. This information is then sent **back to the First Tech Cloud layer, which forwards it to the contactless kernel layer, and finally, to the device layer**.
This layer has the following responsibilities:
1. **Processing the transaction request** based on **anti-fraud rules, card network policies, and issuer requirements**, utilizing its **product and service ecosystem**.
2. **Returning the final transaction status**, along with the **receipt and any additional details**, allowing the SDK to **relay this information to the application and manage the transaction lifecycle**.
### Roles & Stakeholders
The process involves **multiple participants**, each with specific responsibilities to ensure the **proper operation of the payment flow**:
* **Solution Developer**
Responsible for **integrating the First Tech SDK** into their applications. This role includes:
* **Registering the company with acquirers** and **developing the software** according to **security guidelines and First Tech documentation**.
* **Ensuring the application remains updated** with the latest SDK versions and other technical requirements.
* **Providing a seamless and reliable user experience**.
* **Conducting extensive testing** to guarantee **security and performance**.
* **Implementing logging and auditing mechanisms** for **business and payment transaction tracking.**
* **First Tech**
Responsible for the **development, maintenance, and continuous updates** of the SDK, ensuring that it remains **certified and compliant** with industry **security and regulatory standards**. First Tech also:
* **Incorporates new features** into the SDK.
* **Maintains cloud services with high availability**.
* **Performs proactive monitoring** to prevent failures.
* **Provides technical support** to both developers and acquirers.
* **Delivers educational materials**, such as tutorials and manuals, to assist in the efficient use of the solution.
* **Acquirer**
The **company that processes and authorizes transactions**. In some cases, the acquirer also **redistributes the SDK** as a **white-label** solution for other companies. Its responsibilities include:
* **Providing Level 1 support** to developers when redistributing the SDK.
* **Ensuring transactions are processed in a resilient environment**.
* **Investing in advanced anti-fraud solutions**.
* **Managing integrations** with other players in the ecosystem, such as **issuers and card networks**, ensuring regulatory compliance.
* **Merchant (Business/Store)**
The **point of sale or business** that **uses the solution** to accept payments. Their responsibilities include:
* **Operating the application correctly**.
* **Ensuring that devices are properly configured** according to technical requirements.
* **Providing support to end users** during the payment process.
* **Training staff** to use the system properly.
* **Regularly checking** the condition of mobile devices.
* **Solution User (Customer)**
These are the **customers making payments** using **cards or digital wallets**. They are responsible for:
* **Correctly positioning their cards and NFC-enabled devices** on the readers at the right time and place.
* **Entering the PIN correctly**, if required.
* **Ensuring their cards are valid** and have **sufficient balance or credit limit**.
---
# 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/introduction/end-to-end-flow.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.