Network Profiles: Authorization, Clearing, and a Teaching Adapter

What this module can establish

ISO8583 supplies a message framework; a network profile supplies the field meanings, encodings, allowed combinations, and operational rules needed for interoperability. A message name or an MTI does not identify a complete wire specification. Moov's ISO8583 implementation explicitly supports custom message specifications, and pyiso8583 configures data encoding and length encoding separately.

The historical names visa-de63-parser, VisaDE63, and AdaptToVisa are preserved for exercise compatibility. Their VS envelope, tag assignments, hex-ASCII bitmap requirement, DE62 mapping, and timestamp conversion policy are synthetic course conventions, not an authoritative Visa BASE I specification. Production integrations require the applicable licensed network/processor profile and its version. Nothing here establishes certification or universal Visa requirements.

Separate an authorization from completion

An authorization can approve a reservation without establishing that clearing and settlement have completed. The dual-message teaching flow has an authorization exchange followed by a separate clearing step. Visa's public glossary distinguishes these stages. BASE I and BASE II are used here as historical authorization and clearing context; no private wire tables are inferred from those labels.

Do not classify entire competing networks as exclusively single-message or dual-message. Mastercard's transaction processing rules discuss both systems. The route and product determine the applicable procedure.

Suppose request A times out locally and its approval arrives later. The timeout establishes that the caller lacked an answer at its deadline; it does not prove A was unprocessed. Persist the original identity and unresolved state. A configured reversal or status/reconciliation workflow must deal with the late approval. Sending a reversal does not itself prove the reversal completed. Exact MTIs, retry IDs, response interpretation, and timeouts belong to the selected profile.

Decode the exercise's envelope by cursor position

The DE63 task receives bytes after removal of the outer LLLVAR prefix. Its course format is:

"VS" | repeated (one-byte tag | two ASCII length digits | value bytes)

Use this valid literal:

VS115123456789012345202I25040002

Start offset	Read	Cursor after read	Meaning in this exercise
0	VS	2	Envelope identifier
2	1 + 15	5	Tag 1 has 15 value bytes
5	123456789012345	20	TransactionID field
20	2 + 02	23	Tag 2 has two value bytes
23	I2	25	AuthCharIndicator field
25	5 + 04	28	Tag 5 has four value bytes
28	0002	32	NetworkIDCode field

The length counts bytes, excluding tag and prefix. 15 is ASCII decimal fifteen, not hexadecimal 0x15 or a two-byte binary integer. This schema has one-byte tags; it is not BER-TLV. A tag named A does not imply a multibyte EMV tag.

The reference stores unknown tags in RawSubelements. Repeated tags remain in the parsed sequence; the final occurrence wins in map/struct views. Values are copied, so changing the input bytes afterward does not change stored raw values. Parsing checks framing, not authenticity or semantic field lengths.

The existing permissive parser ignores a final one- or two-byte fragment that cannot form a header. This is an exercise compatibility rule, not a safe inference that arbitrary trailing bytes are legitimate production padding. A complete header with a value extending past the end is an error. The statement specifies these boundaries so tests do not silently disagree with the lesson.

Build and validate the same format

For tag Z, value AB, output is Z02AB; a full envelope is VSZ02AB. BuildDE63 derives length from Value, ignoring the supplied Length member. Its input contract restricts values to at most 99 bytes because two decimal digits cannot encode 100. A raw builder does not validate the network's transaction semantics.

Reconstruction: after VSZ03AB, which condition fails? There are only two value bytes for a declared three, so parsing must fail. After VSZ02ABQ, the course parser returns Z's value and ignores the single-byte suffix under its declared permissive rule.

Adapt fields without inferring network facts

The adapter exercise converts a binary bitmap such as byte 0x72 into the two characters 72. One complete primary bitmap is 8 binary bytes or 16 hex-ASCII characters. Encoding conversion changes representation, not which bits are set. The actual target network may choose either representation; this task chooses hex-ASCII.

The task also strips outer track sentinels and normalizes selected fields. Its DE62 mapping is a lookup rule used to practice adaptation. A terminal's PIN capability does not prove that a PIN was entered or verified. Do not infer authentication from that exercise mapping in an operational system.

AdaptToVisa returns a separate message so callers retain the original for correlation or retries. Formatting can be lossy: trimming text and shortening fields can discard data. The problem states the intended behavior; a real integration must decide which invalid values to reject before losing information.

Dates cannot recover absent context

A yearless DE7 value needs a reference year. A time-only DE12 needs a date to handle timezones and daylight-saving rules; DE13 alone has no time of day. The exercise helper uses the current date/year as a convenience and converts fields independently. It cannot guarantee correct conversion for arbitrary historical transactions or consistent date rollover across separate fields.

For a known full timestamp 2026-01-01 00:30:00 +04:00, UTC is 2025-12-31 20:30:00. Merely changing the time and keeping the original date would be wrong. A production adapter should use a complete timestamp plus an explicit timezone and documented ambiguity policy. Local transaction fields must retain their profile-defined meaning; they are not universally UTC.

Check your implementation reasoning

1. Does VS prove that bytes came from Visa? No. It is a parseable label in this course envelope, not authentication.
2. Can a missing DE63 alone identify why a transaction failed? No. Field requirements and error handling depend on the profile.
3. Does an approved authorization prove clearing completed? No. These are separate lifecycle states.
4. Does converting a bitmap to printable hex change field 7's presence? No. Decode the representation and test the same bit.
5. Can a standalone DE12 time determine the correct UTC date? No. The missing date/context must come from elsewhere.

Implement the two linked exercises with their declared synthetic contracts, then use the checkpoint to distinguish framing facts from unsupported business conclusions.