App Store In-App Purchase Rules for Algerian Apps

In 2021, at an invoicing startup I worked with, the CEO came to me after Apple had rejected the iOS app twice. The question was simple: how do you publish an app on the App Store and Google Play when your clients will never pay through Apple's or Google's in-app purchase? I took over the submission and got it through.

Since then I have published several Algerian apps on both stores, and none of them uses in-app purchase. Some never take a dinar inside the app at all: they support a service the customer pays for offline, in cash, by bank transfer, by cheque or at the post office. Others take CIB and Edahabia card payments through SATIM, inside the app.

Both setups sit on the wrong side of the default assumption the stores make, which is that money changes hands inside the app, through the store. This guide covers only that question: what Apple's and Google's in-app purchase rules actually require, and how to get an app whose payments run on Algerian rails approved on both stores, without hiding anything from the reviewer.

Why in-app purchase does not work for Algerian customers

A common belief is that Algerian developers cannot sell through the stores at all. That is not true. Google Play has supported merchant registration in Algeria since 2018, with payouts in USD (Google's list of supported locations).

The real problem sits on the other side. Store billing charges a card attached to the user's Apple Account or Google account, an international Visa or Mastercard in practice (Apple's payment methods by country). Look at what Algerians actually carry. At the end of August 2026 there were about 23 million payment cards in circulation: roughly 19 million Edahabia cards from Algérie Poste and a little over 4 million CIB cards from the banks, according to GIE Monétique figures (Algérie Eco, October 2026). Both are domestic networks. Neither can be added to an Apple or Google account.

International cards do exist, and most banks sell them, but they are a different product with a different purpose:

• They run on a foreign-currency account. You open a dinar account and a euro account at the same bank, and the card draws on the euros. Entry conditions vary by bank, from 8,000 DA plus €100 at BNA to 25,000 DA plus €500 or more at some private banks, with yearly fees between roughly 3,000 and 14,000 DA (Zoom Algérie, August 2026).
• They are built around travel. Since 19 July 2026 the yearly €750 travel allowance for adults is loaded onto these cards, and the Bank of Algeria allows online purchases with it only when they relate to the trip, such as flights and hotels (Algérie 360).
• They take time to get. Demand jumped with the new allowance, and customers report waiting months for delivery (Maghreb Emergent, October 2026).

No public figure counts how many of these cards are active, but the shape is clear. Paying for a local, dinar-priced service through the store means a customer spending euros from their own foreign-currency savings, on a card designed for trips abroad. A few of your users can and will. Your market will not. If your app can only be paid for through the store, most of the people you built it for cannot pay you.

So the question is never "how do I avoid the store's commission". It is "which rule lets my business keep its own payment rails, and how do I show the reviewer that I am inside that rule".

Apple guidelines 3.1.1 and 3.1.3 vs the Google Play payments policy

Both stores draw the same line, in different words: if the money unlocks something consumed inside the app, the rules point you to store billing. If it pays for something that happens outside the app, store billing must not be used.

What the payment is for	Apple App Review Guidelines	Google Play Payments policy	Local rails allowed?
A real-world good or service consumed outside the app (accounting work, delivery, a consultation, an event ticket)	3.1.3(e): you must use a method other than in-app purchase	Physical goods and physical services must not use Play billing	Yes
Nothing is sold in the app; it supports a service the customer pays for elsewhere	3.1.3(f): allowed if there is no purchasing inside the app and no call to action to buy outside	No in-app purchase flow, no payment links	Yes, but no buy button and no "pay on our site"
A live session between one teacher (or doctor, or coach) and one person	3.1.3(d): other methods allowed for one-to-one only	Not carved out explicitly	Apple: yes for 1:1. Google: a risk
Live sessions for a group, one-to-few or one-to-many	3.1.3(d): in-app purchase	Billing required	Not by the letter of the rules
Digital content or features: recorded courses, premium tiers, content subscriptions	3.1.1: in-app purchase	Billing required ("education" subscriptions are named explicitly)	Not by the letter of the rules
Access sold to an organisation for its staff or students	3.1.3(c) enterprise: users can access what the organisation bought	Case by case	Often yes

Sources: Apple App Review Guidelines, section 3.1 and Google Play Payments policy.

Two details that trip people up:

