Most retail and restaurant teams running ERPNext end up with two disconnected systems at the counter: the ERPNext POS on one screen and a standalone card machine on the other. The cashier keys the amount into the terminal by hand, takes the card, then re-enters the result into ERPNext — or just marks the sale as a generic "Card" Mode of Payment with no link to a real transaction. ERPNext core ships a clean POS and a solid POS Invoice/Payment Entry model, but it has no concept of a physical card reader, no card-present capture, no terminal SDK, and no reconciliation between what the acquirer actually settled and what the POS recorded. That gap is where mis-keyed amounts, unmatched settlements, and painful end-of-day counts live.

This is a build-to-order Frappe app that ECOSIRE builds for your specific setup — not an instant download from a marketplace. We ship a proper Frappe app with its own module, DocTypes and hooks.py, turning the ERPNext POS into a true card-present point of sale. New DocTypes such as Terminal Reader, Terminal Connection Profile and Terminal Transaction model your physical readers and every capture, void and refund against them. A client script injects a "Charge on Terminal" action into the POS payment screen; when the cashier confirms, a whitelisted server method (@frappe.whitelist()) creates a PaymentIntent on Stripe Terminal (or the Square/regional equivalent), the reader collects the card, and the connection token flow keeps card data off your servers so the app stays out of PCI scope.

On capture, a Terminal Transaction record stores the processor charge id, card brand, last-four, authorization code and fee, then writes the matching amount back to the POS Invoice as its own Mode of Payment. Split tender is first-class: a single sale can settle across card, cash and wallet, and the app allocates each portion to the correct Payment Entry references so the invoice closes cleanly. Refunds and voids are issued from the POS itself — a @frappe.whitelist() method calls the processor refund API and books a reversing entry, all guarded by ERPNext role permissions and a dedicated role profile so only authorized staff can reverse a charge. A hooks.py doc_events handler on POS Invoice submission and a nightly scheduler_events job pull the processor's settlement/payout feed via the Frappe REST layer and reconcile it against Terminal Transaction rows, flagging any mismatch instead of letting it slip into the GL silently.

Because it is build-to-order, delivery starts with a short scoping call to confirm your processor(s), reader models, currencies, tax and split-tender rules, and whether you are on ERPNext v15 or v16. ECOSIRE then builds the app against a staging copy of your site, runs UAT with your team, and installs to production behind a documented rollback plan. Typical delivery is one working week from confirmed scope depending on how many processors and reader types you need. You receive the full app source in a git repository you own, so nothing is locked behind a black-box binary — you can read every DocType, server script and hook we ship.