Egyptian and MENA merchants running ERPNext hit the same wall: Paymob is the gateway their customers actually pay with — cards, Vodafone/Orange/Etisalat wallets, and bank installments — but ERPNext core has no concept of Paymob. Out of the box you get manual Payment Entry records reconciled by hand against a separate Paymob dashboard, no way to send a customer a pay-now link from a Sales Invoice, and no automated confirmation when money actually clears. The built-in Payment Gateway framework covers a handful of global processors; Paymob's unified intention API, HMAC-signed callbacks, and multi-country acceptance are simply not in it.

We build a proper Frappe app (erpnext_paymob) — a versioned module with its own DocTypes, not a pile of loose customizations. A Paymob Settings single DocType holds your API key, integration IDs, iframe/checkout config, and HMAC secret (secrets stored via Frappe's Password fieldtype, never in plain fields). The core flow: a whitelisted server method calls Paymob's intention/order API to create a payment and returns a hosted unified-checkout URL or a generated payment link, which we surface on the Sales Invoice and via the customer portal. When the shopper pays, Paymob POSTs to a webhook endpoint we expose as a @frappe.whitelist(allow_guest=True) method that first recomputes and verifies the HMAC signature before trusting a single field — on a valid, non-duplicate callback it creates and submits the matching Payment Entry, links it to the invoice, and updates status idempotently so a retried webhook never double-posts.

Technically it lives where ERPNext expects it. hooks.py doc events fire the checkout logic on Sales Invoice submit; a Payment Request-style flow drives link generation; a client script adds the "Pay with Paymob" action in the invoice UI; scheduler events (scheduler_events in hooks.py) run a reconciliation sweep that queries Paymob for any transaction whose webhook was missed and back-fills the Payment Entry. Refunds are handled through a server action that calls Paymob's refund/void endpoint and writes the reversal back into ERPNext with an audit trail. Access is governed by a dedicated role and role-profile so only authorized users can view credentials or trigger refunds, and every gateway call is logged. Multi-country support means we wire the correct integration IDs and currency handling for Egypt, the GCC market you operate in, and Pakistan, rather than assuming a single locale.

Because this is build-to-order, nothing is a black-box download. After a short scoping call we confirm exactly which payment methods, currencies, invoice/portal touchpoints, and ERPNext version (v15 or v16) you need, then build against a staging copy of your instance. You get the full app source in a git repository, install and configuration on your bench, UAT on staging with live Paymob test credentials, and a documented rollback path before we touch production. Typical delivery is one working week from confirmed scope, followed by a post-go-live support window while real transactions flow.