How to Add eSewa and Fonepay to an iOS App Instead of In-App Purchase (A Nepal Developer's Guide)

"With AI vibecoding, it has never been easier to create and publish applications."

We agree with half of that sentence.

Creating an application? Yes, AI has made that dramatically faster. Publishing one? That is still the hardest part, and the App Store is where most teams feel it.

This is the story of a real project we delivered: a subscription app for a Nepali audience, an MVP built in about 30 days, and an App Store review that forced us to rethink how Nepali users actually pay. If you are searching for how to add eSewa to an iOS app for a digital goods application, or how to add a Nepali payment gateway instead of In-App Purchase, this guide covers the technical scope, the trade-offs, and the risks.

(We are keeping the client and the app anonymous. The lessons apply to any team building for Nepal.)

The Timeline: Google Play in a Week, Apple in a Fight

Our team built the MVP in roughly 30 days. Within the following week we submitted it to Google Play, and it was approved without any issue.

Then came the Apple App Store submission. Two days later, the review came back with a single line:

"Please implement In-App Purchase."

Our app sold digital goods (subscriptions unlocked inside the app). Apple's App Review Guidelines, section 3.1.1, require apps that unlock digital content, features, or subscriptions to use Apple's In-App Purchase. Physical goods and real-world services are treated differently, but our product was clearly digital.

We contacted App Review support several times. It did not change the outcome, and we implemented IAP.

Why In-App Purchase Was a Problem for Nepali Users

IAP is a fine system in markets where nearly everyone pays by international card. Nepal is not that market. For this client, IAP created three real business problems:

• Payment access: Most of the target users pay through wallets and local rails such as eSewa, Fonepay, Khalti, or ConnectIPS, not international cards or Apple ID balance.
• Dual pricing: The client had to maintain separate price points for Android and iOS, because Apple's commission and tier pricing don't line up with local wallet pricing.
• Conversion: The app was growing, but paid conversion among Nepali users was held back by a checkout that didn't fit how they pay.

The app was growing. The client's operational headaches were growing faster.

What "Nepali Payment Gateway Instead of In-App Purchase" Actually Involves

Here is the technical scope of adding eSewa and Fonepay to a mobile app.

1. Payment initiation

Your backend creates an order and generates a signed payment request. For eSewa's ePay v2, that means building the request fields (amount, transaction UUID, product code, success and failure URLs) and signing them with HMAC-SHA256 using your merchant secret. Fonepay follows a similar signed-request model. Never sign requests inside the mobile app; keep secrets on the server.

2. Hosting the checkout

The user completes payment on the gateway's page. On iOS, that usually means an in-app browser (SFSafariViewController or ASWebAuthenticationSession) or a WKWebView. Fonepay also supports QR-based flows, where the user pays from their own banking or wallet app.

3. Returning to the app

After payment, the gateway redirects to your success or failure URL. You then bring the user back into the app using a universal link or a custom URL scheme.

4. Server-side verification (the step people skip)

Never trust the redirect alone. Your backend must call the gateway's transaction status API (or verify the signed callback) before granting anything. Check the amount, the transaction ID, and the status.

5. Entitlement management

Once a payment is verified, your backend grants the subscription. Build this properly:

• Idempotency, so a repeated callback never double-grants or double-charges.
• Order state machine: created, pending, paid, failed, expired.
• Reconciliation jobs that catch payments made while the user's connection dropped.
• Renewals: eSewa and Fonepay are not auto-renewing card subscriptions, so you need reminders and a renewal flow.
• Refund and dispute handling, plus proper records for tax and audit.

6. Compliance basics

Include a clear privacy policy inside the app on its own screen, terms of service, and transparent pricing.

What We Did

We rebuilt our release approach in stages. We shipped a lean core version of the app first, with the privacy policy on a dedicated screen inside the app, using a separate Apple Developer account. Once that was live, a later version introduced eSewa and Fonepay as payment options.

The result for the client: Nepali customers who couldn't comfortably subscribe through IAP could now pay the way they already pay every day, and the business could grow in its core market.

Read This Before You Copy Our Approach

We would be doing you a disservice if we described this as risk-free. It isn't.

• Apple's rule is real. Guideline 3.1.1 requires IAP for digital goods in most cases. Nepal does not currently benefit from the external-payment allowances that exist in some regions (for example, specific US and EU provisions), so the exemptions don't help a Nepal-only audience.
• Adding payment features after review can be treated as a violation. Apple expects the app you submit to match the app users get. If Apple concludes that functionality was added in a way that circumvents review, the consequences can include removal from the App Store or termination of the developer account, and Apple can associate related accounts.
• Your client carries the risk, not just you. A rejected update is an inconvenience. A terminated account can mean an app, its users, and its revenue disappear.

Before you choose this route, talk openly with your client about the risk, and check the current App Store Review Guidelines, since Apple's rules and regional allowances change.

Legitimate Options to Evaluate First

• Reclassify honestly. If part of your product is a physical good or a real-world, person-to-person service, guideline 3.1.3 exemptions may apply. Only use this if it is genuinely true.
• Use IAP on iOS and local gateways on Android and web. Many teams price iOS slightly higher to absorb Apple's commission, and route price-sensitive Nepali users to a web checkout.
• Web-based purchase, app as the client. Let users buy on your website with eSewa or Fonepay, then sign in to the app. Check current guidelines on how the app may (and may not) point to that purchase.
• Talk to Apple through the formal appeals process with your specific case, before committing to a workaround.

Key Takeaways

1. AI makes building apps faster. It does not make App Store approval easier.
2. Apple requires IAP for most digital goods, and support conversations rarely change that.
3. In Nepal, local rails (eSewa, Fonepay, Khalti) often match users' real payment behavior better than IAP does.
4. A production payment integration means signed requests, server-side verification, idempotency, reconciliation, and renewal handling, not just a payment button.
5. Any strategy that touches Apple's review process carries account-level risk. Decide with your client, eyes open.

Need Help Building for the Nepali Market?

At MarginTop, we believe problems will always come up. What matters is how you pursue them and solve them, with the ease of the client and their customers as the final goal. If you are planning a mobile app for Nepali users and want a team that has handled payments, store submissions, and MVP delivery, talk to us.