Most GCC merchants running ERPNext hit the same wall: the payment methods their customers actually use — KNET in Kuwait, mada and Apple Pay in Saudi Arabia, local acquiring across the UAE, Qatar, Bahrain, and Oman — are not part of ERPNext core. Out of the box ERPNext ships integrations for a handful of global gateways, but nothing that speaks to Tap Payments' charges, authorize, and refunds APIs or handles KNET's redirect flow. So finance teams end up posting Sales Invoices as paid by hand, chasing settlement reports, and reconciling gateway payouts against bank statements in spreadsheets — exactly the manual work ERPNext was supposed to remove.

We build a proper Frappe app (erpnext_tap) — a versioned, installable module with its own Tap Settings single DocType for API keys and merchant configuration, a Tap Transaction DocType that mirrors every charge for audit and reconciliation, and clean integration into ERPNext's existing Payment Entry and Sales Invoice flows. It is not a hack on top of the Payment Gateway list; it is a first-class connector installed via bench get-app and bench install-app on your own site, so it survives migrations and upgrades cleanly.

Technically, checkout works by creating a Tap charge server-side through a whitelisted method (erpnext_tap.api.create_charge) and redirecting the customer to Tap's hosted page for cards, KNET, mada, or Apple Pay. Confirmation is never trusted from the browser: a dedicated webhook endpoint receives Tap's charge.captured / charge.failed events, verifies the HMAC signature, and — through a hooks.py doc-event and a background job — creates and submits the matching Payment Entry against the correct Sales Invoice, updating outstanding amounts atomically. A scheduler event runs a periodic sweep to reconcile any charge whose webhook was missed by polling the Tap API, so a dropped webhook never leaves a paid order stuck as unpaid. Refunds and partial refunds are initiated from within ERPNext and post the corresponding reversal entries automatically.

Every capability is permission-aware. API keys live encrypted in Tap Settings, refund actions are gated behind a dedicated role (via role profiles and DocType permissions), and multi-currency GCC transactions (KWD, SAR, AED, QAR, BHD, OMR) are mapped to the correct ERPNext currency and exchange settings. Client scripts surface transaction status and payment links directly on the Sales Invoice and Sales Order forms so your team never leaves ERPNext.

Because this is build-to-order, nothing ships until we agree on scope. We start with a short scoping call, confirm your Tap merchant setup, ERPNext version (v15 or v16), currencies, and reconciliation rules, then build against a staging copy of your site. You get UAT on staging with a rollback plan, a training session, and a defined post-go-live support window — plus the full Git repository handed over so the code is yours. Typical delivery is one working week from confirmed scope.