• Apple's recent openings are US-only. Since 2025 the guidelines let apps on the United States storefront link out to web checkout. Your Algerian storefront does not get that. Outside the US, an app in section 3.1.3 still "cannot, within the app, encourage users to use a purchasing method other than in-app purchase". Google's equivalent programmes (alternative billing, external content links) are also tied to specific regions.
• Google does not let you point at another payment method either. The Payments policy forbids leading users to a non-Play payment method through the store listing, in-app promotions, webviews, buttons or links, outside the exempt categories.

Be honest with yourself in this table. Almost every payment problem in review comes from picking the row you want instead of the row you are in.

Model A: an app that supports a service paid offline (guideline 3.1.3(e))

This is the cleanest case, and the one most Algerian B2B apps fall into. The customer pays for a service delivered in the real world: professional work, a subscription to an office's services, goods that get delivered. The payment happens the traditional way, outside the app, and the app is the tool the customer uses alongside that service.

That is what Apple's 3.1.3(e) and 3.1.3(f) describe. For a real-world service, Apple does not just allow local payment, it requires it. Our apps built this way were approved without any discussion of payments. What made that easy:

• The app is free in the store, and has no purchase screen and nothing that looks like a paywall. Features the customer has not paid for are simply not part of their account; the app does not show them locked behind a price.
• The listing says it in plain words, in every listing language: the app is free, and the service is paid directly to the provider, the usual way. One sentence in the description is enough.
• Renewal happens outside the app. The office, the sales team or the website handles it. No "renew" button, no price list, no "pay on our website" link.
• The review notes repeat it, with the guideline number (template below).

The trap in this model is the friendly shortcut: a "contact us to upgrade" button, a WhatsApp link next to a locked feature, a price in a banner. Each of them turns a service companion into an app that sells inside itself without store billing.

Model B: CIB and Edahabia payments through SATIM inside the app

Some of our apps take card payments in the app: the user taps pay, lands on SATIM's payment page, pays with CIB or Edahabia, and comes back to a receipt. If you have not integrated SATIM yet, the SATIM CIB and Edahabia integration guide covers certification, the bank contract and the API. Apple's in-app purchase cannot charge these cards, so there is no store rail to route the payment through, and nothing for the store to take a cut of. Our apps built this way were approved on the first submission, on both stores. The condition was well-written review notes: every one of them explained the payment flow before the reviewer had to ask.

Go in clear-eyed about why, because the written rule is stricter than the experience. Apple's 3.1.1 and Google's Payments policy decide what must use store billing based on what is being sold, not on which cards the store can charge. A card payment for a real-world service, or for a one-to-one live session, is on solid ground. A card payment that unlocks digital content inside the app is the row where the letter of the rules points to in-app purchase, and where approval depends on how the reviewer reads what you sell.

How to set up Model B so the reviewer reads it correctly:

• Name what the payment buys. On the checkout screen and in the listing, describe the service ("monthly accounting follow-up", "a session with your teacher"), not a feature unlock ("Premium", "Pro plan").
• Show the price in dinars and the payment methods by name: CIB, Edahabia, and any offline option such as a CCP receipt. It tells the reviewer in one glance why store billing is not on the screen.
• Send the user to SATIM's own payment page and back. Do not rebuild a card form inside the app; the redirect to the gateway's page is what a reviewer expects to see for a card payment.
• Never show a different flow to the reviewer. No build that hides prices during review and shows them after. That is the one move that turns a policy discussion into an account problem.

If you sell digital content and want a fallback ready before the review, not after a rejection, you have two: add in-app purchase alongside your local rails (compliant, but it only reaches the few users willing to pay from a euro account), or ship the store build as a Model A companion where users pay on the web or offline and the app only gives access to what they already own (compliant, but it removes the main flow for the users the app was made for).

Demo account: let the reviewer see the payment without paying

A reviewer in Cupertino or Dublin cannot pay with a CIB card, and you do not want them paying anyway. Give them two things:

• An account where the purchase is already done. A demo account on production with an active subscription or a settled invoice, so the reviewer sees what a paying customer gets. Google's rule for demo credentials, from one of our rejections, applies here too: "accessible at all times, reusable, and valid regardless of user location", and written in English characters only.
• A description of the payment step. In the review notes, say what screen they will reach if they tap pay, which gateway it is, and that it only accepts Algerian domestic cards. For Model A, say there is no payment step in the app at all.

App Store Connect and Play Console declarations

The payment model also shows up in forms you fill once and forget. Answer them the same way your review notes describe the app:

