GCC retailers and restaurants running ERPNext POS hit a wall the moment a customer taps a card. ERPNext ships a POS Invoice and a Mode of Payment list, but out of the box those payment modes are just accounting labels — there is no card-present integration with a physical terminal. Cashiers end up keying totals manually into a separate Mada or Geidea PIN pad, then reconciling two disconnected systems at end of day. That double entry causes tender mismatches, slows the queue, and leaves you without a certified electronic trail linking each POS Invoice to the actual card authorization.

This build closes that gap. ECOSIRE develops a proper Frappe app (gcc_pos_payments) with its own module, DocTypes and hooks.py wiring that integrates ERPNext POS directly with the terminals and gateways you already use in the GCC — Mada, Tap, Geidea, PayTabs and HyperPay — covering Visa, Mastercard and mada card-present capture plus Apple Pay, STC Pay and mada wallet flows where the acquirer supports them. We add a POS Terminal DocType to register each physical device against a POS Profile, a POS Payment Transaction DocType to record every authorization, capture, void and refund with the gateway reference and RRN, and configuration DocTypes to hold acquirer credentials encrypted via Frappe's password field type.

Technically, the checkout flow is driven by a client script layered onto the POS interface that calls a set of @frappe.whitelist() methods; those methods talk to the terminal (cloud-to-POS or local-network integration, depending on your acquirer) and write the result back against the POS Invoice. A hooks.py doc_events handler on POS Invoice.on_submit verifies that the captured tender matches the invoice total before the sale can close, so you can never submit an invoice whose card leg didn't actually settle. A scheduler event runs a reconciliation pass that pulls the acquirer's settlement batch and matches it to POS Payment Transaction rows, flagging any orphaned auth or short-settled amount. Role profiles and DocType permissions gate who can issue a refund, void or partial capture, and every action is written to the standard Frappe audit trail. Everything is exposed cleanly over the Frappe REST API so head-office dashboards or a mobile app can read live tender status.

Because this is build-to-order, nothing is pre-listed for instant download — we build your version against your acquirer, your merchant IDs and your ERPNext v15 or v16 site. It starts with a short scoping call to confirm which terminals and wallets you run, your settlement and refund policy, and your reconciliation rules. From confirmed scope, typical delivery is one working week: we build on a staging copy of your site, run UAT with your cashiers against your real (or sandbox) terminals, then install to production with a rollback plan. You receive the full source, git repository handover, technical and user documentation, a training session, and a post-go-live support window.