EMV 3-D Secure (3DS) - Payment Authentication Protocol 5.1: 5.1 General message handling: POST, content type, Base64, versions, parsing and validation

All 3DS messages are sent by HTTP POST with the specified content type and Base64 encoding where required; each carries a message protocol version number that components check; parsers are not strict so that future versions pass; required and conditional fields must be present per Table A.1 and all fields meet format and length criteria, a failing message being treated as an error; unknown data elements are ignored and dropped before forwarding while unrecognised non-critical message extensions are passed on; response elements including transaction IDs and reference numbers must match the request; and format failures are reported with the offending element names in the Invalid Request Detail or the Error Description element. AReq validation depends on the device channel and message category matrix.