Retailers and restaurants running on ERPNext hit a wall the moment a customer asks for a gift card or expects a refund to go back as store credit. ERPNext core has no gift-card ledger, no redeemable balance instrument, and no clean way to turn a return into spendable credit — teams end up improvising with coupons, advance payments, or a spreadsheet the POS cashier can't see. That improvisation breaks down fast: balances drift, partially-used cards get double-spent, and there is no single audit trail tying issuance, top-up, redemption and expiry back to the General Ledger. Native POS Invoice, Sales Invoice and Pricing Rules simply were not designed to carry a stored-value instrument that survives across visits, channels and refunds.

We build a proper Frappe app that adds gift cards and store credit as first-class stored-value instruments inside ERPNext. The core is a Gift Card DocType (card code, issue value, current balance, currency, status, expiry, linked customer) plus a child-table Gift Card Transaction ledger that records every issue, sale, redemption, reload and adjustment as an immutable line — so a card's balance is always the sum of its ledger, never a mutable field someone can fat-finger. A companion Store Credit wallet DocType holds per-customer credit accrued from returns and refunds. Redemption is enforced server-side: a whitelisted method (frappe.whitelist()) validates the card code, checks status and expiry, guards against overdraw on partial redemption, and writes the transaction atomically so two concurrent POS terminals can't both spend the last balance.

Integration is done through hooks.py document events rather than by patching ERPNext core. on_submit handlers on POS Invoice and Sales Invoice apply a redeemed card or wallet as a payment/deduction and post the matching entries so revenue and outstanding liability stay correct in the GL; a Credit Note (return) can on_submit mint store credit back to the customer's wallet instead of a cash refund. Barcode/QR redemption is wired into the POS via a client script and a lightweight scan-to-lookup call, so a cashier scans a physical card or a customer's e-gift QR and the balance resolves instantly. E-gift issuance ties into a Notification / email template so digital cards are delivered with their code on purchase. A scheduler event (scheduler_events in hooks.py) runs daily to flag or lapse expired cards and, where you want it, to sweep dormant balances per your policy. Everything is exposed over the Frappe REST API and whitelisted methods so an online store, kiosk, or headless front end can issue and redeem against the same ledger the POS uses. Access is governed by Frappe permissions and a dedicated role profile, so only authorized staff can adjust or void a card, and every change is captured in the document's version history for audit.

Because this is build-to-order, nothing ships until we agree on scope. We start with a short scoping call to confirm your card formats (physical batch codes vs. e-gift), redemption channels, expiry and reload policy, refund-to-credit rules, multi-currency and multi-company needs, and how balances should hit your chart of accounts. We then build against your ERPNext version (v15 or v16), deliver on a staging site for UAT, and only promote to production once you have signed off — with a documented install, a rollback plan, and a support window after go-live. You receive the full source and Git repository so the app is yours to keep and extend.