Madar AI
EN TR AR
Start free →
← Back to blog
Practitioner

The MENA founder's guide to Iyzico vs Stripe vs Apple/Google IAP for subscription apps

When to use each payment rail in Turkey, KSA, UAE, and Egypt: decline rates by country, refund flow differences, Iyzico's 3DS quirks, IAP's platform tax, and where Tabby and Tamara fit as supplementary BNPL rails. Honest trade-offs, no vendor hype.

By the Madar AI team·May 19, 2026·7min read

The MENA founder’s guide to Iyzico vs Stripe vs Apple/Google IAP for subscription apps

A subscription app launching in Turkey, KSA, UAE, and Egypt has four real choices for taking money: Apple/Google in-app purchase, Stripe, Iyzico, and a BNPL supplement like Tabby or Tamara. Most teams default to whichever rail their previous app used and only discover the trade-offs months later when conversion data lands.

This post is the honest comparison. No vendor is going to publish this trade-off table because it makes their competitors look reasonable in places where the competitor genuinely is. We have run audits on apps using every combination of the four, and the right answer depends heavily on which country dominates your install mix and what content type you ship.

The rails, briefly

Apple/Google IAP — In-app purchase via App Store or Play Store. Mandatory for most digital subscription content per platform rules. Takes 30% (15% for apps under $1M annual revenue and for the second year of subscriptions). The user pays in App Store/Play Store credit and the platform handles billing, retries, refunds, and tax. Smoothest UX, highest fees, locked into platform billing.

Stripe — Web-based subscription billing. Used when you have a web-side subscription path (think: paywall on your marketing site, or web app companion). Standard fees roughly 2.9% + $0.30 per transaction in the US; international rates and currency conversion fees add up. Globally well-built, but card decline rates with MENA-issued cards on Stripe’s international rails can be meaningfully higher than the headline figure suggests.

Iyzico — Turkey-native payment processor. Supports Turkish card schemes (Troy, Bonus, Maximum, Axess, World, CardFinans) with native installment options (taksit). Roughly 2.95% + small fixed fee per transaction, in lira. 3DS flows are tuned for Turkish bank quirks. Owned by PayU Global since 2019 but still operates as a Turkey-specialised stack.

Tabby / Tamara — Buy-now-pay-later supplements. Tabby is regional, Tamara is KSA-headquartered. Both let users split a payment into 3 or 4 instalments without interest if paid on time. Take a percentage of the transaction from the merchant (varies by partner agreement, generally low single digits). Useful as a supplementary rail at the paywall, not a primary one.

By country

Turkey

  • Primary: Iyzico for web subscriptions.
  • Secondary: Apple/Google IAP for the in-app subscription path that platform rules require.
  • Don’t lead with: Stripe alone. Card decline rates with Turkish-issued cards on Stripe’s international processing are noticeably higher than on Iyzico’s native Turkish processing. Stripe’s not broken in Turkey — Iyzico is just structurally better-positioned for the same transaction.
  • Taksit (instalment) consideration: Iyzico’s native taksit support is genuinely valuable in Turkey. A $99 annual plan offered as “12 ay x 100 TL” with no interest converts at noticeably higher rates than the same plan offered as a single up-front payment. Stripe does not natively support Turkish taksit.

Saudi Arabia (KSA)

  • Primary in-app: Apple/Google IAP. Apple Pay penetration is high in KSA and the UX is smooth.
  • Primary web: Stripe with explicit Mada acceptance enabled, or a Mada-native processor. The Mada national scheme handles a meaningful share of Saudi card transactions, and routing Mada through international rails has higher decline rates than routing it natively.
  • Supplementary: Tabby and Tamara on annual plans. “Split $99 into 3 payments of $33” converts at materially higher rates than “$99 today” in KSA for the annual paywall.
  • Don’t: Use Iyzico for KSA volume. Iyzico is Turkey-native and Saudi card acceptance is not its strength.

UAE

  • Primary in-app: Apple/Google IAP. iOS share in UAE is high; Apple Pay UX dominates the subscription path.
  • Primary web: Stripe works well in UAE. The Emirati card ecosystem is internationally connected and Stripe’s standard processing handles it cleanly.
  • Supplementary: Tabby in UAE for annual plans. The behaviour pattern is similar to KSA — BNPL converts disproportionately well on higher-ticket annual subscriptions.

