Case study
Sayapatri contactless payment terminal
Two ESP32 payment terminals. One takes the amount from a phone over BLE and joins shop Wi-Fi. The other uses a keypad, a battery, and a cellular modem.
Card tap → ESP32 → Wi-Fi or GSM → payment flow
- Record
- Shipped product firmware. Also an Upwork portfolio item titled NFC-based Payment System.
- Stack
- ESP32, NFC, BLE, GSM, TFT
- Hardware
- ESP32 WROVER · PN532 NFC · 2.8 inch TFT · TTGO T-Call / SIM800 on the GSM SKU · Keypad on the GSM SKU
The problem
A shop terminal has two realities. Some counters have Wi-Fi and a phone in the merchant’s hand. Some do not, and the amount has to be typed on the device, on a battery, on the mobile network. The payment flow itself should not fork into two products that drift apart.
What I built
Sayapatri is a contactless payment device on ESP32, in two SKUs.
The Wi-Fi version uses an ESP32 WROVER. First boot opens an access point so the shop can enter Wi-Fi credentials, then the radio switches to station mode. NimBLE talks to an iOS or Android app so the merchant can enter a payment or a recharge amount. A 2.8 inch TFT shows the amount and the result. The reader is a PN532.
The GSM version uses a TTGO T-Call. The amount comes from a keypad instead of the phone. It runs from a battery, speaks HTTPS, and can take an OTA update. SPI is used for the display path. The cellular side of this family is SIM800.
Both versions follow the same flow: read the card, show status, send the transaction.
Decisions
Setup and daily use are different radios. The captive portal exists so a terminal can be installed without a cable. BLE amount entry keeps the Wi-Fi SKU off a rubber keypad. The GSM SKU drops the phone app because that shop may not have one, and keeps a keypad plus OTA so the firmware can move without a visit.
A separate production flasher is how units in this family get programmed. The public write-up of that station is the ESP32 serial flasher on this site.
The Upwork portfolio lists Sayapatri as “NFC-based Payment System”.