Quick facts
- Price
- $399.00 USD
- ERPNext versions
- —
- Setup time
- 30 min
- License
- One-time perpetual
- Languages
- 11 languages
One-time Purchase
Card Terminal Payments for ERPNext POS
Take in-person, card-present payments through Stripe Terminal, Square and regional readers directly inside the ERPNext POS — with split tender, one-touch refunds, and Payment Entries that reconcile themselves. ECOSIRE scopes, builds, installs and supports it for your ERPNext v15/v16 site.
$399.00USD
No payment now. This sends a quote request to our team — we'll follow up by email with pricing and next steps.
Key Features
Card-present capture via certified readers (Stripe Terminal WisePad/BBPOS, Square, and supported regional models) driven from the ERPNext POS payment screen
Stripe Terminal integration using the connection-token + `PaymentIntent` flow so card data never touches your Frappe server and the app stays out of PCI DSS scope
Dedicated DocTypes — `Terminal Reader`, `Terminal Connection Profile`, `Terminal Transaction` — modeling each physical reader and every capture, void and refund
Split tender across card + cash + wallet in a single POS Invoice, with each portion allocated to the correct Payment Entry references
Auto-created Payment Entries mapped to the right Mode of Payment and deposit account, so sales close without manual re-keying
Refund and void issued directly from POS via `@frappe.whitelist()` methods that call the processor API and book the reversing entry
`hooks.py` `doc_events` handlers on POS Invoice submit to trigger capture and write processor charge id, card brand, last-four, auth code and fee back onto the record
Nightly `scheduler_events` reconciliation job that pulls the processor payout/settlement feed and flags any mismatch against `Terminal Transaction` rows
Role profile and permission rules so only authorized cashiers/supervisors can capture, void or refund — enforced by ERPNext's permission engine, not client-side checks
Client Script that adds a 'Charge on Terminal' button and live reader status (connected / collecting / processing) to the standard POS UI without forking ERPNext core
Idempotent charge handling keyed on the POS Invoice so a double-tap or network retry cannot double-charge a customer
Multi-outlet support — connection profiles and readers scoped per POS Profile / warehouse so each till talks to its own reader
Whitelisted REST endpoints for reader pairing, discovery and status, callable from the Frappe REST API for kiosk or headless setups
Configurable currency, fee posting and settlement-account mapping to match your Chart of Accounts, tested against ERPNext v15 and v16
About this Product
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.
Why Choose Card Terminal Payments for ERPNext POS
Card-present capture via certified readers (Stripe Terminal WisePad/BBPOS, Square, and supported regional models) driven from the ERPNext POS payment screen
Stripe Terminal integration using the connection-token + `PaymentIntent` flow so card data never touches your Frappe server and the app stays out of PCI DSS scope
Dedicated DocTypes — `Terminal Reader`, `Terminal Connection Profile`, `Terminal Transaction` — modeling each physical reader and every capture, void and refund
Split tender across card + cash + wallet in a single POS Invoice, with each portion allocated to the correct Payment Entry references
Auto-created Payment Entries mapped to the right Mode of Payment and deposit account, so sales close without manual re-keying
Refund and void issued directly from POS via `@frappe.whitelist()` methods that call the processor API and book the reversing entry
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 2–4 weeks 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.
What you get
- Installable Frappe app source code, built and tested against your ERPNext version (v15 or v16), packaged for `bench get-app`
- Installation and configuration on your staging and production sites, including reader pairing, connection profiles and Mode of Payment mapping
- Technical documentation covering DocTypes, hooks, whitelisted methods, scheduler jobs and the processor integration
- Cashier user guide plus a live training session for counter and supervisor staff
- UAT on a staging copy of your site with a documented, rehearsed rollback plan before any production change
- Git repository handover — you own the full source, commit history and documentation, with no black-box binaries
- Post-go-live support window (defined in the SOW) for defect fixes and reader/processor configuration adjustments
- Reconciliation runbook for matching processor payouts to `Terminal Transaction` and POS Invoice records at period close
Who this is for
Multi-outlet retail operations manager
Runs several ERPNext POS tills and is tired of reconciling standalone card-machine tapes against ERPNext by hand. Needs each till bound to its own reader, card sales posted automatically, and payout feeds reconciled nightly so the daily close actually ties out.
Restaurant / hospitality owner
Wants fast card-present payments at the table or counter with split tender (card + cash + wallet) on one check, and refunds a supervisor can issue on the spot from the POS — all inside ERPNext rather than a separate payments app.
Finance controller / accountant
Cares about auditability: every charge carrying its processor id, auth code, card brand, last-four and fee, mapped to the correct deposit account and Payment Entry, with mismatches flagged instead of hidden. Needs it to hold up at month-end reconciliation.
IT lead / systems integrator
Owns the ERPNext deployment and wants a clean Frappe app installed via `bench`, source in a git repo they control, permissions enforced through role profiles, and card data kept out of PCI scope via the connection-token flow — not a fork of ERPNext core.
Installation overview
Download from ECOSIRE
Buy the license on ecosire.com and download the Card Terminal Payments for ERPNext POS app ZIP from your account dashboard.
Add the app to your bench
Extract the ZIP into your bench's apps folder, or run `bench get-app` with the path to the extracted app.
Install on your site
Run `bench --site SITE_NAME install-app APP_NAME` followed by `bench migrate` to install Card Terminal Payments for ERPNext POS and apply its schema.
Activate your license
Open the ECOSIRE License settings on your site and activate your license key. Requires the free ecosire_connect and ecosire_license_client apps.
How Card Terminal Payments for ERPNext POS Compares
| Criterion | ECOSIRE | Custom Build | Competitor | Odoo Native |
|---|---|---|---|---|
| Card-present capture in POS | Native 'Charge on Terminal' action drives the reader from the ERPNext POS | Possible but you design the whole terminal SDK flow yourself | Often online/hosted-checkout only, not true card-present | |
| Auto-reconciled Payment Entries | Charge id, fee and deposit account posted automatically, payouts matched nightly | Build the posting and reconciliation logic from scratch | Records a payment but rarely reconciles the settlement feed | |
| Split tender (card + cash + wallet) | One invoice, correctly allocated Payment Entry references | Achievable with significant effort | Varies; many handle a single tender per sale | |
| Refund / void from POS | One-touch, permission-gated, books the reversing entry via processor API | You wire each processor's refund API and guards | May require the processor dashboard, not the POS | |
| PCI scope | Connection-token flow keeps card data off your server | Depends entirely on how you build it | Usually handled, but implementation varies | |
| ERPNext v15/v16 fit | Built and tested against your exact version and Chart of Accounts | You own version testing and upgrades | May lag ERPNext releases or break on upgrade | |
| Source ownership | Full app source in a git repo you own — no black box | You own it because you wrote it | Often closed-source or licence-locked | |
| Support & delivery | Scoped build, UAT, rollback plan, post-go-live support window | Depends on your in-house team's bandwidth | Generic ticket support, no build-to-fit |
Frequently Asked Questions about Card Terminal Payments for ERPNext POS
+How long does delivery take?
This is a build-to-order app, so there is no instant download. Typical delivery is 2–4 weeks from confirmed scope, depending on how many processors and reader models you need and whether you are on ERPNext v15 or v16. It starts with a short scoping call; once scope and the SOW are signed off we build against a staging copy of your site, run UAT, and install to production behind a rollback plan.
+Which card readers and payment processors are supported?
The core build targets Stripe Terminal (WisePad/BBPOS-class readers) and Square, plus supported regional readers we confirm during scoping. We validate reader models, currencies and settlement behavior against your actual acquirer before go-live rather than assuming compatibility.
+Does this put my ERPNext server in PCI scope?
No. We use the processor's card-present flow (connection tokens and `PaymentIntent` / equivalent) so the reader handles the card directly and card data never lands on your Frappe server. Your ERPNext site stores only the transaction reference, card brand, last-four, auth code and fee — never the full card number — which keeps you out of PCI DSS scope for the sensitive data.
+What about updates and ongoing support after go-live?
Every engagement includes a post-go-live support window (defined in the SOW) for defect fixes and configuration changes. Because you receive the full source in a git repository you own, your team or ECOSIRE can maintain and extend it. We also offer a maintenance retainer for processor SDK upgrades, new reader models, and ERPNext version upgrades (for example moving from v15 to v16).
+Is this a Frappe Cloud Marketplace app I can just install?
No — it is a custom Frappe app that ECOSIRE builds, installs and supports for your specific setup. We deliver it as installable source packaged for `bench get-app`, so it works on Frappe Cloud, self-hosted, or on-premise ERPNext, but it is scoped and built to your processors, readers and accounting rules rather than shipped as a one-size download.
+How does reconciliation actually work?
A `hooks.py` `doc_events` handler records the processor result onto each POS Invoice at capture, and a nightly `scheduler_events` job pulls the processor's payout/settlement feed and matches it against `Terminal Transaction` records. Any amount or fee mismatch is flagged for review instead of silently posting to the GL, and we hand over a reconciliation runbook for period close.
+Can a single sale be paid partly by card and partly by cash?
Yes. Split tender is first-class: one POS Invoice can settle across card, cash and wallet, and the app allocates each portion to the correct Mode of Payment and Payment Entry references so the invoice closes cleanly and the accounting stays accurate.
Related Modules
Request a quote
Card Terminal Payments for ERPNext POS
Take in-person, card-present payments through Stripe Terminal, Square and regional readers directly inside the ERPNext POS — with split tender, one-touch refunds, and Payment Entries that reconcile themselves. ECOSIRE scopes, builds, installs and supports it for your ERPNext v15/v16 site.
- Card-present capture via certified readers (Stripe Terminal WisePad/BBPOS, Square, and supported regional models) driven from the ERPNext POS payment screen
- Stripe Terminal integration using the connection-token + `PaymentIntent` flow so card data never touches your Frappe server and the app stays out of PCI DSS scope
- Dedicated DocTypes — `Terminal Reader`, `Terminal Connection Profile`, `Terminal Transaction` — modeling each physical reader and every capture, void and refund
- Split tender across card + cash + wallet in a single POS Invoice, with each portion allocated to the correct Payment Entry references