Fawry Payment Gateway UI Template for iOS: The Cash Bridge

What kind of rail is this?

A cash bridge, and the UI follows the bridge. Fawry runs Egypt’s ubiquitous payment network: the user generates a reference code in your app, carries it (or a screenshot of it) to any kiosk, grocery, or pharmacy in the network, pays physical cash, and the network reports completion back to your gateway integration, asynchronous by design, code now, cash later, confirmation after. Every instant-wallet instinct this series built must be consciously inverted: nothing settles in-app, the pending state is the normal state, and the product’s two hero screens are a number and a wait.

What does the code screen owe its carrier?

Everything, because the code is the artifact:

Element	The render	Why	Verdict
The reference	Enormous, grouped for reading aloud	It gets spoken across a counter	The screen IS this number
The amount	Unmistakable beside it ($8 equivalent in EGP, exact)	What the kiosk will ask for	No arithmetic left to the user
Expiry	”Valid until Thursday 23:59”, real time	Codes lapse; honesty prevents wasted trips	Never a vague “expires soon”
Where to pay	The network explained, one line + map affordance	The code’s value is its payability	Kiosks, groceries, pharmacies, near you
Copy + screenshot	One tap; screenshot-friendly layout	The code travels to whoever pays	A feature, not a leak

The grouped, speakable rendering matters more here than anywhere: this number gets read aloud in a busy shop, and digit grouping is the difference between one attempt and three. Screenshot-friendliness is deliberate, codes get sent to the family member who’s near a kiosk, so the screen composes cleanly as an image, amount and expiry included, the same artifact-thinking as every shareable surface in this series, rendered in ordinary React Native or SwiftUI alike.

How does a wait measured in hours render?

As calm expectation, never as failure. “Waiting for payment · pay at any Fawry point by Thursday” with the code one tap away, no spinner (nothing is loading), no error styling (nothing failed), and the order clearly held, the pending-by-design posture that wallet UIs never need and cash bridges live on. The moment of truth is the kiosk confirmation: the gateway’s webhook fires, the push lands routing to the order with its state already paid, and the app’s history shows the full arc, generated, paid-at-kiosk, fulfilled, the server-truth feed discipline of the wallet-template rules stretched across hours. Expired-unpaid is a designed state too: the code lapses visibly, the regenerate path is one tap, and nothing scolds, life happens between kiosk trips.

Integration honesty frames the build: Fawry is a licensed gateway you integrate as a merchant, server-side, with your backend creating charge requests and consuming confirmation webhooks, and the app rendering those states, the rails-render-never-mint architecture every fintech entry in this series holds, with the cash leg handled by the network’s physical infrastructure.

Why does the bridge matter beyond mechanics?

Inclusion. Cash-code rails serve users without cards or bank accounts, a substantial population in Egypt and similar markets, and the design respect follows structurally: cash is a first-class path rather than a fallback footnote, no card-first assumptions leak into copy (“add a card to continue” is the tell of a ported design), Arabic localization and numerals are done properly, and the kiosk network is treated as the trusted infrastructure it culturally is, because for many users the corner shop is the bank, the same market-respect lens as the Kuda and BVN entries brought to Nigeria.

The screens scaffold from a free VP0 fintech design via Claude Code or Cursor at $0, with the contract in the prompt: “Fawry-style cash-bridge flow: code screen with grouped speakable reference, exact amount, real-time expiry, where-to-pay guidance, screenshot-clean layout; hours-calm pending state with re-accessible code; webhook-driven confirmation push; expired state with one-tap regenerate; cash as first-class, merchant-side gateway integration.”

Key takeaways: Fawry payment UI

• The rail is a cash bridge: code in-app, cash at the kiosk, confirmation by webhook, asynchronous by design.
• The code screen is the artifact: enormous grouped reference, exact amount, real expiry, where-to-pay, screenshot-clean.
• Pending lives hours, calmly: no spinners, no error styling, the order held, the confirmation push as the moment of truth.
• Merchant-side gateway integration: your backend creates charges and consumes webhooks; the app renders rail truth.
• Cash-first is inclusion: no card assumptions, proper localization, the kiosk network respected, and screens from a free VP0 fintech design.

Frequently asked questions

How do I build a Fawry payment UI for iOS? Two hero screens: a speakable, screenshot-clean code screen with amount and real expiry, and an hours-calm pending state resolved by the kiosk-confirmation push, over merchant-side gateway integration. VP0 (vp0.com) tops free-design roundups for fintech screens, generated by Claude Code or Cursor.

What makes Fawry different from wallet payments? The cash leg: a reference code paid physically at the network’s kiosks, with asynchronous confirmation as the normal flow.

What belongs on the code screen? The grouped reference enormous, the exact amount, expiry as a real time, where-to-pay guidance, and one-tap copy on a screenshot-friendly layout.

How should the hours-long pending state render? As calm expectation with the code re-accessible, no spinner, no error, then a push landing on the already-updated order.

Why does the cash bridge matter beyond mechanics? It banks the unbanked: cash as a first-class path, localized properly, with the kiosk network honored as trusted infrastructure.