• No in-app purchase products. Do not create in-app purchase items in App Store Connect or Play Console "just in case". An item configured but not reachable in the app is a question from the reviewer.
• Google's content rating questionnaire asks whether users can purchase digital goods. Answer for what the app really does: the answer adds an "In-App Purchases" descriptor to the rating, and it should match your model.
• Google's financial features declaration. A Model A or Model B app that takes or tracks payments for its own service is not a financial services app, and can declare it offers no in-scope financial features. If your app does offer financial services, Google requires the developer account to be an organisation; one of our apps was rejected for publishing from the wrong account type.

App Store Connect review notes templates

The review notes field in App Store Connect (and the app access instructions in Play Console) is the one place you explain your payment model before a reviewer decides. Keep it short, cite the guideline, and describe what the reviewer will see.

Model A, service paid offline:

textCopy
Payments: the app is free and contains no in-app purchase. It supports a
professional service that clients pay for outside the app (a real-world
service), invoiced and settled offline by cash, bank transfer, deposit or
cheque, as is standard in Algeria. No digital content or app functionality
is unlocked by payment, and the app contains no purchase screen or link.
Guideline 3.1.3(e).

Demo account: [email] / [password]. The account is an active customer with
sample data loaded.

Model B, CIB and Edahabia in the app:

textCopy
Payments: users pay for [the service, described plainly] in Algerian dinars
with CIB or Edahabia, Algeria's domestic card networks, through SATIM, the
national e-payment gateway. Tapping "Pay" opens SATIM's hosted payment page
and returns to a receipt. These domestic cards cannot be used with in-app
purchase, and most users in this market have no international card. [Offline
option, if any: users can also pay by CCP transfer and upload the receipt.]

Demo account: [email] / [password]. The account already has an active
[subscription / paid order], so no payment is needed to review the app.

Checklist: publishing an Algerian app with local payments

Before you submit an app with Algerian payments:

1. Which row of the table are you in? Write it down, with the guideline number.
2. Model A: no purchase screen, no locked feature with a price, no "contact us to pay" shortcut, anywhere in the app.
3. Model B: the checkout names the service, shows the dinar price and the payment methods, and redirects to SATIM's page.
4. The listing says how payment works in one plain sentence, in every language.
5. Nothing in the app or listing points to another payment method unless your row allows it.
6. No in-app purchase products configured that the app does not use.
7. Content rating and financial features declarations match your model.
8. Demo account on production with the purchase already done, English characters only.
9. Review notes: payment model, guideline number, what the payment step looks like.
10. The same build, the same prices and the same flow for the reviewer and for your users.

FAQ

Can Algerian developers sell apps on Google Play and the App Store? Yes. Google Play supports developer and merchant registration in Algeria, with payouts in USD, and an Algerian company can enroll as an organisation on both stores. The limit is on the buyer side: store billing needs an international card on the user's account.

Can I use CIB or Edahabia for in-app purchase? No. Apple's and Google's in-app purchase only charge payment methods attached to the user's store account, which in Algeria means an international Visa or Mastercard. CIB and Edahabia are domestic cards and can only be charged through SATIM, outside the store's billing.

Does Apple take a commission on CIB or Edahabia payments made through SATIM? No. The store only takes a commission on payments made through its own in-app purchase. A payment on SATIM's page goes from the customer's card to your bank account, and the store never sees it.

Is there an alternative to Apple in-app purchase for an Algerian app? Yes, when you sell something consumed outside the app. Guideline 3.1.3(e) requires a method other than in-app purchase for real-world goods and services, and 3.1.3(f) lets a free app support a service paid elsewhere. For digital content, in-app purchase remains the rule on paper.

Can my app link to my website so users pay there? Not on the Algerian storefront. Apple only allows links to web checkout on the United States storefront, and Google's Payments policy forbids leading users to another payment method outside the exempt categories.

Do I need in-app purchase for a service app, such as accounting, delivery or consultations? No, and Apple's guideline 3.1.3(e) says you must not use it. Payment for a service delivered outside the app goes through your own rails: SATIM, bank transfer, CCP or cash.

What should I write in the App Store review notes? Your payment model in one paragraph, the guideline number it falls under, what the reviewer will see if they tap pay, and a demo account where the purchase is already done. Templates for both models are above.

The principle

None of this is a trick. The stores' rules were written for markets where everyone has a card on their store account, and they already make room for businesses that are not. Your job is to find the row you are really in, build the app so it stays inside that row, and say so to the reviewer before they have to ask. A reviewer who has to guess how your app makes money will usually guess against you.