{"title":"Understand the Android Mobile solutions","category":"default","creationDate":1759757460,"content":"<p>This page explains various concepts that our Mobile solutions are based on, and provides information to help you choose which Mobile solution to build. You can choose to:<\/p>\n<ul>\n<li>Integrate our Mobile SDK into your POS app, to accept Tap to Pay and\/or card reader payments.<\/li>\n<li>Let your POS app communicate with an Adyen Payments app that already includes the Mobile SDK, to accept Tap to Pay payments.<\/li>\n<\/ul>\n<h2 id=\"sdk-or-papp\">SDK or Payments app<\/h2>\n<p>Both when integrating the Mobile SDK and when using the Payments app, your POS app must be integrated with <a href=\"\/pt\/point-of-sale\/design-your-integration\/terminal-api#api-structure\">Terminal API<\/a>. And in both cases you have to work on the backend as well as on the frontend.<\/p>\n<p>It depends on your use case and development capacity which solution is the most suitable. You may prefer a low-code integration without PCI Mobile Payments on COTS (MPoC) compliance requirements, or a more involved integration that allows more control of the app experience.<\/p>\n<p>Also note that the same Mobile SDK is used for Tap to Pay and card reader payments. If your POS app allows selecting the payment interface, both solutions can be used alongside each other. The Payments app on the other hand only supports Tap to Pay.<\/p>\n<p>The following table shows the pros and cons of each solution.<\/p>\n<table>\n<thead>\n<tr>\n<th style=\"text-align: left;\">Mobile SDK<\/th>\n<th style=\"text-align: left;\">Payments app<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td style=\"text-align: left;\"><strong>Pros<\/strong><\/td>\n<td style=\"text-align: left;\"><strong>Pros<\/strong><\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: left;\">Full control of the in-app experience<\/td>\n<td style=\"text-align: left;\">Lower integration effort (Links &amp; API)<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: left;\">Better UX: no app switching<\/td>\n<td style=\"text-align: left;\">Adyen handles updates<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: left;\">Better payment performance<\/td>\n<td style=\"text-align: left;\">No PCI MPoC compliance requirements<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: left;\">Supports Tap to Pay and card reader<\/td>\n<td style=\"text-align: left;\"><\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: left;\"><strong>Cons<\/strong><\/td>\n<td style=\"text-align: left;\"><strong>Cons<\/strong><\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: left;\">Update SDK version every six months<\/td>\n<td style=\"text-align: left;\">Payments app must be boarded on each device<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: left;\"><a href=\"\/pt\/point-of-sale\/mobile-android\/security#pci-dss-compliance-requirements\">PCI MPoC compliance requirements<\/a><\/td>\n<td style=\"text-align: left;\">App switching during the payment flow<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: left;\"><\/td>\n<td style=\"text-align: left;\">Only supports Tap to Pay<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h2 id=\"session\">Communication session<\/h2>\n<p>When you integrate the Mobile SDK into your POS app, the SDK has to communicate in a secure way with the plataforma de pagamentos da Adyen. To enable this, you must integrate a server-to-server POST  <a href=\"https:\/\/docs.adyen.com\/api-explorer\/possdk\/latest\/post\/sessions\" class=\"codeLabel  external-link no-image\" target=\"_blank\" rel=\"nofollow noopener noreferrer\">\/checkout\/possdk\/v68\/sessions<\/a> request to create a session. Your POS app needs to call your backend to trigger this request and get the session data.<\/p>\n<p>The SDK uses the session data from the response to authenticate with our payments platform. Because the session expires after some time, the SDK checks regularly if it needs to establish a new session.<\/p>\n<div class=\"hint--right\" data-hint=\"Establishing a session in the payment flow\">\n<p><img alt=\"\" src=\"\/user\/pages\/reuse\/pos-mobile-sdk\/communication-session\/ipp-mobile-authentication-flow.svg?decoding=auto&amp;fetchpriority=auto\" \/><\/p>\n<\/div>\n<h2>SDK transaction flow<\/h2>\n<p>If you use or build a Mobile solution where our Mobile SDK for Android is integrated into your POS app, transactions take place as follows:<\/p>\n<ol>\n<li>\n<p>Optional but recommended: your POS app calls a warm-up function to speed up initiating transactions. <\/p>\n<\/li>\n<li>\n<p>Your POS app creates a Terminal API request that is serialized to JSON, or receives the Terminal API payment request from your backend.<\/p>\n<\/li>\n<li>\n<p>The POS app passes the Terminal API request to the Mobile SDK.<\/p>\n<\/li>\n<li>\n<p>The SDK checks if the communication session is still valid, and if necessary establishes a new session.<\/p>\n<\/li>\n<li>\n<p>The transaction starts on the mobile device.<\/p>\n<\/li>\n<li>\n<p>The SDK passes the Terminal API response to your POS app.<\/p>\n<\/li>\n<\/ol>\n<div class=\"hint--right\" data-hint=\"Payment flow\">\n<p><img alt=\"\" src=\"\/user\/pages\/reuse\/pos-mobile-sdk\/sdk-flow\/ipp-mobile-sdk-flow-ios.svg?decoding=auto&amp;fetchpriority=auto\" \/><\/p>\n<\/div>\n<h2>Payments app transaction flow<\/h2>\n<p>If you use or build a Mobile solution where your POS app communicates with the Adyen Payments app, transactions take place as follows:<\/p>\n<ol>\n<li>Your POS app creates a Terminal API payment request, or receives a Terminal API payment request from your backend.<\/li>\n<li>Your POS app sends an encrypted, Base64URL-encoded Terminal API payment request to the Payments app as an App Link with your return URL.<\/li>\n<li>On the mobile device, a Tap to Pay screen appears, and the shopper presents their contactless payment method to the NFC reader of the device.<\/li>\n<li>The Payments app routes the payment request through our POS Mobile SDK to the Adyen backend.<\/li>\n<li>The Adyen backend returns an encrypted, Base64URL-encoded Terminal API payment response to the Payments app.<\/li>\n<li>On the mobile device, the screen shows the outcome, and switches to your POS app using the return URL you specified.<\/li>\n<li>Your POS app receives the encrypted, Base64URL-encoded Terminal API payment response.<\/li>\n<\/ol>\n<h2>PIN transactions<\/h2>\n<p>It is possible to make PIN transactions in your Tap to Pay and card reader solution. Unlike traditional payment terminals with physical keypads, PIN entry on a mobile device requires specialized security measures to protect the shopper's data. To comply with <a href=\"\/pt\/point-of-sale\/mobile-android\/security\/#pci-mpoc-compliance-requirements\">PCI MPoC compliance requirements<\/a>, the PIN entry pad is not always centered on the mobile device screen. Instead, it appears in a random position as shown in the following examples. <\/p>\n<table>\n<thead>\n<tr>\n<th style=\"text-align: center;\"><\/th>\n<th style=\"text-align: center;\"><\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td style=\"text-align: center;\">Bottom-left <br> <img alt=\"\" src=\"\/images\/0\/a\/1\/2\/6\/0a126dc999bdfc25bb7716739046edc544866a07-screen-enpin-pad-centered.png\" \/><\/td>\n<td style=\"text-align: center;\">Top-right <br> <img alt=\"\" src=\"\/images\/5\/4\/2\/9\/e\/5429e83cc2c07ff455d667848a990a152432ef1e-screen-enpin-pad-random.png\" \/><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3>PIN transaction with a card reader in the US<\/h3>\n<p>You need an NYC1 card reader with PIN support <a href=\"\/pt\/point-of-sale\/mobile-android\/requirements#card-readers\">for secure PIN transactions<\/a>.<\/p>\n<div class=\"notices green\">\n<p>NYC1 card readers with PIN support require Mobile SDK version 2.4.0 or later.<\/p>\n<\/div>\n<p>In the US, not all NYC1 card readers support PIN. You can check if your card reader supports PIN transactions in the following ways:<\/p>\n<ul>\n<li>By checking the [<code>connectedDevice.model<\/code>] . Returns the model of the card reader. The result can be: <ul><li markdown=\"1\"><strong>SCRP<\/strong> (card reader supports PIN).<\/li> <li markdown=\"1\"><strong>SCR<\/strong> (card reader does not support PIN).<\/li><\/ul><\/li>\n<li>\n<p>In the <a href=\"\/pt\/point-of-sale\/mobile-android\/understand#ui-for-card-reader-operations\">built-in UI<\/a>: If under <strong>Device Info<\/strong> the field <strong>Model<\/strong> is present, you have an NYC1-SCR card reader that does not support PIN. If the field <strong>Model<\/strong> is not present, you have an NYC1 that supports PIN.<\/p>\n<table>\n<thead>\n<tr>\n<th style=\"text-align: center;\">Device info for NYC1-SCR<\/th>\n<th style=\"text-align: center;\">Device info for NYC1<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td style=\"text-align: center;\">Card reader not suitable for PIN  <br> <img alt=\"\" src=\"\/images\/7\/0\/4\/e\/a\/704eaf602ae63805689a0f24d7740513c90be70b-screen-enandroid-scr.png\" \/><\/td>\n<td style=\"text-align: center;\">Card reader suitable for PIN <br> <img alt=\"\" src=\"\/images\/b\/2\/3\/5\/a\/b235a7e22f197ae2b22f4ebe9232d77f02d0340c-screen-enandroid-scrp.png\" \/><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/li>\n<\/ul>\n<p>If you want to disable PIN support on your NYC1 card reader, <a href=\"\/pt\/point-of-sale\/mobile-android\/requirements#card-readers\">refer to card reader requirements<\/a><\/p>\n<h2>UI for card reader operations<\/h2>\n<p>If your Mobile SDK solution uses NYC1 card readers as the payment interface, the people operating the readers need to:<\/p>\n<ul>\n<li>Connect their mobile device with the card reader through Bluetooth pairing or direct USB (if the Android device supports USB host mode).<\/li>\n<li>View an overview of card readers. For example, to switch to a different card reader.<\/li>\n<li>View details of the card reader they are using. For example, to check the battery charge level.<\/li>\n<li>Update the firmware of the card reader they are using.<\/li>\n<\/ul>\n<p>The SDK allows you to build your own UI for those tasks, but also provides a built-in UI as shown in the following examples.<\/p>\n<p><img alt=\"\" src=\"\/user\/pages\/docs\/03.point-of-sale\/55.mobile-android\/05.understand\/screen-EN_Reader2x.jpg\" \/><\/p>\n<p>The following sections provide some example built-in screens for specific tasks:<\/p>\n<ul>\n<li><a href=\"#bt-pairing\">Bluetooth pairing<\/a><\/li>\n<li><a href=\"#updating-card-reader\">Updating the card reader firmware<\/a><\/li>\n<\/ul>\n<p>If your solution uses the NYC1 card reader in combination with the NYC1 dock, users also need to be able to connect to the card reader through USB and update the dock firmware. See <a href=\"#usb-dock\">UI for dock operations<\/a>.<\/p>\n<h3 id=\"bt-pairing\">Bluetooth pairing<\/h3>\n<p>The built-in UI screens guide the reader through the process of connecting their mobile device to a card reader through Bluetooth.<\/p>\n<p><img style=\"width: 300px;\" alt=\"\" src=\"\/user\/pages\/docs\/03.point-of-sale\/55.mobile-android\/05.understand\/pairing-new.gif?decoding=auto&amp;fetchpriority=auto\" \/><\/p>\n<h3 id=\"updating-card-reader\">Updating the card reader firmware<\/h3>\n<p>The firmware of the card reader must be updated from time to time, to ensure secure transaction processing.<\/p>\n<div class=\"notices yellow\">\n<p>You must check for new firmware updates regularly, and update your card readers to the latest version.<\/p>\n<\/div>\n<p>Our built-in UI shows a <span style=\"color: red;\">red indicator<\/span> when a new firmware version is available for the connected card reader, and has an <strong>Update<\/strong> button to start the firmware update. A firmware update can fail when the card reader does not have an active Bluetooth connection when the update requires it. In this case the built-in UI shows instructions on how to reset the reader before retrying the update.<\/p>\n<p><img style=\"width: 300px;\" alt=\"\" src=\"\/user\/pages\/docs\/03.point-of-sale\/55.mobile-android\/05.understand\/reader-update-trimmed.gif?decoding=auto&amp;fetchpriority=auto\" \/><\/p>\n<p>If you use your own custom UI, it is required that you <a href=\"\/pt\/point-of-sale\/mobile-android\/build\/card-reader\/?tab=build_a_custom_ui_1_2#updating-card-reader\">build logic into your POS app<\/a> to check for new card reader firmware updates and handle the firmware update flow correctly within your POS app.<\/p>\n<h2 id=\"usb-dock\">UI for dock operations<\/h2>\n<p>If your Mobile SDK solution uses card readers as the payment interface in combination with docks, the people operating the readers need to:<\/p>\n<ul>\n<li>Connect their mobile device with the card reader through the dock.<\/li>\n<li>Update the firmware of the dock they are using.<\/li>\n<\/ul>\n<p>The SDK allows you to build your own UI for those tasks, but also provides a built-in UI.<\/p>\n<p>The following sections provide some example built-in screens for specific tasks:<\/p>\n<ul>\n<li><a href=\"#connecting-usb-dock\">Connecting to a dock<\/a><\/li>\n<li><a href=\"#updating-usb-dock\">Updating the dock firmware<\/a><\/li>\n<\/ul>\n<h3 id=\"connecting-usb-dock\">Connecting to a dock<\/h3>\n<p>In addition to Bluetooth, card readers can be connected through USB. The user's mobile device is connected to a dock using a USB-C cable, and the card reader is placed in the dock. The SDK recognizes the situation, and presents built-in UI screens to inform the reader about the USB connection.<\/p>\n<p><img alt=\"\" src=\"\/images\/0\/8\/3\/8\/d\/0838df5818cf7e691437e68a1d2786c9f079392c-screen-endock-connected.jpg\" \/><\/p>\n<p>Note that it is also possible to place the card reader in the dock but <a href=\"#bt-pairing\">connect the mobile device to the reader through Bluetooth<\/a>. In that case the dock and the user's mobile device are <em>not<\/em> connected with a USB-C cable. This is a way to charge the card reader through the dock in a countertop setup.<\/p>\n<h3 id=\"updating-usb-dock\">Updating the dock firmware<\/h3>\n<p>The firmware of the dock must be updated from time to time, to ensure secure transaction processing.<\/p>\n<p>Our built-in UI shows a <span style=\"color: red;\">red indicator<\/span> when a new firmware version is available for the connected dock, and has an <strong>Update<\/strong> button to start the firmware update.<\/p>\n<p><img style=\"width: 300px;\" alt=\"\" src=\"\/user\/pages\/docs\/03.point-of-sale\/55.mobile-android\/05.understand\/dock-update-trimmed.gif?decoding=auto&amp;fetchpriority=auto\" \/><\/p>\n<p>If you use your own custom UI, it is required that you <a href=\"\/pt\/point-of-sale\/mobile-android\/build\/card-reader\/?tab=build_a_custom_ui_1_2#updating-usb-dock\">build logic into your POS app<\/a> to check for new card reader firmware updates and handle the firmware update flow correctly within your POS app.<\/p>\n<h2>Kiosk mode<\/h2>\n<p>Kiosk mode is intended to optimize the UI for Tap to Pay transactions on larger screens, for example on Android tablets.<\/p>\n<p>Kiosk mode includes the following UI adjustments for usability and security:<\/p>\n<ul>\n<li><strong>Increased text and icon size<\/strong>: Text elements and icons shown during the transaction are enlarged for improved readability on larger screens.<\/li>\n<li><strong>Compact PIN keypad<\/strong>: The on-screen keypad used for PIN entry is reduced in size. This minimizes the risk of bystanders observing the customer's PIN entry.<\/li>\n<\/ul>\n<div class=\"notices yellow\">\n<p>According to the PCI MPoC compliance requirements, your Tap to Pay on Android solution must not use Kiosk mode in an unattended environment.<\/p>\n<\/div>\n<p>Kiosk mode activates automatically at the start of the transaction process if the SDK detects a mobile device with a screen width greater than or equal to 9 inches. It is possible to <a href=\"\/pt\/point-of-sale\/mobile-android\/build\/tap-to-pay\/#apply-kiosk-mode-on-all-smaller-tablets\">enable Kiosk mode on devices <\/a> with a screen width smaller than 9 inches. You can also <a href=\"\/pt\/point-of-sale\/mobile-android\/build\/tap-to-pay\/#customize-position-of-nfc-tap-indicator-in-kiosk-mode\">customize the placement of the NFC tap indicator<\/a> in kiosk mode. The indicator can either be a static image of an NFC logo or an animated chevron-type arrow.<\/p>\n<h2>Next steps<\/h2>\n<div class=\"next-steps\" id=\"next-steps\" >\n<a href=\"\/point-of-sale\/mobile-android\/build\" class=\"next-steps__step\" style=\"width:29%;\" target=\"_self\"><p class=\"next-steps__body\"><div style=\"text-align: center;\"><img src=\"\/user\/themes\/adyen\/images\/illustrations\/wrench.svg\"><h6 class=\"next-steps__title\">Build your solution<\/h6><p>Follow steps to build and Android Tap to Pay, Card reader, or Payments app solutions.<\/p><\/div><\/p><\/a><a href=\"\/point-of-sale\/mobile-android\/manage\" class=\"next-steps__step\" style=\"width:29%;\" target=\"_self\"><p class=\"next-steps__body\"><div style=\"text-align: center;\"><img src=\"\/user\/themes\/adyen\/images\/illustrations\/settings.svg\"><h6 class=\"next-steps__title\">Manage your solution<\/h6><p>Enable and maintain your solution and keep the software up-to-date.<\/p><\/div><\/p><\/a><a href=\"\/point-of-sale\/mobile-android\/troubleshooting\" class=\"next-steps__step\" style=\"width:29%;\" target=\"_self\"><p class=\"next-steps__body\"><div style=\"text-align: center;\"><img src=\"\/user\/themes\/adyen\/images\/illustrations\/close.svg\"><h6 class=\"next-steps__title\">Error handling<\/h6><p>Resolve errors that appear on the mobile Android device.<\/p><\/div><\/p><\/a><\/div>\n","url":"https:\/\/docs.adyen.com\/pt\/point-of-sale\/mobile-android\/understand","articleFields":{"description":"Learn about concepts and transaction flows relevant for choosing a Mobile solution.","parameters":{"generic_sdk_name":"Mobile SDK","specific_sdk_name":"Mobile SDK for Android","platform":"Android"},"type":"page","feedback_component":true,"filters_component":false,"page_id":"ae44de31-ab7f-4a5a-a128-3756a207dd55","decision_tree":"[]","last_edit_on":"06-10-2025 15:31"},"algolia":{"url":"https:\/\/docs.adyen.com\/pt\/point-of-sale\/mobile-android\/understand","title":"Understand the Android Mobile solutions","content":"This page explains various concepts that our Mobile solutions are based on, and provides information to help you choose which Mobile solution to build. You can choose to:\n\nIntegrate our Mobile SDK into your POS app, to accept Tap to Pay and\/or card reader payments.\nLet your POS app communicate with an Adyen Payments app that already includes the Mobile SDK, to accept Tap to Pay payments.\n\nSDK or Payments app\nBoth when integrating the Mobile SDK and when using the Payments app, your POS app must be integrated with Terminal API. And in both cases you have to work on the backend as well as on the frontend.\nIt depends on your use case and development capacity which solution is the most suitable. You may prefer a low-code integration without PCI Mobile Payments on COTS (MPoC) compliance requirements, or a more involved integration that allows more control of the app experience.\nAlso note that the same Mobile SDK is used for Tap to Pay and card reader payments. If your POS app allows selecting the payment interface, both solutions can be used alongside each other. The Payments app on the other hand only supports Tap to Pay.\nThe following table shows the pros and cons of each solution.\n\n\n\nMobile SDK\nPayments app\n\n\n\n\nPros\nPros\n\n\nFull control of the in-app experience\nLower integration effort (Links &amp; API)\n\n\nBetter UX: no app switching\nAdyen handles updates\n\n\nBetter payment performance\nNo PCI MPoC compliance requirements\n\n\nSupports Tap to Pay and card reader\n\n\n\nCons\nCons\n\n\nUpdate SDK version every six months\nPayments app must be boarded on each device\n\n\nPCI MPoC compliance requirements\nApp switching during the payment flow\n\n\n\nOnly supports Tap to Pay\n\n\n\nCommunication session\nWhen you integrate the Mobile SDK into your POS app, the SDK has to communicate in a secure way with the plataforma de pagamentos da Adyen. To enable this, you must integrate a server-to-server POST  \/checkout\/possdk\/v68\/sessions request to create a session. Your POS app needs to call your backend to trigger this request and get the session data.\nThe SDK uses the session data from the response to authenticate with our payments platform. Because the session expires after some time, the SDK checks regularly if it needs to establish a new session.\n\n\n\nSDK transaction flow\nIf you use or build a Mobile solution where our Mobile SDK for Android is integrated into your POS app, transactions take place as follows:\n\n\nOptional but recommended: your POS app calls a warm-up function to speed up initiating transactions. \n\n\nYour POS app creates a Terminal API request that is serialized to JSON, or receives the Terminal API payment request from your backend.\n\n\nThe POS app passes the Terminal API request to the Mobile SDK.\n\n\nThe SDK checks if the communication session is still valid, and if necessary establishes a new session.\n\n\nThe transaction starts on the mobile device.\n\n\nThe SDK passes the Terminal API response to your POS app.\n\n\n\n\n\nPayments app transaction flow\nIf you use or build a Mobile solution where your POS app communicates with the Adyen Payments app, transactions take place as follows:\n\nYour POS app creates a Terminal API payment request, or receives a Terminal API payment request from your backend.\nYour POS app sends an encrypted, Base64URL-encoded Terminal API payment request to the Payments app as an App Link with your return URL.\nOn the mobile device, a Tap to Pay screen appears, and the shopper presents their contactless payment method to the NFC reader of the device.\nThe Payments app routes the payment request through our POS Mobile SDK to the Adyen backend.\nThe Adyen backend returns an encrypted, Base64URL-encoded Terminal API payment response to the Payments app.\nOn the mobile device, the screen shows the outcome, and switches to your POS app using the return URL you specified.\nYour POS app receives the encrypted, Base64URL-encoded Terminal API payment response.\n\nPIN transactions\nIt is possible to make PIN transactions in your Tap to Pay and card reader solution. Unlike traditional payment terminals with physical keypads, PIN entry on a mobile device requires specialized security measures to protect the shopper's data. To comply with PCI MPoC compliance requirements, the PIN entry pad is not always centered on the mobile device screen. Instead, it appears in a random position as shown in the following examples. \n\n\n\n\n\n\n\n\n\nBottom-left  \nTop-right  \n\n\n\nPIN transaction with a card reader in the US\nYou need an NYC1 card reader with PIN support for secure PIN transactions.\n\nNYC1 card readers with PIN support require Mobile SDK version 2.4.0 or later.\n\nIn the US, not all NYC1 card readers support PIN. You can check if your card reader supports PIN transactions in the following ways:\n\nBy checking the [connectedDevice.model] . Returns the model of the card reader. The result can be: SCRP (card reader supports PIN). SCR (card reader does not support PIN).\n\nIn the built-in UI: If under Device Info the field Model is present, you have an NYC1-SCR card reader that does not support PIN. If the field Model is not present, you have an NYC1 that supports PIN.\n\n\n\nDevice info for NYC1-SCR\nDevice info for NYC1\n\n\n\n\nCard reader not suitable for PIN   \nCard reader suitable for PIN  \n\n\n\n\n\nIf you want to disable PIN support on your NYC1 card reader, refer to card reader requirements\nUI for card reader operations\nIf your Mobile SDK solution uses NYC1 card readers as the payment interface, the people operating the readers need to:\n\nConnect their mobile device with the card reader through Bluetooth pairing or direct USB (if the Android device supports USB host mode).\nView an overview of card readers. For example, to switch to a different card reader.\nView details of the card reader they are using. For example, to check the battery charge level.\nUpdate the firmware of the card reader they are using.\n\nThe SDK allows you to build your own UI for those tasks, but also provides a built-in UI as shown in the following examples.\n\nThe following sections provide some example built-in screens for specific tasks:\n\nBluetooth pairing\nUpdating the card reader firmware\n\nIf your solution uses the NYC1 card reader in combination with the NYC1 dock, users also need to be able to connect to the card reader through USB and update the dock firmware. See UI for dock operations.\nBluetooth pairing\nThe built-in UI screens guide the reader through the process of connecting their mobile device to a card reader through Bluetooth.\n\nUpdating the card reader firmware\nThe firmware of the card reader must be updated from time to time, to ensure secure transaction processing.\n\nYou must check for new firmware updates regularly, and update your card readers to the latest version.\n\nOur built-in UI shows a red indicator when a new firmware version is available for the connected card reader, and has an Update button to start the firmware update. A firmware update can fail when the card reader does not have an active Bluetooth connection when the update requires it. In this case the built-in UI shows instructions on how to reset the reader before retrying the update.\n\nIf you use your own custom UI, it is required that you build logic into your POS app to check for new card reader firmware updates and handle the firmware update flow correctly within your POS app.\nUI for dock operations\nIf your Mobile SDK solution uses card readers as the payment interface in combination with docks, the people operating the readers need to:\n\nConnect their mobile device with the card reader through the dock.\nUpdate the firmware of the dock they are using.\n\nThe SDK allows you to build your own UI for those tasks, but also provides a built-in UI.\nThe following sections provide some example built-in screens for specific tasks:\n\nConnecting to a dock\nUpdating the dock firmware\n\nConnecting to a dock\nIn addition to Bluetooth, card readers can be connected through USB. The user's mobile device is connected to a dock using a USB-C cable, and the card reader is placed in the dock. The SDK recognizes the situation, and presents built-in UI screens to inform the reader about the USB connection.\n\nNote that it is also possible to place the card reader in the dock but connect the mobile device to the reader through Bluetooth. In that case the dock and the user's mobile device are not connected with a USB-C cable. This is a way to charge the card reader through the dock in a countertop setup.\nUpdating the dock firmware\nThe firmware of the dock must be updated from time to time, to ensure secure transaction processing.\nOur built-in UI shows a red indicator when a new firmware version is available for the connected dock, and has an Update button to start the firmware update.\n\nIf you use your own custom UI, it is required that you build logic into your POS app to check for new card reader firmware updates and handle the firmware update flow correctly within your POS app.\nKiosk mode\nKiosk mode is intended to optimize the UI for Tap to Pay transactions on larger screens, for example on Android tablets.\nKiosk mode includes the following UI adjustments for usability and security:\n\nIncreased text and icon size: Text elements and icons shown during the transaction are enlarged for improved readability on larger screens.\nCompact PIN keypad: The on-screen keypad used for PIN entry is reduced in size. This minimizes the risk of bystanders observing the customer's PIN entry.\n\n\nAccording to the PCI MPoC compliance requirements, your Tap to Pay on Android solution must not use Kiosk mode in an unattended environment.\n\nKiosk mode activates automatically at the start of the transaction process if the SDK detects a mobile device with a screen width greater than or equal to 9 inches. It is possible to enable Kiosk mode on devices  with a screen width smaller than 9 inches. You can also customize the placement of the NFC tap indicator in kiosk mode. The indicator can either be a static image of an NFC logo or an animated chevron-type arrow.\nNext steps\n\nBuild your solutionFollow steps to build and Android Tap to Pay, Card reader, or Payments app solutions.Manage your solutionEnable and maintain your solution and keep the software up-to-date.Error handlingResolve errors that appear on the mobile Android device.\n","type":"page","locale":"pt","boost":17,"hierarchy":{"lvl0":"Home","lvl1":"Terminais","lvl2":"Android Mobile solutions","lvl3":"Understand the Android Mobile solutions"},"hierarchy_url":{"lvl0":"https:\/\/docs.adyen.com\/pt","lvl1":"https:\/\/docs.adyen.com\/pt\/point-of-sale","lvl2":"https:\/\/docs.adyen.com\/pt\/point-of-sale\/mobile-android","lvl3":"\/pt\/point-of-sale\/mobile-android\/understand"},"levels":4,"category":"In-person payments","category_color":"green","tags":["Understand","Android","Mobile","solutions"]},"articleFiles":{"screen-EN_dock-connected.jpg":"<img alt=\"\" src=\"https:\/\/docs.adyen.com\/images\/e\/7\/e\/3\/4\/e7e34e456916290f67a24e4b2f48bd10833dea49-screen-endock-connected.jpg\" \/>","screen-EN_Reader2x.jpg":"<img alt=\"\" src=\"https:\/\/docs.adyen.com\/user\/pages\/docs\/03.point-of-sale\/55.mobile-android\/05.understand\/screen-EN_Reader2x.jpg\" \/>","dock-update-trimmed.gif":"<img style=\"width: 300px;\" alt=\"\" src=\"https:\/\/docs.adyen.com\/user\/pages\/docs\/03.point-of-sale\/55.mobile-android\/05.understand\/dock-update-trimmed.gif?decoding=auto&amp;fetchpriority=auto\" \/>","pairing-new.gif":"<img style=\"width: 300px;\" alt=\"\" src=\"https:\/\/docs.adyen.com\/user\/pages\/docs\/03.point-of-sale\/55.mobile-android\/05.understand\/pairing-new.gif?decoding=auto&amp;fetchpriority=auto\" \/>","reader-update-trimmed.gif":"<img style=\"width: 300px;\" alt=\"\" src=\"https:\/\/docs.adyen.com\/user\/pages\/docs\/03.point-of-sale\/55.mobile-android\/05.understand\/reader-update-trimmed.gif?decoding=auto&amp;fetchpriority=auto\" \/>","updating-reader.gif":"<img alt=\"\" src=\"https:\/\/docs.adyen.com\/user\/pages\/docs\/03.point-of-sale\/55.mobile-android\/05.understand\/updating-reader.gif\" \/>"}}