Egypt

  • Primary in-app: Apple/Google IAP, but with the caveat that iOS share in Egypt is much lower than the Gulf, so IAP captures a smaller share of total subscribers.
  • Primary web: Stripe, but with realistic expectations on decline rates. Egyptian-issued card decline rates on international rails are meaningfully higher than Gulf or Turkish figures.
  • Critical supplementary: Local mobile wallets (Vodafone Cash, Orange Money) and Fawry for cash-via-network payment. A non-trivial share of Egyptian subscribers do not have a card-on-file experience that works smoothly with international Stripe processing. Without an alternative rail, you are leaving Egyptian subscribers stranded at the paywall.

The fee math actually matters

Apple/Google take 30% (or 15% under specific conditions). Stripe takes ~3%. Iyzico takes ~3%. For a $9.99 monthly subscription:

  • IAP at 30%: you net ~$7.00
  • IAP at 15%: you net ~$8.49
  • Stripe at 3%: you net ~$9.69
  • Iyzico at 3%: you net ~$9.69

If you can legitimately offer a web-based subscription path (platform rules permit it for certain product categories), the math says route as much volume as possible through Stripe or Iyzico. The catch is that the platform-rule allowance depends on what content your app ships, and Apple has tightened enforcement of the in-app-purchase requirement substantially since 2024. Most consumer subscription apps cannot legally route around IAP.

The realistic optimisation: maximise IAP UX (it converts higher than web), but ensure web/Iyzico routes exist where platform rules allow them, especially for annual plans where the saving on platform fees materially affects gross margin.

Refund flow differences

Apple/Google IAP refunds: Issued by the platform, not by you. Time-to-refund is typically 24-72 hours. You don’t control timing or messaging. Refund volume affects your App Store and Play Store standing in ways that are not always transparent.

Stripe refunds: Issued by you, processed in hours. Full control over timing and customer messaging. Stripe also exposes a real dispute/chargeback flow that you have to actively manage.

Iyzico refunds: Processed quickly but Turkish consumer law mandates a 14-day right of withdrawal on digital subscriptions for first-time purchases. Your refund flow must respect this; a “no refunds” policy is not legal for first-time Turkish subscribers within the 14-day window.

Tabby/Tamara refunds: Complex — the user owes Tabby/Tamara, and a refund unwinds back through them. Plan for 5-10 days end-to-end and have a clear communication template ready.

Iyzico’s 3DS quirks (the practical bits)

Three things about Iyzico’s 3DS flow that catch first-time integrators:

  1. OTP timing varies by Turkish bank. Some banks send the OTP in 5 seconds; some take 30+ seconds. Build a UX that doesn’t time out the user before the OTP arrives. Default setTimeout values designed for Stripe US flows will silently kill conversions.
  2. Some banks add an “approval delay” step. A small share of transactions go through a second-step bank approval that adds 30-60 seconds before clearing. The transaction looks pending in your system while it is still resolving. Don’t show “payment failed” until you have a definitive Iyzico response — show “processing” with a longer patience window.
  3. Taksit number affects bank approval rates. A 12-month taksit option will be declined by some banks for users near their credit limit; a 3-month or 6-month option succeeds where 12 fails. Offer multiple taksit periods at the paywall, default to the safer ones.

The right combination, by country

A pragmatic combination matrix that we see work well across audits:

  • Turkey: Iyzico (primary web) + IAP (in-app, where required) + Papara for some younger user segments. No Stripe primary.
  • KSA: IAP (primary in-app) + Stripe with Mada acceptance (web) + Tabby/Tamara on annual plans (supplementary).
  • UAE: IAP (primary) + Stripe (web) + Tabby (annual plans).
  • Egypt: IAP (where reachable) + Stripe (with realistic decline expectations) + local mobile wallet rail (critical for capture). Fawry as a cash-via-network supplement for users without active cards.

A team running a single global Stripe-only stack is leaving 15-30% of MENA revenue on the table compared to a team running the right rail per country. The work to add a second processor is not trivial, but it pays for itself within a quarter in our audits.

How Madar surfaces this

Madar AI connects to your payment processors and looks at decline-rate patterns by country, by card scheme, by transaction size, and flags the cases where a different rail would close the gap. It does not recommend a processor; it tells you where your current setup is leaking and which fix has the highest expected revenue lift.

If you want to see your specific payment-rail leakage, the live demo includes the payments audit in the first 10 minutes.