Skip to main content

Pine Labs, Mswipe, Razorpay, Paytm, Ezetap, Innoviti | HelloBooks POS One launcher for six EDC vendors. The till sends the amount, the EDC handles the swipe / dip / tap, the result flows back, the receipt prints. Server-side API keys, vendor-agnostic UX, audited every step.

EDC CARD TERMINALS

Pine Labs, Mswipe, Razorpay, Paytm, Ezetap, Innoviti

One launcher for six EDC vendors. The till sends the amount, the EDC handles the swipe / dip / tap, the result flows back, the receipt prints. Server-side API keys, vendor-agnostic UX, audited every step.

Part of HelloBooks POS · Hardware integrations

Card terminal with HelloBooks POS launcher

Card payments are where competing POS systems hide their worst code — different SDKs per vendor, secrets stored on every till, race conditions that double-charge customers. HelloBooks runs an EDC proxy on the server: API keys live in env vars, the till speaks one normalised contract, and every status response is reconciled against the underlying ledger.

HOW IT WORKS

Every detail, dialled in

Built for the till, validated against the canonical accounting engine — so every POS sale closes the books cleanly.

💳

Six vendors, one contract

The till POSTs to /pos/edc/<vendor>/start with { amount, terminalRef } and gets back a sessionId. It polls /status/<sessionId> until the card is charged or the customer cancels. Your operations team sees a single set of EDC events across all vendors.

  • Pine Labs Plutus, Mswipe WisePOS
  • Razorpay POS, Paytm For Business
  • Ezetap mPOS, Innoviti Uno
  • Same contract per vendor
🔐

API keys never touch the till

Vendor secrets live as environment variables on the Auth service. The terminal authenticates with its own JWT and the proxy attaches the correct vendor credentials. A compromised till cannot extract a Pine Labs key.

  • Env-var secrets per vendor
  • Server-side proxy on Auth-V3
  • Per-outlet vendor selection
  • Rotateable without redeploying tills
🔁

Idempotent, reconciled

Every charge has a terminalRef the till generates and the EDC respects, so a botched poll never double-charges. The settle posts to Undeposited Funds; the bank reconciliation matches against the EDC settlement file the next day.

  • Idempotent terminalRef on every start
  • Cancel endpoint releases stuck sessions
  • Posts to Undeposited Funds
  • Settlement file matched at reconciliation time

Why teams move off legacy tills

Old POS · Manual workarounds
  • Vendor SDK installed on every till
  • API keys distributed widely
  • Different cancel flow per brand
  • Manual settlement reconciliation
HelloBooks POS
  • Server-side proxy, one contract
  • Secrets in env vars only
  • One normalised cancel flow
  • Auto-match against settlement file
FAQ

Questions, answered

Which EDC vendors are supported today?

Pine Labs (Plutus), Mswipe (WisePOS / WisePad), Razorpay POS, Paytm For Business, Ezetap (mPOS), Innoviti Uno. New vendors plug in via the same contract.

Where do the API keys live?

Server-side environment variables only. The till never sees a vendor secret; it authenticates with its own JWT to the EDC proxy on Auth-V3.

What happens if the till loses connection mid-charge?

The terminalRef is idempotent. On reconnect the till re-polls the same sessionId and gets the final status. The customer is charged exactly once.

Does the card payment flow into Undeposited Funds?

Yes. Card receipts post to Undeposited Funds, and the next day’s vendor settlement file is matched line-by-line against the bank deposit. No manual reconciliation.

Ready to automate your books?

Join 2,000+ businesses saving 20+ hours per month. Get started free — no credit card required.

Subscribe to our newsletter

Stay up to date with the latest news and announcements. No credit card required.

By subscribing, you agree to our Privacy Policy.