Middle East ERPNext merchants keep hitting the same wall: ERPNext core ships Stripe, PayPal, Razorpay, Braintree and a couple of others out of the box, but nothing for HyperPay — the acquirer most Saudi, Jordanian and UAE banks actually settle through. That means no mada support, no Apple Pay or STC Pay at checkout, no local 3-D Secure 2 flow, and no clean way to reconcile HyperPay settlements against your Payment Entry and Sales Invoice records. Teams end up bolting on a hosted payment page in a separate system and re-keying transactions, which breaks the audit trail ERPNext is supposed to give you.

We build a proper Frappe app — erpnext_hyperpay — that registers HyperPay as a first-class Payment Gateway inside ERPNext rather than a script pasted into a Web Form. It ships a HyperPay Settings DocType (single) holding your entity IDs per brand (mada, VISA/MASTER, Apple Pay, STC Pay), access token and mode, with credentials encrypted via Frappe's get_password/password fieldtype so they never sit in plain text. A Payment Request routes through the gateway controller, which prepares a checkout against HyperPay's /v1/checkouts endpoint and renders the COPYandPAY widget, or drives the Server-to-Server API where you need a fully custom checkout. The success return hits a @frappe.whitelist(allow_guest=True) method that queries the payment status endpoint, verifies the resultCode, and on approval creates or submits the Payment Entry and marks the linked invoice — all inside a single database transaction so a half-recorded payment can't happen.

Technically it is wired the ERPNext way. hooks.py doc events keep Sales Invoice and Payment Request in sync; a Payment Gateway Account links the gateway to the right bank/clearing account so reconciliation is automatic. 3-D Secure 2 SCA is handled by HyperPay's flow and the challenge result is validated server-side before we trust it. For subscriptions and saved cards we implement registration tokens: the initial COPYandPAY run stores a HyperPay registrationId on a child table against the customer, and a scheduler_events (cron/daily) hook charges tokenized initiator=MERCHANT transactions for recurring billing, writing each result back as a Payment Entry with full idempotency guards so a retried scheduler run never double-charges. Webhooks (where your HyperPay account has them enabled) are received on a signed, whitelisted endpoint and verified before any ledger write. Everything respects Frappe permissions — a dedicated HyperPay Manager role profile gates Settings and the manual-capture/refund actions, and all API calls are logged for audit.

Because this is build-to-order, nothing ships until we agree scope. After a short scoping call we confirm which brands and flows you need (COPYandPAY vs Server-to-Server, recurring yes/no, refund/capture handling), your ERPNext version (v15 or v16) and hosting, then build against a staging copy of your bench. You get UAT on staging with test-mode HyperPay credentials, a documented go-live cutover, and the full source repo handed to you. Typical delivery is one working week from confirmed scope, and we support the app through a post-go-live window with a clear path for updates as HyperPay's API and your ERPNext version evolve.