Selling online across the GCC means supporting the rails buyers actually use — KNET in Kuwait, mada in Saudi Arabia, Benefit in Bahrain, plus Apple Pay and cards — and each one is its own integration, credential set, and settlement report. ERPNext ships payment gateway plumbing (Payment Gateway Account, the Integrations app, generic Razorpay/Stripe/PayPal connectors) but nothing that speaks MyFatoorah's aggregator API. Without it, finance teams reconcile MyFatoorah settlements by hand, sales orders sit unpaid while a customer waits for a bank-transfer instruction, and no ERPNext document ever knows a payment succeeded until someone types it in. That manual gap is where cash gets stuck.

We build a proper Frappe app — myfatoorah_erpnext — installed on your bench alongside ERPNext, not a fragile script bolted onto Payment Request. It ships a MyFatoorah Settings single DocType (API key, live/test toggle, currency, default success/error URLs, encrypted secrets) and a MyFatoorah Transaction DocType that logs every InvoiceId, PaymentId, invoice reference, status transition, and settlement/refund record so every payment is a queryable, permissioned ERPNext document. Whitelisted methods wrap MyFatoorah's SendPayment, ExecutePayment, GetPaymentStatus, and refund endpoints, and its InitiatePayment call lets you present KNET, mada, Benefit, and Apple Pay in one API instead of routing per method. Because MyFatoorah is an aggregator, one connector covers many local gateways with a single credential.

Technically, the flow hangs off ERPNext's own documents. A hooks.py doc_events handler on Sales Invoice / Sales Order submit can generate a MyFatoorah payment link and email it to the customer via the standard notification pipeline; a Payment Request gets a working "pay now" URL instead of a dead one. Confirmation comes back through a webhook exposed as a whitelisted, signature-verified endpoint — we validate MyFatoorah's callback, then create the ERPNext Payment Entry against the invoice on the server side so status is never trusted from the browser. A scheduler event (scheduler_events in hooks.py) polls GetPaymentStatus for pending transactions and pulls settlement and refund updates, so reconciliation is automatic. Client scripts surface a "Pay via MyFatoorah" action and live status on the invoice form; role profiles and DocType permissions keep API keys and refund actions restricted to the roles you nominate. Recurring and embedded-checkout flows are wired the same disciplined way. Everything targets Frappe/ERPNext v15 and v16 and is delivered against your exact edition and workflow.

This is a build-to-order engagement, not a marketplace download. It starts with a short scoping call to confirm your MyFatoorah account type, the methods you need (KNET / mada / Benefit / Apple Pay / cards), the trigger documents, and your ERPNext version. We then build against a written scope, validate on a staging bench with UAT, and only cut over to production with a rollback plan agreed in advance. Typical delivery is one working week from confirmed scope, and you receive the full source and git repository so nothing is a black box.