One Way Merge Replication

I have a replication question. I have a rather large transaction database, that until now received only transactions from a local application. At the moment we're deploying the same application at pretty much the other side of the world.

There is a VPN connection between both locations, but the application will run locally and use the local database for latency reasons. Now I want to maintain a central database (for reporting purposes). What is supposed to happen is the following. Both databases will receive new transactions and updates to existing ones, each by its own local application, but I want the transactions of the remote database (and updates to existing transactions) to be merged into the main database (but not other way around!). There will be no conflicts between these transactions, since each transaction ID will be prefixed with a location ID.

Initially I thought I could use SQL Server's merge replication, but this requires both databases to contain the same contents. This is not what I want, since the main database is far bigger than the remote database is supposed to become. Also I do not need the transactions from the main database to be in the remote database.

As an alternative I was thinking along the following line: replicate (using transaction replication) the remote database to the central database server in a separate database and create a view that UNIONs both databases. Then insert and update in the physical databases, but use the view for reporting purposes. I'm a bit afraid such a view will be much slower. Perhaps this is an irrational fear since the underlying databases will be correctly indexed? Also this would mean some changes in the application.

Anyway, I was hoping for some feedback on this. Perhaps there are other ways to make the above happening?