Most Bitcoin IPN providers work in the following way:

1. Merchant submits invoice information (i.e. amount, their btc address, user ID and unique invoice ID).
2. The IPN provider inserts this information to a DB and generates a unique btc address for this specific invoice.
3. The merchant receives the unique btc address from the IPN provider and presents it to the end-user.
4. Once the end user pays the agreed upon amount and the transaction receives enough confirmations, the IPN provider submits a notification (i.e. POST request) and sends the funds to the merchant's wallet address.

The issue that I see here, is that a fee is paid twice. Once from the end-user to the IPN provider's unique BTC address, and again from the IPN provider to the merchant's wallet address.

I was thinking about a different approach, where the end-user sends the funds to the merchant's wallet, and the IPN provider "listens" to the BTC address. In this case the invoice identifier would be the BTC amount instead of the btc address. For example:

1. Merchant creates a new invoice for 0.001 BTC, and submits its wallet address along with the invoice information to the IPN provider.
2. The IPN provider "generates" a unique number for that specific invoice, which should be very close to the original amount (i.e. 0.00100052 - a "gap" of 1 cent). The IPN provider inserts the data (with the new amount) to its database and starts "listening" to the merchant's wallet address.
3. Once the IPN providers spots a transaction for that particular amount (0.00100052 in our example), it flags the invoice as completed and informs the merchant.

With the example above, a fee is only paid once, and the funds are transferred straight to the merchant which means that in all stages, either the customer or the merchant own the funds - never the IPN provider - a P2P IPN.

What could be the cons of this method?