# Flutterwave Payment Gateway UI in React Native (Free Template)

> By Lawrence Arya, Founder & CEO of VP0. Published 2026-07-01. 6 min read.
> Source: https://vp0.com/blogs/flutterwave-payment-gateway-ui-react-native

You build the screen, Flutterwave handles the money. Here is the clean split, the payment methods to plan for, and the verification that keeps it safe.

**TL;DR.** In React Native, a Flutterwave payment splits cleanly: you build the order summary, method selector, and pay button, while Flutterwave's hosted checkout handles card entry, 3D Secure, and PCI. The official flutterwave-react-native SDK opens Flutterwave Standard on the V3 API, clearing cards, bank transfers, mobile money, USSD, Apple Pay, and Google Pay across more than 30 countries. The callback is a signal, not a receipt: verify every transaction on your server against status, amount, and currency before fulfilling. Build the UI from a free template, wire the SDK, and keep the secret key server-side.

In React Native, a Flutterwave payment splits cleanly: you build the payment screen, and Flutterwave handles the money. The order summary, the method selector, and the pay button are native UI you own. The card entry, the mobile-money prompt, the 3D Secure step, and PCI compliance all live inside Flutterwave's hosted checkout, which the [official flutterwave-react-native SDK](https://www.npmjs.com/package/flutterwave-react-native) opens for you. That division is the whole security model: your app never touches a raw card number. Flutterwave clears payments across [more than 30 countries](https://developer.flutterwave.com/) with roughly 15 methods, from cards and bank transfers to mobile money, Apple Pay, and Google Pay, so the UI you design once reaches most of Africa and the diaspora. Build the screen from a free template, wire the SDK, and verify every transaction server-side before you deliver anything.

## How does a Flutterwave payment work in React Native?

