I think non-repudiation and other technical side-effects of integrating this protocol with CA signed messages are secondary to the issue at hand.
It's not a "technical side effect" it's what it does. If you don't care about non-repudiation then you don't need to care x.509 certificates in the payment protocol at all.
I'm struggling at trying to figure out your understanding of the payment protocol world. Are you under the impression that CAs would sign payment requests or control private keys? Thats not the case. Only the requester and the requestee will see the payment requests. If x.509 is used its used so that when you receive a payment request signed by a particular party your client (and anyone you show the payment request to) can use their certificate to validate that the request was signed by the right party.
The repudiation issue highlights my concerns, not because websites can send unsolicited payment requests as you allude to, but because the requester is in control of what and how it is sent, not just the circumstances under which they send. You addressed this with an unqualified assertion that:
I'm afraid I'm not following you here.
I addressed your concern by saying that it's the requester who controls how non-repudiation is provided and it's the requester who suffers if the non-repudiation is insecure. (Because the consequence of insecure non-repudiation is that a customer can produce cryptographic evidence that vendor ripped them off when they didn't really)
with one [a secure communications channel] your usage of the payment protocol is secure from privacy or theft attacks even if the x.509 certs aren't secure.
The qualitative security of this secure communications channel is not established my mere virtue of your description of it being suggestively absolute. This is just not a way to establish confidence that such statements are correct.
I have no comment on the "qualitative security" of the channel. It's entirely outside of the payment protocol, and you must have it even before a payment request can exist since you'll need to use it to negotiate the request (e.g. to do your shopping). The payment protocol doesn't provide it. Obvious readily available options today include: SSL (with its various limitations), http+tor onion URLs (though how you know you have the right site is another question), or exchanging gpg signed and encrypted payment requests.
Well, the issue is that when I ask the relocation server for a validity of a certain cert, it gets my IP.
AFAIK the payment protocol stuff does not support OCSP. I suspect that it probably shouldn't.