Hybrid Point-of-Sale 2017
Create a platform enabling small businesses and contractors to take card payments in-person.
Types: Web, Mobile; Roles: Conception, Development, Architecture, Management; Functions: E-commerce, Payments; Tools: Moonstalk, JavaScript, jQuery, Tarantool, Openresty.
Innovations
- Utilising RFID/NFC smartphones to improve customer interaction in completing payments, requiring development of both UX and API between the user-presented web interface and native routines in an app. Existing card payment UX (in the west) was limited to using a camera to capture the card details (rarely used) or manually typing details in, being unreasonable to expect both parties to have the same app/system (unlike developing countries, such as with USSD solutions).
- The UX had to be carefully considered as it was taking place on a smartphone handed to the customer by their service-provider, in the manner of a bill to be paid there-and-then.
- My solution simply involved tapping a contactless payment card to the phone and then entering the 3-digit CV2. The app having been developed to invoke the NFC card reading on the payment screen. Because this only reads the card details rather than using the encrypted contactless payments channel, payments could be settled in the usual manner, and for any value above the usual contactless limit.
Features
- thin (hybrid) mobile app wrapping the website functionality with native NFC and camera card reading
- backoffice to review submitted documents and automated account progression through third-party identity verification/KYC
- short merchant-id generation for statements
- third-party account settlements
- overloaded the default status and error handling, redirecting to Slack for real-time devops and account insights
Notes
Lead development for this fintech startup, hands-on for the web, also managing outsourced (Ukraine) mobile developers (Kotlin) whom needed direction implementing entirely novel routines with no prior experience.
Originally conceived as utilising blockchain tech, I however identified no valid reason to use it for payment settlements with current card infrastructure. I did however define a roadmap in which an ancillary and complimentary featureset could integrate and utilise DLT for purposes such as insurance and servicing histories (e.g. of heating boilers).
Sourcing a payments provider able to handle independent (sub) accounts and having an API proved difficult at the time, with only Stripe having a suitable service, but was blocked during the founder's own MVP due to poor KYC practices. I nonetheless identified and established a relationship with a historic payments provider (Netbanx a card gateway from the dot-com days) whom was releasing an equivalent service (PaySafe), this was however under ongoing development without being fully implemented for our needs until late in our own development cycle.
The project was shelved by the founder just prior to a one-year cycle (whom jumped over to a more interesting role in blockchain space), and ironically two years later Apple acquired a similar startup having an inferior product.