# Native Mobile SDKs

xMoney provides native checkout SDKs for iOS, Android, and React Native. All three use the same integration model: your backend creates a signed order, the app presents a payment surface, and the SDK returns a `PaymentResult`.

Current release: **1.0.0** on every platform.

iOS
Integrate with Swift Package Manager or CocoaPods. Use Payment Sheet, Payment Element, or Apple Pay in UIKit and SwiftUI.

Android
Install from Maven Central. Use Payment Sheet, Payment Element, or Google Pay with Compose or an Activity.

React Native
Install from npm and use native payment views from React Native New Architecture apps, including Expo development builds.

## Choose an integration

| Surface | Use it when | Who owns the Pay button? |
|  --- | --- | --- |
| **Payment Sheet** | You want the fastest path to a complete native checkout. | The SDK |
| **Payment Element** | The payment form should sit inside your own checkout layout. | The SDK, or your app through `confirm()` |
| **Apple Pay / Google Pay** | You want a standalone express-wallet experience. | The native wallet |


Payment Sheet includes the platform wallet. Payment Element does not add the wallet module automatically: link `XMoneyApplePay` beside the iOS element or `com.xmoney:googlepay` beside the Android element when you want a wallet button. The React Native package includes both platform wrappers, but each wallet renders only on its supported platform.

## Native SDK or WebView?

Use a native SDK when you want native controls, lifecycle handling, accessibility, and wallet presentation. Use [Mobile WebView integration](/guides/checkout/inline-checkout/mobile-webview) when you already have one web checkout that must be shared by web, iOS, and Android. Use [Hosted Checkout](/guides/checkout/hosted-checkout) when redirecting to an xMoney-hosted payment page is a better fit.

The native SDKs are not WebView wrappers. Card collection uses native SDK views; web content may still appear during an issuer's 3DS challenge.

## Shared checkout flow

Sequence diagram showing the shared xMoney native SDK checkout flow
1. Your backend creates the order and signs it with the private key.
2. The app receives `payload` and `checksum` and builds a `PaymentIntent`.
3. The app presents Payment Sheet, mounts Payment Element, or opens a wallet.
4. The SDK obtains the payment session, collects payment details, and handles 3DS when required.
5. The SDK returns `complete`, `failed`, or `canceled`.
6. Your backend confirms the final transaction status before fulfillment.


Keep secret keys on your server
The app should contain only a publishable key such as `pk_test_...` or `pk_live_...`. Never ship a private or secret API key. Create and sign orders on your backend.

For a server-side signing example, see [Create the order on your backend](/guides/checkout/inline-checkout/web-integration#3-create-the-order-on-your-backend).

## Install a platform SDK

iOS
Use Swift Package Manager:

```swift
.package(
    url: "https://github.com/xMoney-Payments/xmoney-ios.git",
    from: "1.0.0"
)
```

Link `XMoneyPaymentSheet` for the drop-in flow, or select `XMoneyPaymentElement` and `XMoneyApplePay` separately.

With CocoaPods:

```ruby
pod 'XMoneyPaymentSheet', '1.0.0'
```

Android
Install from Maven Central:

```kotlin
dependencies {
    implementation("com.xmoney:paymentsheet:1.0.0")
}
```

For separate surfaces, use `com.xmoney:paymentelement:1.0.0` and `com.xmoney:googlepay:1.0.0`.

React Native
Install the npm package:

```bash
npm install @xmoney/react-native@1.0.0
```

React Native 0.76 or later with New Architecture is required. On iOS, run `pod install`, then rebuild the native app.

## Payment results and order consumption

Every surface reports the same three terminal outcomes:

- **Complete:** payment completed; the transaction is available on the result.
- **Failed:** the attempt failed; use the SDK-authored error code and message.
- **Canceled:** the shopper dismissed or left the flow.


Signed order checksums are one-shot after a payment attempt starts:

| Outcome | Is the order consumed? | Next action |
|  --- | --- | --- |
| Complete or failed | Yes | Request a new signed order and create a new `PaymentIntent`. |
| Canceled after Pay or 3DS started | Yes | Request a new signed order. |
| Payment Sheet closed before Pay | No | Present the same intent again. |
| Wallet dismissed before authorization | No | Present the same intent again. |


For Payment Element and wallet buttons, replace the consumed intent or unmount the surface. Use `isOrderConsumed` and `isInteractionEnabled` where exposed to control your app UI.

Confirm payment server-side
`PaymentResult` updates the app experience; it is not the sole source of truth for fulfillment. Confirm final status through your backend, using webhooks or a trusted API check.

## Shared capabilities

All three SDKs support:

- Card collection and saved cards
- Payment Sheet and embedded Payment Element
- Apple Pay on iOS and Google Pay on Android
- SDK-owned or merchant-owned Pay buttons for Payment Element
- Order updates without remounting Payment Element
- 3DS challenges
- Light, dark, and custom appearance
- English, Greek, Romanian, Bulgarian, Hungarian, and Polish
- Optional cardholder name verification when enabled for the site


For complete API references and runnable samples, see the [iOS SDK](https://github.com/xMoney-Payments/xmoney-ios), [Android SDK](https://github.com/xMoney-Payments/xmoney-android), and [React Native SDK](https://github.com/xMoney-Payments/xmoney-react-native) repositories.