Things you should know about our upcoming ePOS launch and development:
Readiness Assessment
1. The ePoS UI is approximately 95% ready. All main user scenarios have already been built and linked together.
2. Registration, authorization, email confirmation and 2FA, password recovery, and PIN code functionality are in place.
3. Role selection is implemented: the user can sign in as a merchant or as a cashier.
4. The main sections for the merchant are ready: company profile, terminals, cashiers, currencies, balance, withdrawal of funds, history, and statistics.
5. The POS interface for the cashier is ready: amount entry, currency selection, the payment waiting screen, and the operation result screens.
6. There is a separate window with the cashier's login and password. The credentials can be copied, sent, and immediately used to sign in to the cashier account.
What Already Works in Terms of Logic
1. After registration, the merchant is automatically signed in to the app. There is no need to re-enter the login and password.
2. Merchant authorization works via the REST API.
3. Cashier authorization has also been moved to REST: the cashier signs in with the issued login and password, the tokens are saved, and then the POS part of the app opens.
4. Creation of the ePoS merchant, checkout, and cashier via the REST API has been implemented. After a cashier is created, the app receives and displays their credentials.
5. Cashier lists and cashier details work on REST data.
6. Translations are loaded from a spreadsheet. A fallback has been added, so in case of network issues the app should not display technical keys instead of text.
7. The QR code on the payment screen is generated on the frontend from a string that the app passes to the QR library.
What Still Needs to Be Completed
1. The main payment scenario has not yet been fully moved to REST. Payment verification currently still uses the old TCP logic.
2. The scenario "ePoS displays the QR code, the wallet scans it, the payment goes through, ePoS receives confirmation" has not yet been fully tested on the test environment.
3. REST payment requires a response from the backend with ready signed data for the QR: paymentUrl or qrData. Without this, it cannot be guaranteed that the QR code will be processed correctly by a crypto wallet.
4. The QR signature is currently generated in the app. For production, this needs to be moved to the backend so that the private key is not stored in the mobile app.
5. The old TCP chain needs to be replaced with REST: create the transaction, confirm it, display the QR code, and receive the payment status via the API.
6. The scenarios of merchant creation, checkout, cashier creation, and cashier sign-in need to be run on the test API, including errors, repeated requests, and cases where the entity already exists.
7. Publishing to Google Play will require a production Android signature. The current APK is suitable for internal testing.
8. Before QA, the changes in the repository should be put in order: separate the temporary files and commit the working changes in clear commits.
Summary
1. In terms of the interface and basic account scenarios, the app is almost ready.
2. The main block currently holding back the release is payments: the REST contract, server-side QR signing, receiving the payment status, and testing the scenario together with a crypto wallet.
3. After this integration is completed and fully tested, the app can be prepared for production release.