Details : Payment system¶

Cursor (an AI assistant) was used throughout this log as a research and writing aid — to explain technical concepts, summarise reference material, clarify questions, and help structure and draft the documentation. All explanations were reviewed, tested against the actual build where possible, and verified by the author.

Week 1¶

-

Week 2¶

-

Week 3 : Remote activation payment¶

An early draft and written simply to get a rough plan without the know-hows yet.

The payment system is planned around a remote command idea. After a user successfully pays, the device should be told to turn on (unlock) ; when the paid time runs out, it should be told to turn off (lock) again.

Research is made on similar system that has been deployed in the past.

OpenPAYGO (EnAccess)¶

The approach of this project is token-based and works offline: - After payment, a token is generated and user receive it at the user's phone normally by SMS— a short code tied to a certain amount of paid time. - The user enters that token on the device (for example on a keypad), and the device checks the token by itself and turns on for the paid period. When the time is up, it turns off again. No internet or live connection is needed.

References :

Payment system for the project (sketch)¶

In contrast to the OpenPAYGO system, the following is envisioned to be implemented to the project :

Automatic activation after payment — the device should unlock or enable power delivery immediately after a successful payment, eliminating the need for manual user intervention.
Robust remote command delivery — control commands must be able to travel reliably from the backend system to the remote device, even in challenging urban environments with interference, obstacles, and competing wireless signals.

Week 3¶

-

Week 4¶

-

Week 5¶

-

Week 6¶

-

Week 7¶

-

Week 8¶

-

Week 9¶

-

Week 10¶

-

Week 11¶

-

Week 12-13¶

-

Week 14¶

-

Week 15 : Payment system integration¶

The natural next step is to connect the lock/unlock system — driven from the Week 15 : Interface & Application Programming web interface — with real payment.

It was found out later that the general mechanics are a sub-project itself (i.e. fees, customer/transaction records, security/compliance) and is ultimately country-specific. Since the prototype is developed and tested in China and a merchant account needs a Chinese business license, a live payment could not be tested. Therefore this will point will be deferred and brought to the next phase on the deployment.

Week 16¶

-

Week 17¶

-

Week 18¶

-

Week 19¶

-

Week 20¶

-