Omnichannel SMBs in the US, UK, and Australia sell both online and across a counter, but ERPNext core has no native Square connector. Merchants end up reconciling Square's dashboard against ERPNext by hand: online orders captured through a hosted page never write back a Payment Entry, in-person card-reader takings arrive as a lump settlement that nobody can tie to specific invoices, and refunds issued in Square silently drift out of sync with the ledger. The result is manual journal entries, mismatched customer balances, and a monthly close that takes days longer than it should. ERPNext's built-in payment gateway framework covers a handful of redirect-style processors and does not speak Square's Web Payments SDK, Terminal API, or webhook model.

ECOSIRE builds a proper Frappe app — installed on your bench with bench get-app and bench install-app — that treats Square as a first-class ERPNext payment rail. Online, we implement Square's Web Payments SDK to tokenize the card client-side and complete the charge server-side through a whitelisted method (frappe.whitelist()), so raw PAN data never touches your server and PCI scope stays minimal. A Square Settings single DocType holds your application ID, location IDs, and access token (stored as a Password field, encrypted at rest); environment toggles let you point the same install at Square Sandbox for UAT and Production for go-live. In-person sales use Square's Terminal API / device-code pairing so a physical card reader can be driven from an ERPNext POS or a custom checkout screen, with cards, Apple Pay, Google Pay, and Cash App Pay all handled by Square's own SDK.

Under the hood the app maps Square events onto ERPNext documents. A dedicated Square Payment (or Square Transaction) DocType logs every payment, order, and refund with the Square payment_id/order_id for a durable audit trail; hooks.py doc events on Sales Invoice and Payment Request trigger charge creation, and on success we create or allocate a Payment Entry against the correct invoice, respecting company currency and your configured bank/clearing account. A Frappe webhook endpoint (a whitelisted, signature-verified method) receives payment.updated and refund.created callbacks so disputes, chargebacks, and Square-initiated refunds flow back into ERPNext automatically. Tokenized card-on-file is supported via Square's Customer/Cards API and stored against the ERPNext Customer for repeat and subscription billing. A scheduler event (scheduler_events in hooks.py) runs a periodic reconciliation sweep that fetches recent Square settlements and flags any transaction that lacks a matching Payment Entry, so nothing goes un-posted. Access is governed by ERPNext role profiles and permissions, and a Client Script adds the Square payment button and status badges to the relevant forms.

Because every ERPNext install differs — your chart of accounts, POS profiles, currencies, tax treatment, and whether you need Terminal hardware or online-only — this is delivered build-to-order rather than as a generic download. We start with a short scoping call, confirm the exact flows and DocType mappings in a written statement of work, then build against your Square Sandbox and your data model. Typical delivery is one working week from confirmed scope, targeting Frappe/ERPNext v15 and v16. You receive the full app source in a git repository, UAT on a staging bench with a documented rollback plan, and a post-go-live support window — no lock-in, and the code is yours to maintain or extend.