I’m concerned that renderV2Message currently renders logo image blocks directly from item.source_url. That does not match legacy PMC behavior or the v6 renderer closely enough for first-party logos.

Legacy PMC does use <img>, but the src comes from local PayPal logo assets generated through @paypal/sdk-logos and selected by style mutations like logo.type and text.color. v6 similarly does not render arbitrary image URLs for brand logos; it maps image content blocks into known local SVG templates via brandTemplate/graphicTemplate.

For PayPal and PP Credit logos, I think we should resolve the logo locally from the semantic image block plus logo.type, logo.position, and text color. That keeps rendering deterministic, makes logo.type actually control the displayed logo variant, and avoids depending on CPS-provided asset URLs for core brand presentation.

A reasonable implementation path for this PR would be to reuse or adapt the existing legacy PMC logo resolver/data-URI assets rather than porting the full v6 inline SVG implementation. If source_url still needs to be supported, I’d treat it as fallback-only and document/validate or allowlist it explicitly.

I agree with Jeremy’s concern here. The current implementation makes the v2 IMAGE block URL the source of truth for first-party branding:

case 'IMAGE':
    return <img src={item.source_url} alt={item.alternative_text || 'PayPal'} />;

That means logo.type, logo.position, and text.color mostly affect wrapper classes/CSS, but they do not actually choose the logo asset. For example, logo.type: primary and logo.type: alternative can still render the same CPS-provided source_url.

Legacy PMC handles this differently. The logo asset is renderer-owned, and the style options select the variant:

['text.color:white && logo.type:primary', { logo: Logo.PP_PAYPAL.WHITE }],
['text.color:grayscale && logo.type:primary', { logo: Logo.PP_PAYPAL.GRAYSCALE }],
['text.color:monochrome && logo.type:primary', { logo: Logo.PP_PAYPAL.MONOCHROME }],

['text.color:white && logo.type:alternative', { logo: Logo.PP_PAYPAL.WHITE[0] }],

Then the renderer uses the resolved local/logo object:

{logos.map(({ src, dimensions: [width, height] }) => (
    <div className="message__logo message__logo--svg">
        <img src={src} alt="" role="presentation" />
        <canvas height={height} width={width} />
    </div>
))}

I think the right path is to keep this PR’s simple v2 renderer shape, but add a small first-party logo resolver before rendering the image. Something like:

resolveLogoBlock({
    block: logoBlock,
    logoType,
    logoPosition,
    textColor
});

For known first-party blocks like paypal_logo and PayPal Credit logo names, that resolver should pick from the existing PMC logo assets based on logo.type and text.color. For unknown/non-first-party image blocks, source_url can remain the fallback path.

So the behavior would be:

if (isKnownPayPalLogo(block.name)) {
    return getLocalPayPalLogo({ logoType, textColor });
}

if (isKnownPayPalCreditLogo(block.name)) {
    return getLocalPayPalCreditLogo({ logoType, logoPosition, textColor });
}

return { src: block.source_url };

That keeps the implementation small, avoids bringing back the full v5 mutation system, but still makes the core PayPal brand rendering deterministic and style-driven.

I’d also add tests for:

• known paypal_logo does not render the CPS source_url
• logo.type: primary vs alternative resolves different local assets
• text.color: white/monochrome/grayscale resolves the matching local variant
• unknown image blocks still fall back to source_url