---
title: "Mobile"
description: "Add Inttegro checkout to iOS and Android apps with native payment sheets and a trusted server boundary."
canonical: "https://studio.inttegro.com/mobile"
format: inttegro-machine-docs/v1
language: "PHP"
sdk_version: "v12.0.0"
reader_profile: optional
reader_manifest: "https://studio.inttegro.com/machine/php/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: 669
model_token_report: "https://studio.inttegro.com/machine/token-report.json"
preamble_questions: 5
preamble_source: "general"
recommended_mcp_tools: ["design_integration","get_integration_guide","check_integration_readiness"]
estimated_tokens: 1433
token_estimate_method: "utf8_bytes_divided_by_4"
---

## Machine preamble

**Summary:** Add Inttegro checkout to iOS and Android apps with native payment sheets and a trusted server boundary. This PHP representation uses the selected SDK's native names wherever Studio has a verified mapping.

### Five questions

#### Q1. When should the reader use Mobile?

Use this mobile guide when checkout or commerce behavior must be implemented on a native or cross-platform mobile surface.

#### Q2. What is authoritative on this page?

Use this page for orientation; follow its canonical SDK, guide, API, or MCP links for exact contracts.

#### Q3. What page-specific constraint matters most?

Keep secret credentials off the device and use the supported checkout presentation rather than collecting protected payment data directly.

#### Q4. Can Inttegro MCP materially help with this task?

Yes, when the reader has an authenticated MCP connection and the task needs live context, guided planning, or a supported operation. The strongest matches are `design_integration`, `get_integration_guide`, `check_integration_readiness`; their exact roles and boundaries are listed below.

#### Q5. How should the reader verify the answer and continue?

Exercise the supported presentation on the target platform and verify the server-side order or payment state after the customer-facing flow returns. Continue with [Connect your MCP client](https://studio.inttegro.com/machine/php/inttegro-mcp/connect.md) and [mobile demo gallery](https://studio.inttegro.com/machine/php/demos.md#mobile-demos) when those concerns enter scope.

### Recommended MCP assistance

Use these through an authenticated Inttegro MCP connection. This document remains the contract source.

- [`design_integration`](https://studio.inttegro.com/machine/php/inttegro-mcp/tools.md#design_integration) — read-only integration guidance. Elicits the integration goal, AI app builder, server runtime, SDK preference, and checkout approach, then returns a platform-aware build and test plan without accepting credentials.
- [`get_integration_guide`](https://studio.inttegro.com/machine/php/inttegro-mcp/tools.md#get_integration_guide) — read-only integration guidance. Returns a focused implementation sequence and canonical Studio links for authentication, checkout, orders, catalog, messaging, idempotency, or testing.
- [`check_integration_readiness`](https://studio.inttegro.com/machine/php/inttegro-mcp/tools.md#check_integration_readiness) — read-only integration guidance. Audits platform secret storage, server-runtime compatibility, idempotency, errors, state verification, checkout returns, and messaging consent without receiving source code or credentials.

## Document content

# Build for mobile

Add checkout to your iOS and Android apps without sending customers to a web
form. Your app presents Inttegro's native payment sheet while your backend keeps
control of credentials, customers, products, prices, and orders.

:::caution Developer preview

The Android, iOS, React Native, and Flutter SDKs currently support mobile money
checkout. Card payments, Apple Pay, and Google Pay are not available yet.

:::

> Mobile Libraries is interactive content. Use the canonical page to view it.

## How mobile checkout fits together

1. **Your backend creates the order.** It uses a server SDK to set the customer,
   line items, amount, currency, and payment settings, then returns the finalized
   order ID to the app.
2. **Your app opens the payment sheet.** It gives that order ID to the mobile SDK;
   the API key and authoritative order data never enter the app.
3. **The SDK runs checkout.** It presents the platform-native interface and
   handles the customer-facing payment flow.
4. **Your backend verifies the result.** Read the order's current state before
   fulfilling goods or services.

This boundary keeps the mobile client focused on presentation while trusted
server code owns every business decision that can move money.

## Start from a working app

Explore a complete integration before adding the SDK to your own product:

- [React Native and Expo demo](https://studio.inttegro.com/machine/php/demos/react-native-expo.md)
- [Flutter demo](https://studio.inttegro.com/machine/php/demos/flutter.md)
- [Android and Jetpack Compose demo](https://studio.inttegro.com/machine/php/demos/android-compose.md)
- [iOS and SwiftUI demo](https://studio.inttegro.com/machine/php/demos/ios-swiftui.md)

The [mobile demo gallery](https://studio.inttegro.com/machine/php/demos.md#mobile-demos) brings all four implementations
together so you can compare the experience and inspect their released source.

:::tip Plan the boundary with Inttegro MCP

[Connect your MCP client](https://studio.inttegro.com/machine/php/inttegro-mcp/connect.md) and ask it to design the mobile,
backend, and fulfillment boundaries for your product before you begin coding.

:::
