Visa message support adjustment and subfield encode and decode support

[blima1]

Could I make a pull request with some changes to support the Visa transaction?

• length byte encoding/decoding
• subfield encoding/decoding

I am preparing a visa transaction beater to be used in capacity tests at my company.

[knovichikhin]

I think Visa transactions should be supported. Which part is not supported?

For field encoding/decoding, PR is welcome. Couple of things:

• Current supported version is 3.7. We can also move to 3.8 because 3.7 is deprecated at the end of the next month. So any new code should be limited to what's in 3.7 or 3.8. I'd also prefer no 3rd party dependencies.
• This package uses numpy docstring (I believe I followed it for the most part): https://numpydoc.readthedocs.io/en/latest/format.html#docstring-standard. It's the most readable if someone simply looks at the code.
• Currently there is no module structure in place for field parsing, so we need to come up with one. You can think about it, but it needs to consider that someone else may decide to add parsers for other orgs (e.g. MasterCard, UPI/CUPS, NYCE, Base24, etc). So maybe something like this: iso8583.visa.FieldXX where FieldXX is an encoder/decoder for Visa field XX. I don't know if this needs a breakdown between Visa SMS and Base I (?). I'm more familiar with SMS.
• The main decoder.py/encoder.py operate on strings and will need to stay that way. Field parser can take a string or raw data in and produce higher level representation of it.

Also, if you want or prefer, you can create another package that focuses on Visa field parsing. I can link to it. It does not have to be here.

[brunojet]

About size encoding type VISA represents its size in binary and not bcd or ascii. The print below demonstrates how the message is received by the Visa authorizer.

Regarding support for subfields, I noticed that the project does not provide for treatment of subfields within a field. In the case of visa, it is very similar to handling a message, except for the possibility of having a bitmap size other than 8 bytes.

At the moment I only needed to treat some fields with subfields and I didn't do all of them. I'm going to fork the master and I'm going to parse and test all the fields supported by the visa specification.

Then I'll check with Mastercard if there are similarities with what I'm doing with Visa. As soon as I finish Visa I can use Mastercard.

I have worked for over 15 years with C applications in POS terminals on various platforms and I am new to Python (only 2 months). I'll try to identify everything you asked and do in my fork before I warn you about a pull request.

Thank you very much for your attention.

[brunojet]

I will fork in https://github.com/brunojet/pyiso8583 because the blima1 account is private to the company.

[knovichikhin]

Got it on the spec. I will update the parser to handle binary length. You don't need to worry about it.

Regarding support for subfields, I noticed that the project does not provide for treatment of subfields within a field.

There is a simple reason for this. It's a full time paid job to do this by someone with access to the latest releases of the specs. I don't have time and motivation for that. It will also invite implication of free future support. Situations such as where this package supports Visa SMS June 2022 released, and someone comes in and says that field X is not correct because it was updated in October 2023 release with some massive additions.

However, I welcome people to volunteer their time.

At the moment I only needed to treat some fields with subfields and I didn't do all of them.

Do as much or as little as you want.

Then I'll check with Mastercard if there are similarities with what I'm doing with Visa.

MasterCard is a completely different story, especially in some of the custom fields.

I am new to Python (only 2 months). I'll try to identify everything you asked and do in my fork before I warn you about a pull request.

Take your time. If you find something that works well internally then feel free to contribute. When I build something like this last time (MasterCard Debit), I used Python dataclases with additional methods to pack and unpack raw data. IMO, dataclasses is a good choice considering I don't want 3rd party dependencies.

https://docs.python.org/3/library/dataclasses.html

Also, if you are building internal tools, take a look at my other packages:

• https://github.com/knovichikhin/psec - useful for generating MAC/encrypted PIN block, CVV/CVC/CVD.
• https://github.com/knovichikhin/pyemv - TLV parser, can generate ARQC/ARPC/AAC for Visa CVN 10, 18, 22. Visa CVN 22 is not tested live, just written to a spec.

[brunojet]

In the case of Visa and several acquirers, the subfield is basically an ISO message with no header and no mti, but with a bitmap of variable size.

In my proposal, it's just adding the support itself and there is no specific treatment of the field (exactly so as not to be bound by any specification).

I'm totally against making features that only apply to one type of project.

[knovichikhin]

I added support in binary length in 3.0.0.

[blima1]

I will download and test here. Thank you very much!