Most software says Arabic is "supported". The word hides more than it reveals, because for most products it means the strings were translated and the text was aligned right, and an Arabic reader tells that apart from real work in about a second.
This page is about the difference. What actually changes when a loyalty program runs in Arabic, across four surfaces: the card in the wallet, the join page, the dashboard, and the notification that reaches the lock screen. Everything here was read from this product's source, and every claim is cited to its file in the source note on this article. This page says nothing about any competitor's Arabic, in either direction.
Direction, not alignment
Alignment is a property of text: it starts on the right. Direction is a property of the page: everything in it starts on the right, so the order of elements inside a row inverts, edges and margins mirror, and the first thing the eye lands on is what used to be the end of the line.
The difference is practical rather than theoretical. A right-aligned page with Arabic strings is still an English page with Arabic text in it: the primary button is on the wrong side, the arrow points backwards, and progress fills the wrong way. In Fideliya the join page sets its direction to right-to-left when the language is Arabic, and sets the page language alongside it, on the container itself. Direction is declared once and everything inside inherits it.
The card in the wallet
A wallet pass is not a web page and you cannot impose a layout on it. What you control is the text on its fields, and in Fideliya that text is built from the card's language: member since, reward, visits, points, goal, next reward, latest update. This is an owner-forced path, deliberately separate from the one driven by the customer's device language, and the consequence is that the card reads in Arabic even on a phone its owner has set to English.
One detail here deserves to be known, because it is what hurried work gets wrong most often. The date on an Arabic Fideliya pass is printed with Latin digits and a pinned Gregorian calendar, because the locale tag in use forces both explicitly. The pinning matters because some ICU builds default Arabic to the Hijri calendar, which would print a year from a different era on a customer's card with no error surfacing anywhere. A locale that does not pin its calendar writes dates that are correctly formatted and wrong.
The notification
The short message that reaches the lock screen when a stamp is added or a reward is earned is built in the language of the card that customer holds. Choosing the language once, when the card is designed, is therefore what decides the language of every notification afterwards. There is no second setting for notifications to remember, which is the right shape: a setting that can contradict another setting eventually will.
The dashboard and the scanner
The dashboard is a different question, and it reads in the staff member's language rather than the card's. Those are two different readers: the customer reads the card, the staff member reads the screen at the counter, and tying them to one setting would force one of them into the other's language. The dashboard and scanner run in four languages on every plan, with no subscription gate on language at all.
One small engineering rule from the design system belongs here, because it is the kind of thing found by breaking rather than by reading. The cards that flip in the analytics view use an iOS-safe pattern: an independent rotation on each face, no preserved 3D on the parent, and the inactive face overlaid absolutely with backface visibility hiding it whichever way it turns. The other pattern, the elegant one, works everywhere except iOS, where it shows a mirrored face. The lesson generalises past flipping: direction, rotation and transitions are all places where something correct on a developer's screen falls apart on a customer's phone.
The decision that is made once
A Fideliya business runs one live card, on all three plans. So the card's language is one decision, carried by everyone who joins after it, rather than a preference held per customer.
| Surface | Whose language | Changeable later |
|---|---|---|
| The wallet card | The business, at design time | One decision per live card |
| The join page | Follows the card | With the card |
| The notification | Follows the card | With the card |
| Dashboard and scanner | Each staff member | Any time |
Some businesses read that as a constraint and some as a relief. The constraint is that a business serving customers in two languages cannot hand each of them a card in their own. The relief is that language never becomes a setting somebody forgets, leaving half the customers holding a card in a language nobody chose.
Choosing the language, in practice
- Choose the customer's language, not the office's. The card is read by the person standing in front of the counter and the dashboard by the person behind it, which is exactly why they are two settings.
- If your customers read in two languages, choose the language of the moment. The moment is the few seconds at payment when the QR code is offered and the card is added. Whatever language that sentence is said in is the language of the card.
- Open the join page on a phone before you print anything. Not the preview in the dashboard, the real link on a real handset. Look for direction rather than translation: where the button sits, and which way the arrows point.
- Look at a real card in a real wallet, not a screenshot. Add the card to your own phone and read the date on it. Latin digits and a Gregorian year mean you are seeing what your customers will see.
- Scan yourself once. The first stamp produces a notification, and that is the first Arabic your customer reads outside the card itself. Read it before anybody else does.
What you measure afterwards does not change with the language: the same seven numbers, under their Arabic names on the dashboard, are set out on the seven numbers a loyalty program should report, and the vocabulary used here is defined on the loyalty program glossary. What the notification channel can and cannot promise is on push notifications from a loyalty card.
What this page will not do
It says nothing about anyone else's Arabic. We have not run competitors' products in Arabic on real devices, and asserting that one of them "does not really support Arabic" would be an opinion with no measurement behind it, which is the same kind of sentence that gets written about us. When there is a dated measurement it will have a place here. Until then, nothing.
There is also no production figure on this page. Our last measurement carries no split by card language, so we have nothing to say about how Arabic cards perform against others, and we are not going to invent something to say.
Sources
Every product claim on this page was read from this repository's source on 6 September 2026 and is cited in the source note on this article to its file and to the symbol inside it: the card's language column, the four-language label table, the locale tag that forces Latin digits and a pinned Gregorian calendar, the join page's direction attribute, the notification built from the holder's language, the single active pass slot per business, the absence of any plan gate on language, and the iOS-safe flip rule. This page quotes no statistic, no figure from our own production, and no claim about any other product.
Fideliya is wallet-native loyalty program software for small businesses. Customers add a stamp or points card to Apple Wallet or Google Wallet in one tap, with no app to download and no account to create. Fideliya runs stamps, points, gift cards and referrals on one platform in English, French, Spanish and Arabic with full right-to-left support, and the free plan issues a real wallet pass for up to 20 customers. What the product does with languages is described on the languages page, and the plans are on the pricing page.