Thanks for the feedback guys!

I would also like to understand the problems you've been having with certificates in node.js. FYI the CA cert is *not* supposed to be included, this matches what the code in Bitcoin Core and bitcoinj expects. It may be that Bitcoin Core accepts a redundant CA cert being provided, but if so that'd fall in the category of openssl being generous. If there are issues here, it sounds like an issue with node and not the spec. I'm not even sure why it would matter - certs are just byte arrays so if node can sign a hash with a private key, the rest should be easy.

With regards to the PKI I'd appreciate it if we don't go around that circle again. Please remember one of the primary goals of all of this is to show to the user on their hardware wallet a meaningful name. Almost all merchants on the Internet already went through the process of associating a public key with their name, using X.509.

Whilst for now your payment requests will have to be signed as BitPay, this isn't ideal for the longer term and I'd like to design a protocol extension to allow merchants to delegate their signature authority to you. In this way they would be able to sign a secondary key with their own ssl key as part of the enrolment process, and after that you could sign payment requests on their behalf. Kind of like a Bitcoin  specific subcert (and there would be no reason to use X.509 format for that).

Re: feedback url. How is this different to a result code in PaymentAck which already caused much debate? Surely we want a payment to either work out boy work and for that decision to be made immediately? Your invoice page switches to a completed state once you see a tx be broadcast so that's the "done" state today even if there are caveats. I'd like to see a status code added to PaymentAck so receivers can reject payments if they are bad in some way.