If you sell in Saudi Arabia, the UAE or Egypt on ERPNext, the gap shows up the moment a customer reaches the pay button. ERPNext ships with generic Payment Gateway integrations (Stripe, Razorpay, PayPal, Braintree), but none of them clear mada — the domestic Saudi debit scheme that most local shoppers actually carry — and none surface Apple Pay or STC Pay natively. So you either lose the sale to cart abandonment, or you bolt on an off-platform checkout and lose the tie-back to your Sales Invoice, Payment Entry and reconciliation. This app closes that gap by making PayTabs a first-class citizen inside ERPNext.

We build a proper Frappe app (its own module, installed via bench get-app and bench install-app) that registers a PayTabs provider against ERPNext's native Payment Gateway and Payment Request framework. A PayTabs Settings Single DocType holds your profile ID, server key and client key (stored as encrypted Password fields), your acquiring region, default currency and hosted-vs-seamless mode. From there the flow is standard ERPNext: a Payment Request generates a checkout, the customer pays via PayTabs, and a controller returns them to a whitelisted return handler. On the server side, hooks.py doc events and a whitelisted callback method validate the PayTabs return signature, look up the originating Payment Request, and create the Payment Entry — so every paid transaction reconciles against the correct invoice with no manual matching.

Technically, we cover both integration styles. Hosted payment page hands checkout entirely to PayTabs (fastest to certify, PCI scope minimised). The seamless iframe embeds card capture directly in your ERPNext web checkout or Portal page via a client script, for a branded, on-site experience. We handle mada, Visa, Mastercard and Amex card rails plus Apple Pay and STC Pay wallets, multi-currency acceptance across 168+ currencies, and optional tokenization so returning customers pay with a saved card token rather than re-entering details. Server-side callback verification, idempotent transaction handling (so a double PayTabs postback never creates two Payment Entries), and a scheduler event that reconciles any pending/held transactions round out the reliability story. Role-based permissions keep gateway credentials and refund actions restricted to a Payments Manager role profile, and all activity is written to a queryable log DocType.

Because this is build-to-order, nothing is a black box. After a short scoping call we confirm your acquiring setup, currencies, checkout style (hosted or seamless), and which ERPNext transactions trigger payment (Sales Invoice, POS, web checkout, or a custom Portal flow). We build against your target Frappe/ERPNext version (v15 or v16), test the full happy path plus failure and refund paths on a staging bench, run UAT with your team, and only then deploy to production with a rollback plan. You receive the source code for your version, the git repository, and a support window after go-live. Typical delivery is one working week from confirmed scope.