--- title: "Android SDK" description: "Present Inttegro checkout as a native payment sheet in Kotlin and Jetpack Compose applications." canonical: "https://studio.inttegro.com/mobile/android" format: inttegro-machine-docs/v1 language: "TypeScript" sdk_version: "v12.0.0" reader_profile: optional reader_manifest: "https://studio.inttegro.com/machine/typescript/readers/index.json" reader_identification: "Optional: declare your client only if known and your current-session capabilities; use reader_manifest for supplemental recommendations." preamble_estimated_tokens: 532 model_token_report: "https://studio.inttegro.com/machine/token-report.json" preamble_questions: 5 preamble_source: "curated" recommended_mcp_tools: ["design_integration","check_integration_readiness"] estimated_tokens: 2711 token_estimate_method: "utf8_bytes_divided_by_4" --- ## Machine preamble **Summary:** Native Android Checkout receives only a backend-finalized Order ID; Compose presents the sheet, while server lookup—not a completed UI result—authorizes fulfillment. ### Five questions #### Q1. Which Android artifact does a native Kotlin app need? Use the Inttegro payments artifact described in [requirements](https://studio.inttegro.com/machine/typescript/mobile/android.md#requirements), not the Android activity/dictionary bridge for React Native and Flutter. The guide describes a source-evaluation developer preview rather than an open public Maven distribution; confirm availability before live rollout. #### Q2. What should cross from the backend to Android? Only the finalized Order ID. Keep API credentials, amount and line-item decisions, and protected payment data off the device. [Orders](https://studio.inttegro.com/machine/typescript/api/orders.md#create-an-order) defines the trusted server creation path. #### Q3. How is the native payment sheet presented? Create PaymentSheetConfiguration with the Order ID and pass it to the documented Compose InttegroPaymentSheet. Use [present the sheet](https://studio.inttegro.com/machine/typescript/mobile/android.md#present-the-payment-sheet) for public Kotlin signatures, not Flutter or React Native bridge calls. #### Q4. What does onResult completed prove? It supports immediate UI feedback only. Ask the trusted backend to [look up the order](https://studio.inttegro.com/machine/typescript/api/orders.md#lookup-an-order) or process its webhook before releasing goods or services; separate canceled and failed results. #### Q5. Can display features or MCP change the sale? Sheet features only alter customer presentation, not Order amount or identity. An authenticated agent can use [design_integration](https://studio.inttegro.com/machine/typescript/inttegro-mcp/tools.md#design_integration) and [check_integration_readiness](https://studio.inttegro.com/machine/typescript/inttegro-mcp/tools.md#check_integration_readiness) to plan and audit declared integration controls; neither replaces live server verification. ## Document content # Inttegro SDK for Android Add Inttegro checkout to a Kotlin or Jetpack Compose app with a native Material payment sheet. The Android SDK owns the customer-facing payment flow; your backend continues to own credentials and every decision about the order. :::caution Developer preview The Android SDK is implemented and used by the React Native and Flutter bridges, but public Maven distribution is not open yet. The current preview supports mobile money checkout; card payments and Google Pay are not available. ::: ## Requirements - Android API 26 or later - A Kotlin application using Jetpack Compose - A backend endpoint that creates and finalizes an Inttegro order The SDK has two Maven artifacts with distinct responsibilities: - `com.inttegro:inttegro-payments` contains the native Checkout client, Jetpack Compose payment sheet, result models, and telemetry. - `com.inttegro:inttegro-android` adds the activity and dictionary bridge used by the official React Native and Flutter packages. It depends on `inttegro-payments` and preserves the existing framework-integration coordinate. Native Kotlin and Compose applications should depend directly on `inttegro-payments`; they do not need the framework bridge. Until public Maven distribution opens, use the [versioned source](https://github.com/inttegro/commerce/tree/inttegro-android-0.4.1/sdks/mobile/android) to evaluate the preview. ## Present the payment sheet Give the SDK only the finalized Order ID returned by your backend: ```kotlin val configuration = PaymentSheetConfiguration( orderId = orderId, returnUrl = "merchant-app://inttegro-return", features = PaymentSheetConfiguration.Features( showLineItems = true, showInvoiceDownload = true, showReceiptDownload = true, allowPaymentMethodChange = false, ), ) InttegroPaymentSheet( configuration = configuration, onResult = ::handlePaymentResult, onDismissRequest = ::closePaymentSheet, eventListener = CheckoutEventListener(::handleCheckoutEvent), ) ``` `InttegroPaymentSheet` retrieves the checkout, presents available payment methods, collects any required mobile money details, handles confirmation or provider authorization, and returns a completed, canceled, or failed result. For a Buy link, configure the same sheet with its public Purchase Intent instead: ```kotlin val configuration = PaymentSheetConfiguration( purchaseIntentId = buyLink.purchaseIntentId, returnUrl = "merchant-app://inttegro-return", ) ``` The sheet gathers the Buy-link choices and payment details without creating an Order. When the payer presses Pay, Inttegro creates the finalized Order and starts the payment attempt together. Customer-selected pricing uses the authoritative currency, range, and suggestions returned by Checkout. ## Observe the payment lifecycle `eventListener` receives the same ordered lifecycle as the web and other mobile SDKs: `presented`, `ready`, `change`, `orderPrepared`, `paymentAttemptStarted`, `paymentActionRequired`, `paymentProcessing`, `paymentAttemptFailed`, `completed`, `canceled`, and `failed`. Every `CheckoutEvent` includes `type`, `occurredAt`, `flowId`, and `sequence`. Events about a payment attempt carry the full client-safe `order` rather than a separate payment ID. `PAYMENT_ATTEMPT_FAILED` is recoverable; leave the sheet in control so the payer can retry. `onResult` receives the exact terminal `COMPLETED`, `CANCELED`, or `FAILED` event: ```kotlin fun handlePaymentResult(result: PaymentSheetResult) { when (result) { is PaymentSheetResult.Completed -> showPaymentComplete(result.event.order!!.id) is PaymentSheetResult.Canceled -> restoreCheckoutControls() is PaymentSheetResult.Failed -> showPaymentUnavailable(result.event.failure!!.message) } } ``` Use lifecycle events for immediate interface state and privacy-safe telemetry. Before fulfillment, retrieve the Order from your backend or process its webhook. > Mobile Sdk Screenshots is interactive content. Use the canonical page to view it. ## Optional feature states Configure optional presentation through [`PaymentSheetConfiguration.Features`](https://mobile.inttegro.dev/v0.4.1/android/payments/com.inttegro.payments/-payment-sheet-configuration/-features/). These values control only what the native sheet shows. They cannot change the Order, its shipping address, its amount, or the customer that owns an attached payment method. Start with the defaults, then expose only the context or follow-up actions that help the payer complete this checkout. | Property | Default | What changes | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | [`allowPaymentMethodChange`](https://mobile.inttegro.dev/v0.4.1/android/payments/com.inttegro.payments/-payment-sheet-configuration/-features/allow-payment-method-change) | `true` | Set to `false` to keep an attached method selected and remove the replacement action. If the Order has no attached method, the payer can still enter one. | | [`showInvoiceDownload`](https://mobile.inttegro.dev/v0.4.1/android/payments/com.inttegro.payments/-payment-sheet-configuration/-features/show-invoice-download) | `false` | Offers the invoice after a successful payment when Checkout returns a secure invoice URL. | | [`showLineItems`](https://mobile.inttegro.dev/v0.4.1/android/payments/com.inttegro.payments/-payment-sheet-configuration/-features/show-line-items) | `false` | Offers a collapsed Order summary when Checkout returns line items. Opening it moves the sheet to its full-height state before revealing the items. | | [`showReceiptDownload`](https://mobile.inttegro.dev/v0.4.1/android/payments/com.inttegro.payments/-payment-sheet-configuration/-features/show-receipt-download) | `false` | Offers the receipt after a successful payment when Checkout returns a secure receipt URL. | The opening capture combines `showLineItems = true` with `allowPaymentMethodChange = false`. The attached method and pay action remain in view while the Order summary stays out of the way until the payer opens it. The completion capture enables both download properties. After payment succeeds, the sheet returns to its compact state and shows only the document actions for URLs Checkout actually supplied; the Done button remains immediately available. > Mobile Sdk Feature Screenshots is interactive content. Use the canonical page to view it. :::warning Verify before fulfillment A completed result is useful for immediate app feedback. Your backend must still read the order's current state or process its webhook before releasing goods or services. ::: ## Continue - [Browse the generated API reference](https://mobile.inttegro.dev/v0.4.1/android/) - [Run the Android and Jetpack Compose demo](https://studio.inttegro.com/machine/typescript/demos/android-compose.md) - [Compare every mobile SDK](https://studio.inttegro.com/machine/typescript/mobile.md) - [Create and finalize orders](https://studio.inttegro.com/machine/typescript/api/orders.md#create-an-order)