Chris Brown

There's no guarantee what page the shopper will go to next after completing a purchase. Unsetting the session value immediately upon extraction for display to the template is the most...

You mentioned checkout_confirmation. I suppose anywhere that `$_SESSION['payment']` is `unset()` or set `= ''` is a place where (maybe) this var should be cleared too. Ajax handler too. My concern...

While re-reviewing this, I found myself wondering ... Is there something about the messages you're setting via this session var, that doesn't warrant being stuffed into the Order Status History...

> Generally order instructions like mailing address information for Money Orders. I guess tacking those instructions into the order comments could work? Things that are static like that, or even...

I'm not opposed to your PR; I'm concerned about ripple effect with one-page checkout or other checkout approaches, which might not clear the var. And haven't dug into known addon/plugin...

For reference to how other modules use this var, here are a couple that aren't just cloning what the authorizenet module did for response[88]. These are real-time informational messaging to...

Probably the simplest for all is to add it to status history. Can still one-time-flash it with this payment_method_messages var. But if it's added into order-status-history, then it's always accessible...

Recently did similar with PayPal RESTful module: https://github.com/lat9/paypalr/pull/62/files

Eeks. Something went wrong in that merge/rebase.

What part of the application is generating these particular parameters in all lower case? Or is this 3rd party code that's making assumptions about valid parameters but getting it wrong?