Omnichannel ERPNext retailers hit a wall the moment they try to take a physical card. ERPNext POS handles cash, cheque, and manual "credit card" mode-of-payment lines, but it has no concept of a certified card-present terminal: no reader pairing, no EMV/contactless capture, no card-present pricing, and no automatic reconciliation of the swipe back to the POS Invoice. Staff end up keying totals into a separate Stripe or bank terminal and then re-typing the result into ERPNext, which produces mismatched settlements, orphaned refunds, and a POS ledger nobody trusts at month-end. Stripe's card-present rails (Terminal) solve the hardware and compliance side, but nothing in ERPNext core speaks to them.

We build a proper Frappe app — installable with bench get-app and bench install-app — that makes Stripe Terminal a first-class ERPNext payment method. The app ships a custom Stripe Terminal Settings single DocType for API keys and location config, a Stripe Reader DocType to register and manage BBPOS WisePOS E and M2 devices, and a Stripe Terminal Payment transaction DocType that stores the PaymentIntent id, capture method, card brand, last4, and reconciliation state. Whitelisted server methods (@frappe.whitelist()) expose connection-token minting and PaymentIntent create/capture/cancel to the POS front end without ever exposing your secret key to the browser, since the Stripe Terminal JS/SDK requires a server-issued connection token. A client script extends the ERPNext POS payment screen with a "Pay at Reader" action that drives the physical terminal, then writes results back through the REST API.

Under the hood we wire the flow through hooks.py document events and scheduler hooks: on_submit of the POS Invoice triggers capture and stamps the Stripe reference, a Stripe webhook endpoint (a whitelisted guest method with signature verification) receives payment_intent.succeeded, charge.refunded, and terminal.reader.action_* events to keep ERPNext authoritative, and a scheduler_events hourly job reconciles any in-flight PaymentIntents against Stripe so a dropped Wi-Fi connection can't leave a sale in limbo. Refunds initiated from the reader or from ERPNext create a linked Payment Entry and reverse the charge, and card-present transactions carry the 3DS liability shift so you get the lower card-present pricing and exemptions rather than online rates. Tap to Pay on iPhone and supported Android devices runs through the same PaymentIntent path for retailers who don't want dedicated hardware. Role-based permissions (a dedicated POS Terminal Manager role profile) gate settings, refunds, and reader registration.

Because this is build-to-order, nothing ships until we agree on scope. We start with a short scoping call, confirm your ERPNext version (v15 or v16), your Stripe account and target regions, the reader models and store count, and your reconciliation and refund rules. We then build against a staging copy of your bench, run UAT with your team, and only cut over to production once you sign off. You receive the full source as a versioned Frappe app in a git repo you own, plus documentation, training, and a defined post-go-live support window — not a black-box marketplace binary.