Everything between a hand and a bank authorisation.
Banks are good at accounts and money movement. HathPay builds the parts a bank does not want to: capturing palms, matching them at scale, trusting terminals in the field and orchestrating each payment safely.
The customer and the money
- Customer relationship, onboarding and KYC
- The account, the balance and the ledger
- Authorisation and settlement on its own rails
- Pricing, limits policy and disputes
The palm layer
- Guided enrolment on NIR terminals
- Encrypted templates and 1:N matching
- Terminal identity, approval and revocation
- Risk rules, APIs, webhooks and audit
A hand that pays
- Checkout with no phone, card or cash
- Pause, limits and history in the bank app
- A separate PIN, never a banking password
- Removal at any time, which deletes the template
One platform, seven jobs.
Guided enrolment
Staff verify identity; the terminal guides five captures of one hand. Captures that disagree are dropped, a palm already enrolled for someone else is refused, and the images are deleted once the template exists.
1:N identification
At checkout the palm is searched against the bank's enrolled customers, with no card or phone to narrow it down. Customers can register both hands, and either one pays.
Risk engine
Limits, velocity and PIN step-up, set by the bank and the customer.
Device trust
Every terminal has its own key and needs approval before it can charge.
Customer control
Pause, limits, history, "not me" and removal, inside the bank's app.
Tamper-evident audit
Every sensitive action is written to a log where each entry seals the one before it. Change a single row and verification fails from that point on.
Operations console
Approve terminals, follow payments, verify the audit chain and handle support.
Four steps. Three places. One bank account.
The customer switches HathPay on inside their bank app.
The bank has already signed them in. They agree to the consent, choose the account to pay from and set a HathPay PIN that is separate from every banking password. The app then shows a one-time enrolment code.
At the branch, the palm becomes a template.
Staff check identity and enter the code. The terminal guides five captures of one hand, keeps the ones that agree, refuses a palm already enrolled for someone else and builds an encrypted template. The images are deleted.
At checkout, a palm is all it takes.
The cashier enters the amount and the customer holds out a hand. For small payments that is the whole interaction. Above the bank's threshold, or when a risk rule fires, the terminal asks for the HathPay PIN.
The bank decides, and the bank moves the money.
HathPay sends one signed authorise-debit request to the bank's adapter, exactly once. The bank approves or declines, settles on its own rails and receives a signed event that updates its app and records.
See it working, end to end, in thirty minutes.
Activation in a bank app, enrolment at a branch terminal and a palm payment settled through a simulated bank. Then the architecture and the pilot plan.