Mobile
Take payments in your mobile app
Your iPhone and Android apps can take payments with Vezmo: cards, Apple Pay and Google Pay, pay-later methods, Cash App, UPI and Pix, in the buyer's own currency, with 3D Secure. The payment is the same API checkout session your website uses, so pricing, payouts, webhooks and the dashboard work exactly as they do on the web.
Two ways to do it
- Checkout for apps (available now): your app opens our hosted checkout in the phone's secure browser sheet, the buyer pays, and the checkout sends them straight back to your app with the result. Every payment method works, and there is no SDK to install.
- Native SDK: the Vezmo payment sheet inside your app. Available for React Native (and Expo), iOS, Android and Flutter. Checkout for apps keeps working alongside it.
Release candidate: the SDKs are published to npm, Swift Package Manager, Maven Central and pub.dev with Vezmo's mobile launch. Until then, use Checkout for apps.
Source code and example apps
The SDKs are open source (MIT) in one GitHub repository, vezmo-mobile-sdk. Each has an example app, a small shop that pays against Vezmo's sandbox, and a changelog.
Found a bug in an SDK? Open an issue with the SDK, its version and the phone. Report a security problem privately, as the repository's security policy says, never in a public issue.
1. Add your app
In the dashboard, open Developers → Mobile apps and add each app that takes payments:
- Platform: iPhone (iOS) or Android.
- Bundle ID or package name, like
com.acme.shop. - Return link: the link that opens your app. Either your app's own scheme, like
acme://vezmo, or a universal link / App Link on your site, likehttps://shop.acme.com/vezmo.
This is the app version of trusted origins. A checkout only ever sends the buyer back to a return link registered here (or a path or query under it, such as acme://vezmo/order/1042). Web links (http), script links and other apps' payment links are refused.
2. Create the session on your server
Your server creates the session with your API key, exactly as for the web. For Checkout for apps it adds app.returnUrl. Never put your API key or secret in the app: the app only ever gets the session's url and clientToken. See Checkout for apps for the full request.
3. Know the result
Three signals, in order of trust:
- Webhook (fulfil orders from this):
payment.success,payment.processing,payment.failed. See Webhooks. - Session status, for your app's screen. It answers for a week after the session expires, so a buyer who comes back late still sees the outcome.
- The return link, which carries
status(success,pendingorfailed) andpaymentId. Good for moving the screen on, never for shipping an order: anyone can open a link.
// GET https://api.vezmo.com/api/v1/secure-payments/{clientToken}/status
{
"success": true,
"data": {
"state": "succeeded",
"paymentId": "cmv7uayzo004jqu01h8sdz7i9",
"transactionId": "VT34J5UP",
"livemode": true
}
}state is one of open (not paid yet), requires_action (the buyer has a step left, such as 3D Secure or their bank app), processing (paid, money on its way, for example a bank debit), succeeded, failed (the last attempt failed; the buyer can try again) or canceled.
App store rules
Physical goods and real-world services (deliveries, bookings, tickets, services) can be paid with Vezmo inside your app.
Digital goods used inside the app (subscriptions to app features, in-app currency, content) are different: Apple's App Store and Google Play generally require their own in-app purchase for these. Some regions allow exceptions, such as links to a web checkout or other payment options under local rules. These rules change, so check the current Apple App Review Guidelines and Google Play policies for your app and your buyers' countries before you sell digital goods through Vezmo.
Before you go live
- Every app that takes payments is added under Developers → Mobile apps.
- An iPhone app that offers Apple Pay: its Apple Merchant ID shows Active under Developers → Mobile apps → Apple Pay in your iPhone app (see Apple Pay).
- Checkout for apps and iPhone: your app opens its return link (a URL scheme in Info.plist; an intent filter on Android for Checkout for apps). The Android SDK needs nothing.
- Sessions are created on your server only; no keys in the app.
- Orders are fulfilled from the webhook, not from the return link.
- You tested with sandbox keys and test cards, including a card that asks for 3D Secure.