Your thoughts go into the right direction in my opinion, although I hope I can convince you in the following to take a slightly different route.
Let's analyze your requirements:
You want to guarantee mutually authenticated requests for payment processing, i.e. a client initiating such a process would want to be sure of talking to the right server, and a server accepting a request would like to be sure of the identity of the peer. So the solution has to have server authentication plus client authentication
Integrity of the requests is another must - nobody should have the chance to alter anything in the request while it is on its way
These were the major requirements you listed. I would also add privacy to the mix - you possibly don't want anyone listening in on the traffic to be able to learn what the client purchased or the amounts of money they pay.
And now comes the tricky part. You can indeed achieve these goals with a mix of asymmetric and symmetric cryptography. But I think a manual scheme is not appropriate here, and here's the reasons why:
You are trying to secure the transport and the protection is ephemeral - once the transaction is done, you need no longer persist the request data (unless you try establishing an audit trail)
By securing the transport, you are actually designing a security protocol here. And getting them right is probably one of the hardest problems in cryptography. If you read about the Needham-Schroeder protocol: they were dead serious about this protocol for a couple of years, convinced that it was perfectly fine. And they had every right to do so, being decorated cryptographers and all. But three years later they were presented with a valid attack... you probably know where I'm heading and you yourself already mentioned the various things you would have to care about when trying to make this thing secure...
But not all is lost, because there's a perfectly fine protocol already doing all of the above and much more for you. It's TLS! It supports all of your requirements and has been tested by millions, so chances are overwhelming that your manual solution won't be able to compete with it anyway. And on the bright side, it's also already supported in all popular programming languages, no need for you to invent anything.
PS: When to use signatures vs. when to use TLS: it has always helped me to analyze my situation asking me this question: "Do you want to secure the transport?" vs. "Do you want to secure the data/document?"