The SDK gives you a button that opens a hosted checkout. The [Flutterwave React Native library](https://github.com/Flutterwave/flutterwave-react-native) exposes a PayWithFlutterwave component: you pass it your public key, a unique transaction reference, the amount, currency, and the customer's email, and on tap it launches Flutterwave Standard, the hosted page that runs the actual payment on the V3 API. When the customer finishes, the SDK calls back with a status and the reference.

That callback is a signal, not a receipt. It tells you the user reached an end state, but you confirm the real outcome on your server. The pattern mirrors every hosted checkout, and it is the same server-first flow behind [the Flutterwave checkout React component](/blogs/flutterwave-checkout-react-component-ai/) and [a Paystack React checkout](/blogs/paystack-react-checkout-ai-generator/).

## What do you build, and what does Flutterwave handle?

You build everything the user sees before and after the money moves, and Flutterwave owns the money itself. Your side is the cart or order summary, the amount in the right currency, a clear pay button, and the success and pending states. Flutterwave's side is method selection, card capture, bank and mobile-money flows, fraud checks, and the compliance that would otherwise put your app in PCI scope.

| Method | Where it clears | UX to plan for |
| --- | --- | --- |
| Cards | Global, most Flutterwave regions | 3D Secure step may appear |
| Mobile money | Kenya, Ghana, Uganda, Rwanda | pending state while the user approves on their phone |
| Bank transfer | Nigeria and select markets | show a reference and a waiting state |
| USSD | Nigeria | user dials a code, then you poll or await webhook |
| Apple Pay and Google Pay | supported devices and regions | native sheet, fastest checkout |

The mobile-money and USSD rows are the ones people forget. Those are not instant: the customer acts on their own phone, so your UI needs a genuine pending state, the same discipline as [a mobile money UI](/blogs/fintech-mobile-money-ui-react/) and the [M-Pesa Daraja integration](/blogs/mpesa-daraja-payment-integration-ui/).

## How do you keep it secure and verified?

Verify on the server, always, before you treat a payment as real. When the SDK returns, send the transaction reference to your backend and call Flutterwave's verify endpoint, then check three things: the status is successful, the amount matches what you charged, and the currency is the one you expected. Only then do you fulfil the order. A $10 order that comes back "successful" for 10 of a weaker currency is the classic manipulation this catches.

Two rules protect the rest. Keep your secret key on the server and ship only the public key in the app, because anything in the bundle is readable. And treat the reference as the source of truth by making it unique per attempt and recording it, so a retried or replayed callback cannot double-credit an order. Webhooks are the reliable backstop for the asynchronous methods, since a mobile-money payment may confirm minutes after the user closes the app.

## Common mistakes building the Flutterwave UI

The expensive one is trusting the client callback. A determined user can spoof a success on the device, so an app that unlocks content on the SDK's onRedirect alone will leak product; the server verify call is not optional. Right behind it is hardcoding the secret key into the React Native bundle, which exposes your whole account.

The UI mistakes are about state. Treating every payment as instant breaks mobile money and USSD, where the correct design shows a pending screen and resolves on a webhook. And using the wrong currency code, or not passing one at all, produces confusing charges, so bind the currency to the customer's region rather than a default. Get the states right and the same screen handles a card tap and a mobile-money approval without looking broken.

## Key takeaways: a Flutterwave payment UI in React Native

- Build the order summary, method selector, and pay button natively; let the flutterwave-react-native SDK open the hosted checkout for card and PCI handling.
- Pass a unique transaction reference, amount, currency, and email to PayWithFlutterwave, and treat the callback as a signal to verify, not a receipt.
- Verify every transaction on your server against status, amount, and currency before fulfilling the order.
- Design real pending states for mobile money and USSD, and confirm those through webhooks.
- Ship only the public key in the app, keep the secret key server-side, and record references to block replays.

## Frequently asked questions

**How do I add Flutterwave payments to a React Native app?**
Install the official flutterwave-react-native SDK, render the PayWithFlutterwave button with your public key, a unique transaction reference, the amount, currency, and customer email, and let it open Flutterwave Standard for the actual payment. When it calls back, send the reference to your server, call the verify endpoint, and fulfil the order only after confirming status, amount, and currency. Build the surrounding UI from a free template.

**Does Flutterwave handle card security so my app stays PCI compliant?**
Yes, because the card is entered inside Flutterwave's hosted checkout, not your app. The SDK opens Flutterwave Standard to capture the card and run 3D Secure, so your React Native code never sees a raw card number and stays out of PCI scope. Your app only handles the reference and the result.

**Which payment methods and countries does Flutterwave support?**
Flutterwave clears payments in more than 30 countries, concentrated in Africa but reaching the US and UK diaspora, with around 15 methods including cards, bank transfers, mobile money, USSD, Apple Pay, and Google Pay. The available methods depend on the customer's country, so the hosted checkout shows the right ones automatically.

**Why is server-side verification necessary if the SDK returns success?**
Because the device callback can be spoofed and asynchronous methods confirm late. The SDK telling you a payment succeeded only means the user reached an end state; the authoritative answer comes from calling Flutterwave's verify endpoint on your server and matching the amount and currency. Webhooks cover mobile money and USSD that settle after the app closes.

**Can AI build the Flutterwave payment screen for me?**
It can build the UI well when you give it a real template to follow. Tools like Claude Code or Cursor produce a clean order summary and pay button from a free VP0 design, then you wire the SDK and the server verify call. The parts an AI should not invent are the security steps: key handling and server verification stay by the book.

## Frequently asked questions

### How do I add Flutterwave payments to a React Native app?

Install the official flutterwave-react-native SDK, render the PayWithFlutterwave button with your public key, a unique transaction reference, the amount, currency, and customer email, and let it open Flutterwave Standard for the actual payment. When it calls back, send the reference to your server, call the verify endpoint, and fulfil the order only after confirming status, amount, and currency. Build the surrounding UI from a free template.

### Does Flutterwave handle card security so my app stays PCI compliant?

Yes, because the card is entered inside Flutterwave's hosted checkout, not your app. The SDK opens Flutterwave Standard to capture the card and run 3D Secure, so your React Native code never sees a raw card number and stays out of PCI scope. Your app only handles the reference and the result.

### Which payment methods and countries does Flutterwave support?

Flutterwave clears payments in more than 30 countries, concentrated in Africa but reaching the US and UK diaspora, with around 15 methods including cards, bank transfers, mobile money, USSD, Apple Pay, and Google Pay. The available methods depend on the customer's country, so the hosted checkout shows the right ones automatically.

### Why is server-side verification necessary if the SDK returns success?

Because the device callback can be spoofed and asynchronous methods confirm late. The SDK telling you a payment succeeded only means the user reached an end state; the authoritative answer comes from calling Flutterwave's verify endpoint on your server and matching the amount and currency. Webhooks cover mobile money and USSD that settle after the app closes.

### Can AI build the Flutterwave payment screen for me?

It can build the UI well when you give it a real template to follow. Tools like Claude Code or Cursor produce a clean order summary and pay button from a free VP0 design, then you wire the SDK and the server verify call. The parts an AI should not invent are the security steps: key handling and server verification stay by the book.

---
*Published on the [VP0 Journal](https://vp0.com/blogs). Free to read, index and cite with attribution.*