User A send a transaction to user B. Those transactions are bundled together into a merkle tree. User A and B can both use the transaction plus the merkle root, plus the merkle path to prove the merkle root in the block header is correct.
Let me rephrase your question to ensure we are on the same page:
Alice pays Bob. When Alice submits her transaction to the network, it is still unconfirmed. The transaction gets confirmed by being included in a block. The block header includes the merkle root which is a cryptographic commitment to the included transaction set (in order).
Neither Alice nor Bob know the merkle path at this point. Depending on the thin client they're running, their wallet will either request a full node peer to flag transactions that match a bloom filter encoding their interests (BIP 37 (deprecated)), they trust a service provider to know their addresses (Electrum, various centralized wallet services), or they download compact client-side block filters which they can use locally to see whether a block might include anything of interest (BIP 157/158).
Once the thin client learns about a transaction they're interested in, the thin client either requests the merkle block for the transaction specifically or the complete block from a full node peer or their service provider. The Merkle block datastructure has all the necessary hashing partners to retrace the full branch from the transaction leaf to the root as well as the block header (as does the complete block of course). That's how they know!
As chytrik wrote in another answer, most thin clients follow along with the network by synchronizing the block header chain. Since they do not parse the complete blocks, they do not keep track of the full ledger of bitcoin balances (the unspent transaction output set), and therefore cannot validate transactions. They can however perform basic validity checks on blocks such as whether they fulfill the current difficulty requirement, and whether the block header's content actually matches the given hash.
