I think you can't ever be sure of that. The data exchange usually is like this
1) Customer browser on seller site: the customer clicks on Pay
2) Seller server to payment gateway (hopefully over an encrypted channel): I'm S (important) and somebody is about the come to you to buy Y with order number Z. In case of success please redirect to U1, in case of failure redirect to U2.
3) Payment gateway to seller server: ok, thanks, my transaction code for this is T
4) Seller server to browser: redirect to the payment gateway (the browser has been waiting since step 1) for order Z (you don't mind if somebody pays for you)
5) Customer on payment gateway (https): check that S and Y are what is expected (this is fundamental), type in credit card data, click Pay.
6) Payment gateway to seller server (on a safe channel): transaction T has been paid for.
7) Payment gateway to customer browser: redirect to U1
8) Customer browser on seller server: page U1 says thank you for paying, goods are being delivered.
What makes you sure that the payment gateway is not a rogue one and will pay your seller? It's that you can see the order's data in step 5. However you can't be sure that the seller site has not been MITMed and you've been redirected to the wrong payment gateway. The only safeguard for that is the authentication and encryption in step 2, but that's not under your control. Https between the customer and the seller site doesn't make the transaction any safer.
On the other side, what makes the seller site safe against scammy customers is step 6, but I saw some eshops relying only on the information sent in step 7, which in some cases could be forged by the client.
1) Customer browser on seller site: the customer clicks on Pay
2) Seller server to payment gateway (hopefully over an encrypted channel): I'm S (important) and somebody is about the come to you to buy Y with order number Z. In case of success please redirect to U1, in case of failure redirect to U2.
3) Payment gateway to seller server: ok, thanks, my transaction code for this is T
4) Seller server to browser: redirect to the payment gateway (the browser has been waiting since step 1) for order Z (you don't mind if somebody pays for you)
5) Customer on payment gateway (https): check that S and Y are what is expected (this is fundamental), type in credit card data, click Pay.
6) Payment gateway to seller server (on a safe channel): transaction T has been paid for.
7) Payment gateway to customer browser: redirect to U1
8) Customer browser on seller server: page U1 says thank you for paying, goods are being delivered.
What makes you sure that the payment gateway is not a rogue one and will pay your seller? It's that you can see the order's data in step 5. However you can't be sure that the seller site has not been MITMed and you've been redirected to the wrong payment gateway. The only safeguard for that is the authentication and encryption in step 2, but that's not under your control. Https between the customer and the seller site doesn't make the transaction any safer.
On the other side, what makes the seller site safe against scammy customers is step 6, but I saw some eshops relying only on the information sent in step 7, which in some cases could be forged by the client.