Getnet DocsGetnet Docs

Architecture

View as MarkdownView this page as plain textOpen in ChatGPTAsk questions about this pageOpen in ClaudeAsk questions about this pageOpen in PerplexityAsk questions about this page
Connect to CursorUse these docs in CursorConnect to VS CodeUse these docs in VS Code

This page explains the technical architecture of Get Mini App2App and how the components interact to process payment transactions.

App2App Architecture

Get Mini App2App uses an Intent-based architecture to enable communication between your application and the Get Mini app. Instead of implementing low-level EMV protocols or managing direct hardware connections, you delegate these tasks to the certified Get Mini app.

The communication flow follows a simple request-response pattern. Your application generates an Android Intent containing the operation data, the Get Mini application launches and manages the PIN pad interaction and banking host communication, then returns control to your application with the transaction results.

Components

The architecture consists of three main components that work together to process transactions.

Your Application

Your Android application is responsible for creating Intent requests with the appropriate action and parameters, launching the Get Mini application using Android’s Intent system, handling the response data returned after transactions complete, and displaying certified tickets while managing the user experience.

Get Mini Application

The Get Mini application handles all payment processing logic including managing communication with the PIN pad hardware, processing EMV transactions according to card brand specifications, communicating with the payment gateway and banking host, generating certified tickets, and returning transaction results to your application.

PIN pad Device

The PIN pad device is a certified hardware component that reads payment cards through chip, contactless, or magnetic stripe methods, captures cardholder PIN entries, and performs cryptographic operations required for secure transactions.

Communication Flow Diagram

Your application and the Get Mini app exchange data in a request-response pattern. Your app sends the operation. The Get Mini app drives the PIN pad and returns the result along the same path.

%%{init: {'theme':'base', 'themeVariables': { 'actorBkg':'#F6E9EA', 'actorBorder':'#A4262C', 'actorTextColor':'#1A1A1A', 'actorLineColor':'#BFBFBF', 'signalColor':'#4A4A4A', 'signalTextColor':'#1A1A1A', 'labelBoxBkgColor':'#FAF0F1', 'labelBoxBorderColor':'#A4262C', 'labelTextColor':'#1A1A1A' }}}%% sequenceDiagram participant App as Your App participant GetMini as Get Mini App participant Device as PIN pad App->>GetMini: Intent Request GetMini->>Device: Card read and PIN entry Device-->>GetMini: Encrypted card data GetMini-->>App: Result Callback

Certified Tickets (Boletas)

A critical component of this architecture is the handling of certified tickets. The Get Mini app generates a certified ticket (Boleta) validated by Get Mini. To ensure compliance with card brand requirements, your application receives a reference to this document (a URL or URI) rather than raw ticket data. You can then use this reference to display, share, or print the official certified ticket PDF.

Security Considerations

The App2App architecture provides significant security benefits. Payment card data never passes through your application, and all sensitive cryptographic operations are performed in the certified Get Mini app and PIN pad. Your application only receives transaction results and certified ticket references, keeping it outside of PCI DSS compliance scope.

Next Steps

Now that you understand the architecture, continue with:

  1. Prerequisites and Setup - Set up your development environment
  2. Quick Start: Your First Transaction - Process your first payment transaction
  3. Intent-Based Communication - Learn more about how Intents work in this integration