As I mention in comments I don't really know what bad outcome(s) you're trying to prevent, but:
An option in the app to close the flap (and cease charging, if there's already a car plugged in) would help protect the user against accidentally opening a different tower from the one they intended (or opening a tower by finger-fumbling the single button when they were just trying to browse around) and paying for the charge of the next lucky person to arrive at that tower.
You could experiment with applying this option automatically if the user exits the app, or if no car is plugged in for a certain time after opening the flap, but you'd have to understand the amount of variety in your users' workflows. It might seem reasonable to set it to one minute, since plugging in a car is easy, but maybe some users prefer to do the phone thing to open the flap, then get out of the car into the rain, fish the charge lead out of the car, and plug both ends. This might take more than the one minute that seemed ample. And it might seem reasonable that the user can keep the app open until they're done plugging stuff in, but users only have a finite number of hands, and might need one more than you expected for other purposes ;-)
Additionally, closing any flap the user already has open at the point they open a flap (or perhaps more user-friendly, forcing them to confirm to close it if they try to open another), would protect the system against a user mischievously or accidentally leaving flaps open all over the country.
You can't use a smartphone app to prove that a malicious user genuinely is present, because they can make their phone lie to your app about its location. However, you can use the app to "prove" that a co-operating user is in the right location. So, the app could check that the phone is close to the tower before opening the flap. This would protect the user against certain kins of abuse or accident, but would not protect the system against abuse by a determined user.
This will inconvenience a few users, along the lines of "I left my phone at home, and needed to charge my car, so I called my phone. My spouse picked up, and I asked them to open the tower I need. Why did you stop this working, and how do I get my phone and my car into the same place at the same time given that my car battery is flat?". However, since it's for the user's protection and not that of the system, it doesn't have to be a block, it could just trigger an additional confirmation ("that tower is nowhere near you, are you sure you want to proceed?").
The only thing that distinguishes this case of a forgotten phone from abuse, is that the owner actually has the car and plans to charge it, so:
- If you can add something to the car, then you could perhaps use the tower to detect that the right "something" is near the tower before opening the flap. Probably bluetooth has enough range, and that RF is open to use without special license etc. This might not defend against determined users, who perhaps could sit comfortably in their home with their phone while an accomplice carries their "something" around the country. I can't tell whether you would consider this a flaw.
Edit, the threat you mentioned above suggests a particular scenario:
A mischievous user (by which I mean someone who wants to mess with the system, but isn't extracting money from it) tries to interfere with people opening flaps. So he sends an "open flap" message just as they're sending one of their own, or he spams the system with "open flap" messages, or whatever. This results in an innocent user doing one of two things:
- knowingly or unknowingly charges their car on the malicious user's account
- feels unable to charge their car, since it keeps opening on the malicious user's account.
The first thing might seem harmless, but leads to two problems:
- the malicious user disables the charge part way through (assuming my other measures above exist), leaving the innocent user to return to an uncharged car.
- the malicious user successfully disputes the bill (in point of fact they didn't receive the charge they paid for, so they might get away with just proving they weren't in the area), and you've performed a charge that nobody pays for.
Unless you can establish that only one user is genuinely close to the tower you cannot automatically adjudicate between the innocent and the malicious user, however you can:
- Put a button on the tower to close the flap for re-use, which gives the innocent user a slight advantage in the battle to open it on their account.
- Track when users are engaged in "flap wars", including when someone presses the button on them, so that you can investigate their patterns of use and apply usage limits or ban them if necessary.
- Confirm in the app when a car is charging on their account, and when an "open flap" attempt fails due to the flap being opened by another account, so that the innocent user at least knows what is going on.
- Forget that the smartphone happens to be online, and require an NFC tap on the tower to open it. Of course this further limits what phones the app will work on. You might like to provide cards for those whose phones won't do it, but then again the system has already decided to use phones rather than cards, so maybe there's a reason it won't do that. This re-opens the "I left my phone at home" scenario, so for emergencies you might allow users a very limited number of flap-openings without a tap.
Be aware also that the abuser needn't be 100 miles away. They could interfere with the innocent user while actually present. In fact they could be standing right near the tower using their phone, enjoying the confused look on the innocent users' faces as the tower fails to operate properly. Hopefully, however, they can't be close enough to tap their card/phone without the innocent user realizing what they're doing. Naturally you can't hope for your system to stop a malicious user who is willing to actually stand at the tower taking obvious actions to stop innocent users from accessing it -- that's a matter for the police...
Plate #1 from my pending patent application.
