You gotta keep 'em separated!

A multi-world-economy would exist for a few reasons: the server owner may want to experiment with different economic styles, so to appeal to different types of players. In one world it might be gold-based economy, using only nuggets and ingots as a means of transferring data, while another world may want a more robust fleshed out approach. And then some! There is a closed economy style where no new money is made, just the same money is transferred around a bunch. Then you have the more current, buggy method of money where there is no limit, more like "credit-lite" system.

First thing needed is a chest shop, using the easiest method possible to set up, would always be nice. Players should be able to set their own price for what they are selling. Hyperconomy already has many options for simple to more stylish shops inside it, so this should not be an issue.

There should be an option in the configuration file for supporting multiple worlds, and a method of grouping those worlds which share economies. This can be done in the config, or in a separate file altogether.

The player should have a new balance for each world group they go to. This balance is private, and the player's location should not be affecting the transactions. The shop created should keep as part of its database information on the world it is in. All /balance info should be concerned primarily with the world the player is currently in.

The reason for that decision is because plugins like Vault do not even support multiple worlds, and those who try to do so always fail in the /pay exception when a player gets paid. The player ALWAYS gets paid to the world he is in, not to the world the shop is in. I know there can be an easy solution as long as the plugin who supports this method out of the box including the shops, which this does.

Think of it this way: the player has three balances based on three economy groups. The three worlds are worldA, worldB, and worldC. The string for that value could be worldA_hyperbalance, worldB_hyperbalance, etc. When player2 wants to buy something in worldA from player1, and player1 is in worldC, there should be no reason for the money player1 is making to go to his worldC account since the purchase was made in worldA.

Things to remember: the payment should not go to a player, but instead to the players account equal to the world the shop is in. Any /pay commands should only transfer money to the world in which the /pay command was executed from.

Example: GreenDot logs in to a world with three economy groups, so the player gets three new variables in their associated db labeled (something like) greendot_worldA_balance (there would be one for worldB and another for worldC). Any /pay command doesn't send to the player directly but instead to the "greendot_worldA_balance" int would be updated with the new value. Also any /balance should display the balance based on the world the player is currently in. There should be also a "/balance worlds" to see all balances across all worlds.