# Fawry Payment Gateway UI for Mobile (Integration Guide)

> By Lawrence Arya, Founder & CEO of VP0. Published 2026-05-30, updated 2026-06-02. 4 min read.
> Source: https://vp0.com/blogs/fawry-payment-gateway-ui-mobile

The UI's job is to make a pay-later, by-code flow feel clear and trustworthy.

**TL;DR.** Fawry supports card payments and a reference-code flow where users pay later in cash or via their bank. Design the payment-method and reference-code screens from a free VP0 design: a copyable code, how-to-pay steps, and a live pending state. Route everything through Fawry's certified gateway and never store card data.

Fawry is one of Egypt's largest payment networks, and many local apps need a checkout that supports it: card payments plus Fawry's signature reference-code flow, where the user gets a code and pays in cash at a kiosk or via their bank app. The short answer is, design the payment-method and reference-code screens from a free VP0 design, and integrate through Fawry's certified gateway, never handling raw card data yourself. The UI's job is to make a slightly unusual flow (pay later, offline, by code) feel clear and trustworthy.

## Why the reference-code flow needs careful UI

Most checkout UI assumes instant card payment, but Fawry's strength is supporting users who pay in cash or through their bank using a reference code, which is common where many people are underbanked. That means your UI must handle a payment that completes later, outside the app: show the reference code clearly, explain where and how to pay it, and reflect a "pending until paid" state that updates when the gateway confirms. Security is non-negotiable for payments: roughly [71%](https://cybernews.com/security/) of mobile apps were found to leak sensitive data, so route everything through [Fawry](https://fawry.com/)'s certified gateway and never store card details in your app.

## How to build the Fawry checkout UI

VP0 is a free iOS design library for AI builders. Pick a checkout and a confirmation/status design, copy the links, and have Cursor or Claude Code build them in [React Native](https://reactnative.dev/) or SwiftUI: a payment-method screen (card or pay-by-code), and for the code flow, a clear screen showing the reference number, the amount, an expiry, and step-by-step "how to pay" instructions, plus copy and share buttons. Wire it to Fawry's gateway SDK or API so the actual charge and status come from them. Show a pending state and update it on confirmation (via webhook or polling your backend). Offer [Apple Pay](https://developer.apple.com/apple-pay/) too where it fits. For the standard card checkout, see [eCommerce checkout screen UI mobile](/blogs/ecommerce-checkout-screen-ui-mobile/).

## Fawry checkout building blocks

Here is what each part should do.

| Part | What to get right |
|---|---|
| Method choice | Card or pay-by-code, clear |
| Reference code | Large, copyable, with amount |
| How to pay | Step-by-step, where and how |
| Pending state | "Awaiting payment," updates live |
| Confirmation | Clear success when paid |

## A worked example

Say a user buys a course in your app and chooses pay-by-code. Your VP0-designed screen shows the Fawry reference number large and copyable, the amount, an expiry time, and short instructions ("Pay at any Fawry outlet or in your banking app using this code"). The order sits in a clear "Awaiting payment" state; when Fawry confirms via your backend, it flips to a success screen and unlocks the course. The card path, by contrast, completes immediately through the gateway. Never touch raw card data. For a receipt the user can keep, see [Apple Wallet pass UI template free](/blogs/apple-wallet-pass-ui-template-free/); for presenting identity at payment, [wallet verifiable credential UI template](/blogs/wallet-verifiable-credential-ui-template/).

## Common mistakes

The most common mistake is forcing an instant-card mental model onto the reference-code flow, leaving users confused about a payment that completes later. The second is a reference code that is hard to read, copy, or find again. The third is no clear pending state, so users do not know the order is waiting on their payment. The fourth is handling card data directly instead of through Fawry's certified gateway. The fifth is not updating the status when payment confirms, stranding a paid order in "pending."

## Key takeaways

- Fawry supports card payments and a reference-code flow where users pay later in cash or via their bank.
- The UI must make the pay-by-code flow clear: a copyable code, how-to-pay steps, and a live pending state.
- Route all payments through Fawry's certified gateway and never store card data (around 71% of apps leak).
- Update the order status on confirmation so a paid order never stays stuck in pending.

## Frequently asked questions

How do I design a Fawry payment gateway UI for mobile? Build a payment-method screen and a reference-code screen from a free VP0 design: show a large copyable code, the amount, an expiry, and how-to-pay steps, plus a pending state that updates on confirmation. Integrate through Fawry's certified gateway.

What is special about the Fawry flow? It supports paying later in cash at an outlet or via a bank app using a reference code, not just instant card payment. The UI must make that delayed, offline completion clear with a pending state.

Do I handle card details in the app? No. Route all payments through Fawry's certified gateway (or Apple Pay where it fits) and never store raw card data, because payment data is exactly what leaks most often.

How does the order know when a code is paid? Through Fawry's confirmation to your backend (webhook or polling). Update the order from pending to success on that confirmation so the user gets access promptly.

## Frequently asked questions

### How do I design a Fawry payment gateway UI for mobile?

Build a payment-method screen and a reference-code screen from a free VP0 design: show a large copyable code, the amount, an expiry, and how-to-pay steps, plus a pending state that updates on confirmation. Integrate through Fawry's certified gateway.

### What is special about the Fawry flow?

It supports paying later in cash at an outlet or via a bank app using a reference code, not just instant card payment. The UI must make that delayed, offline completion clear with a pending state.

### Do I handle card details in the app?

No. Route all payments through Fawry's certified gateway (or Apple Pay where it fits) and never store raw card data, because payment data is exactly what leaks most often.

### How does the order know when a code is paid?

Through Fawry's confirmation to your backend (webhook or polling). Update the order from pending to success on that confirmation so the user gets access promptly.

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