This touches several parts of how Ethereum works. I'll try to explain it in an understandable way:
1.) Ethereum has "externally owned accounts" (EOAs) and "contract accounts". EOAs are much like normal bank accounts. They have an address (IBAN) and a balance (in Ether). Essentially, the EOAs owner possesses a public key pair, of which only he knows the private key. The matching public key "is" the EOAs "address" - the "IBAN". Now, only the EOAs owner can transfer Ether (="withdraw or wire money") from that account - by using the private key in the process. In short, EOAs are "directly owned and controlled" by their respective owners.
Contract accounts do not "belong" to anyone. They simply exist on their own and store smart contract code. They also have an address etc, but noone possesses the matching private key. Therefore, the comprised smart contract logic controls the contract account. For a better explanation see also: https://github.com/ethereumbook/ethereumbook. Consider buying the book if you work with Ethereum. It is worth every cent!
2.) The scenario you describe could have a smart contract (i.e. contract account, not EOA) that accepts payments from customers (i.e. from EOAs) and then stores a list of who (= which address) payed. In a smart contract, that can be done e.g. via a mapping. The money payed to the smart contract can then be forwarded to the "business owner's" address (EOA).
So all in all, to your questions:
- No, you would have a contract account accepting reservations
- Technically, you can also have a payment via VISA and just store the "receipt" in the chain. Wouldn't advise you to though!!! You can also go and use your own reservation token. I guess paying in Ether is the best approach here. Anyhow: Why are you thinking about implementing this in Ethereum in the first place?
- Your web3.js simply sends transactions to the blockchain. I guess you would have a web-app which allows a customer to make a reservation which is then payed (and recorded) on the Blockchain. Here, the customer would use his wallet (e.g. Metamask) to pay to your account, and your backend would listen to an event telling you that the reservation and payment went through.
3.) Depending on what you want to do exactly, you can also issue a (non-fungible) token for reservations. Customers who want to "buy" a reservation buy a token. See, e.g. https://ethereum.org/en/developers/docs/standards/tokens/erc-721/ for a standard for such a token.
4.) Anyhow, consider the fact that storing personal information on the blockchain is bad practice, as everything is public and cannot be deleted afterwards. A better approach might be one where your customer pays you (e.g. in ether) and you then issue a so-called "verifiable claim" for him, stating that you confirm his reservation and payment. This happens off-chain and only a hash is stored on the blockchain. The general approach is called "Self-Sovereign Identity" (SSI). See systems like "Sovrin" or "uPort" if you want to follow up on this. https://medium.com/uport/erc1056-erc780-an-open-identity-and-claims-protocol-for-ethereum-aef7207bc744
Hope this could help you.
