Thread Rating:
  • 2 Vote(s) - 4.5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Misc Banking & Cash ideas
#1
Using your ID card to make purchases in stuff like vending machines should be tracked in your banking account.

Your PDA could have an app to check account balances and recent purchases remotely. Maybe have a peer to peer way to transfer cash? Maybe have these use packets to steal info for theft?

A cash register for places like the bar that let you store custom named buttons and set a price for them. (Burger - 50 Credits)
You could punch those buttons to get a total, theĀ  enter how much cash you're putting in and have it generate the change and receipt.
Reply
#2
What if you could put purchases on a tab that you have to pay off later? (in a set time frame)
Reply
#3
Perhaps the withdraw to card option should be removed and the slot machine should work directly with the bank account balance. I remember that mechanic being pretty unintuitive and I had to ask around on the Discord to figure out how to use the slot machine. It seems strange to have 'two types' of digital money rather than just cash and your account balance. A PIN should then be required with the slots too, but that would just bring it in line with the other ways you use your ID to buy things.

I do like Frank_Stein's ideas. Perhaps each player with an account should have a random password generated for them when joining that would be structured like the head/security netpasses. The player wouldn't need to know it, but someone attempting to spoof account info would need both the PIN and password to fake a packet and steal credits. Currently, you need to both find the PIN and steal the physical card to take someone's credits, so requiring someone to 'make themselves vulnerable' by using the transfer option would be a fair trade. I'd imagine the money transfer option could have both a request and a send transfer. Here's an idea for the packet structure for both.

address_1 = target PDA device address
sender = sender PDA device address
sender_name = name to show to user in the notification
command = request/send
pin = PIN (only on send)
user_netpass = round start randomly generated password (only on send)
amount = how much is requested or to be transferred

There are a few things you could then do with packets. You could spoof a sender to request credits and you could passively grab account info by listening for transactions. Internally, when a PDA receives a request packet, all that happens is the user gets a notification with an option to accept or decline. When a PDA receives a send packet, if there is
1) an account with the given user_netpass
2) the PIN is correctly associated with that account
3) the send amount is less than or equal to the account balance
then the transfer goes through. Otherwise, it fails.

An alternative is to have transfer mediated through DWAINE or some physical bank device that all requests are sent to, like an alternative to the network radio just for money transfers. The downside with this is coding it would be a lot more work with what I see as only marginal benefits. Though maybe others would disagree.
Reply
#4
I'd also want to toss on the idea of a transaction history on the Bank Records console or whatever, embezzling is currently nigh impossible to track down.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)