I think in principle, for mail-order and ecommerce, you're supposed to put a phone number in the field. For in-person transactions, you're supposed to put city and state.
The problems:
* Not everyone has it set up correctly, either inadvertently,or as an attempt to disguise questionable transactions.
* Ir's a cramped field at best, so you may end up with UNRDBL ABREVS.
* Some space gets burnt with payment aggregatoer/gacilitator IDs (the "SQ" part of the example.
A lot of this stuff is remarkably underused. There's Level 2/3 data, a very detailed interface to document individual receipt line items-- but it's typically only used for corporate cards. So even if someone bothers to configure their shopping cart to correctly populate it (often ignored, since most carts prioritize "we support 2340 different payment platforms, at a minimal level" over offering all bells and whistles, the consumer still won't see the info that would help say "oh, SQBLABLABLABLA was where I bought the blue widgets."
The problems:
* Not everyone has it set up correctly, either inadvertently,or as an attempt to disguise questionable transactions. * Ir's a cramped field at best, so you may end up with UNRDBL ABREVS. * Some space gets burnt with payment aggregatoer/gacilitator IDs (the "SQ" part of the example.
A lot of this stuff is remarkably underused. There's Level 2/3 data, a very detailed interface to document individual receipt line items-- but it's typically only used for corporate cards. So even if someone bothers to configure their shopping cart to correctly populate it (often ignored, since most carts prioritize "we support 2340 different payment platforms, at a minimal level" over offering all bells and whistles, the consumer still won't see the info that would help say "oh, SQBLABLABLABLA was where I bought the blue widgets."