Mobile SDKs
A native payment sheet for your app: cards, mobile wallets and Zimswitch, in your Checkout Studio design.
| Platform | Package | Install |
|---|---|---|
| iOS (SwiftUI) | Watenga | Swift Package Manager or CocoaPods (pod 'Watenga') |
| Android (Jetpack Compose) | africa.watenga:watenga-android | Maven Central |
| React Native and Expo | @watenga/react-native | npm install @watenga/react-native react-native-webview |
| Flutter | watenga_flutter_ui | flutter pub add watenga_flutter_ui |
How a payment works
- Your server creates a checkout session with its secret key (
POST /v1/checkout/sessions, Hosted checkout) and gives the app itsclient_secret. The app never decides the amount, and never holds a secret key. - The app opens the sheet with your publishable key (
pk_test_…orpk_live_…) and the client secret. The sheet asks the server which methods, mobile wallets, currencies and phone formats your market offers (none are built into the app) and draws your published Checkout Studio design (itscheckout_native_appearancetokens). - Cards are entered in the card processor's own form (PCI SAQ A): the card number never touches your app or Watenga's servers. A mobile-money payment prompts the customer's phone and the sheet waits for their approval.
- The sheet returns the result to your app; confirm the payment on your server with the
payment.capture.completedwebhook before you fulfil the order.
Card entry in the native iOS and Android sheets
The native card step uses the card processor's licensed mobile SDK (OPPWA), which you add to your app from your processor. Without it, the iOS sheet builds and offers the other methods; the Android module needs it on the classpath to build. React Native and Flutter enter cards in the processor's hosted form in a WebView.