To generate dynamic addresses, we'll be creating a Hierarchical Deterministic (HD) wallet system for the merchant. HD wallets create a hierarchical tree of public and private keys from a single master node. This allows the user to generate and control a suite of public and private keys from the same seed phrase. The HD wallet owner can easily port their suite of keys to another hardware by porting the seed phrase used to derive the public-private key tree.

All addresses are generated from a master seed. Each time a new key pair is generated, the seed is extended at the end by a counter value. This means that, theoretically, you can generate 2⁵¹² key pairs from the same seed phrase. To back up their wallet, the user needs to back up just the master seed phrase. They can also move their key pairs easily between hardware by importing this key pair to a different infrastructure. This makes them extremely portable. This also means that the user needs to back up the seed phrase and keep it safe anytime they generate a new HD wallet as they might end up losing their funds otherwise.

As the name suggests, HD wallets use a hierarchical structure for deriving Ethereum addresses. To generate the addresses, we first create 12- or 24-word BIP39 mnemonic phrase or seed phrase. The BIP39 standard defines an implementation standard for generating deterministic wallets from a seed phrase. It has a predetermined 2,048-word list, which it uses to create a seed phrase with 12 or 24 words aligned in a selected order. The order of the words in the seed phrase is important. Random seed phrases can be used but they are not recommended due to the possibility of checksum errors.

From the seed phrase, we derive the binary seed, which is actually used to generate the key pairs. For a 128-bit seed, we use 12 words and for a 256-bit seed, we use 24 words in the seed phrase. The 256-bit implementation is considered more secure.

From this seed, we derive a master node and the corresponding master public and private key pair. We derive the child address nodes from this master node and subsequently the child public-private key pair and Ethereum address. The BIP32 standard defines the functions that are used to derive the child key pairs from this master public and private key. It also defines a hierarchical wallet structure and a nomenclature that would be used to refer to the child key pairs generated out of this mechanism.

The following nomenclature is a symbolic representation used to refer to a BIP32 HD wallet key pair:

m/i_H/0/k

Here, m indicates the master node, i indicates the account number derived from the master node, 0 indicates that the address is generated for the external keychain (used for generating public address), and k indicates the k^th key pair generated. Additionally, you can set the third parameter to 1 instead of 0 for an internal keychain for addresses for other operations such as change addresses (addresses that store transaction change amounts) and generating addresses.

You can find the network diagram representing a BIP32 hierarchical public-private key structure in the following diagram: 

The BIP44 standard builds on top of BIP32 and defines a derivation path with the following 5-level hierarchy:

m / purpose' / coin_type' / account' / change / address_index

This enables the HD wallet system to handle multiple accounts and asset types (such as Bitcoin and Ethereum). 

In this representation, we have the following:

• m: This indicates the master node.
• purpose: This is a constant set to 44 to indicate that the derivation path is of BIP44 type.
• coin type: This is constant for each cryptocurrency. For Bitcoin, this is 0 and for Ethereum, this is 60. Additional coin types can be registered with the community.
• account: This is the account type; users can use multiple types of accounts. They can be split into various categories such as donations, savings, and expenses.
• change: This is set to 0 for public addresses and 1 for internal addresses such as those holding transaction change.
• index: This is used as a child index in BIP32 key derivation. It starts at 0 and increases sequentially whenever a new address is generated.

A typical derivation path may look as follows:

m/44'/0'/0'/0/0

For our purpose, we'll be using a BIP39 mnemonic and BIP44 derivation path to build our HD wallet. We'll be varying the address index starting from 0 to generate a key structure each linked to the same root node. The coin type will be set to 60 for Ethereum. All of the dynamically generated addresses can then be easily monitored and managed. Each address will be valid only for one payment request. The mnemonic generated for the merchant wallet will be constant throughout and the merchant needs to preserve it to be able to view their total balance and access their funds. 

Let's move on to building our ecosystem, starting with the payment gateway.