Today the only solution is for the payment processor to strictly control the 'memo' field so Mallory wouldn't be able to make his own PR that looked exactly like merchant Y's. But maybe it's too subtle to make payment processors embed that kind of information.

So is the main goal is to provide a structured way to embed this information in the PR and expect that user interfaces will display them to end users? If that's the case, I don't think we need an entirely secondary certificate, or cross signing from a secondary ECDSA key.

A poor solution: If the UI included some sort of certificate viewer, even just tied to the OS certificate viewer, and made the cert available for inspection, at least the merchant would have a chance to put some fields in there which a very advanced user might actually find. But this was discussed a while ago and I think the primary problem is the difficulty in getting a CA to let you embed any additional fields in your certificate in the first place, plus you don't want to generate a new cert for each merchant.

A somewhat better option: Some additional fields defined in an extension which are reliably shown in the UI. We could try to define specific fields, like 'DelegateCN' which would possibly override the primary CN... As an aside, I think you can never allow actually overriding the CN displayed in the UI directly, the most you can do is add another field in the UI to show this string. First I need to know it's from Payment Processor X, and then maybe we can let the payment processor make some additional claim, like yes you are paying irs.gov. You can't give the impression that Payment Processor X is not actually man-in-the-middle.

Maybe the simplest would be a single field expected to contain a delimited key/value string (of course JSON) which could be shown as additional lines of labeled text in the UI. I don't want to give the "merchant" too much dynamic control over what the user's screen will display, but making it somewhat dynamic might add some future proofing.