Field 34 & 56 length increase

[Sree Sija]

Hi Team, 

    

I am facing an issue with data elements 34 and 56, where I have used **LLHBINARY(36)** and **LLLHBINARY(56)** data types, which have a maximum length of **9999**. However, I need to accommodate a higher length for these fields (greater than 9999) as data needs to be bound in these fields. Could you please advise on the appropriate data type to use in this case?

Regards,

S.Sreekumar

[Alejandro Revilla]

Are you defining a new link, or connecting to an existing one?

– If you're connecting to an existing link, you’ll need to check their specs.
– If you're defining it yourself, what documentation are you following for fields 34 and 56? Is it based on the jPOS CMF?

--

@apr

--
--
jPOS is licensed under AGPL - free for community usage for your open-source project. Licenses are also available for commercial usage. Please support jPOS, contact: sa...@jpos.org
---
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jpos-users+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/jpos-users/CAKxXs%2BM7GOcQtoR%3DwNXCeNFw-GT_VENasp37yK5rcXNUZKXKRQ%40mail.gmail.com.

[chhil]

Go to the source for these packages in the GitHub repo and simply write your own field packager if they don't already exist. 

-chhil

--

[Andrés Alcarraz]

You can use types that admit longer values, existing ones or define yours, provided the other party can modify the types on their side.

But if those types are fixed by the interface there is no much you can do, you'd have to send the data on another field. Are you sure you are sending the data correctly? Track 3 (field 36) shouldn't be so long, LLH gives you up to 255 length.

----
Enviado desde mi móvil, disculpas por la brevedad.

Sent from my cellphone, I apologize for the brevity.

Andrés Alcarraz.

--

[Sree Sija]

Hi Alejandro,

     I am using the visa spec with respect to online messages please find the below details 

Field 34:

   

Field 34 – Acceptance Environment

Data (TLV Format)

Field 34 – Attributes

variable length

2 bytes, binary

1535 bytes, variable by usage, maximum 1537 bytes

Note: ISO definition supports 9999 bytes.

Field 34 – Description

This field contains acceptance environment data.

The datasets, which are in TLV format, can have multiple subelements. The TLV format is shown

below.

Positions:

1 2-3 4-1535

Subfield 1:

length

Subfield 2:

dataset ID

Subfield 3:

dataset length

Subfield 4:

TLV Subfields

Byte 1-2 Byte 3 Byte 4-5 Byte 6-1537

Length Subfield: 2-byte binary subfield that contains the number of bytes in this field.

Field 34 has the capacity to hold up to 9999 bytes. However, V.I.P. currently only supports

a maximum length of 1535 bytes.

Position 1, Dataset ID: This one-byte binary subfield contains a hexadecimal value that

identifies the TLV data that follows. Values:

l Dataset ID 01, Authentication Data

l Dataset ID 02, Acceptance Environment Additional Data

l Dataset ID 03, Additional Service Request Data

l Dataset ID 04, Additional Service Result Data

l Dataset ID 06, Device Platform Data

21 October 2024 Visa Confidential 209VisaNet Authorization-Only Online Messages – Technical Specifications

Data Field Descriptions

l Dataset ID 07, Device Common Data

l Dataset ID 56, Supplemental Data

l Dataset ID 4A, EU PSD2 Strong Consumer Authentication and Common and Secure

Communication

Positions 2-3, Dataset Length: This 2-byte binary subfield specifies the total length of the TLV

fields present in the dataset. The length is variable, depending on the data that follows.

Positions 4-1535, TLV Data: Each subfield of a dataset has a defined tag, length, and value. The

tag is used with the dataset ID value. The dataset subfields can be present in any order with

other TLV subfields.

The TLV format is used by all clients regardless of region.

Regards,

S.Sreekumar

To view this discussion visit https://groups.google.com/d/msgid/jpos-users/CAAgSK%3D%3DweJbdibnrtTr_H%2BNq%3DPaxATc41XFKppzo%2B%2BGKxDgGQA%40mail.gmail.com.

[Sree Sija]

Sorry that is not field 36 it is field 34 Acceptance environment data by the way it just got typographical error. I am trying to send all the bit in this field whereas it says 9999 in visa tech spec . But while trying to send it gets some 13k length of the data. So which data type will suitable to use more that 9999 length.

Regards,

S.Sreekumar

To view this discussion visit https://groups.google.com/d/msgid/jpos-users/CAACHDe28yHyS1SCS2EUt6WCaTm_kZZWQRirmSkudN_Ho6qYuhw%40mail.gmail.com.

[Mark Salter]

The spec is the spec, you can't change it and hope Visa will accept it they won't.

The extract you shared states that specifically...

'

Field 34 has the capacity to hold up to 9999 bytes. However, V.I.P. currently only supports

a maximum length of 1535 bytes.

'

Check you have the right data, drop fields or check you are try to present the right thing.

Your Visa contact will be able to advise!  I assure you that you don't need to do what you are trying to do.

-- 
Mark

-------- Original Message --------

To view this discussion visit https://groups.google.com/d/msgid/jpos-users/CAKxXs%2BO-nHqz%3Daw3u0D4AUdN1v3SrVkQx6%3D_b5Ww9rFtcX0qdA%40mail.gmail.com.

[Sree Sija]

Thanks for the information but the thing is while we doing visa testing with the tester they sending the DE 34 with 13k length data which is beyond 9999

Regards,

S.Sreekumar

To view this discussion visit https://groups.google.com/d/msgid/jpos-users/OJgepSWwbhNdp9rQzrY684UUhp-gY62FguSckHJgsUXpnJA5J8BOFX7lGwoGBa05UtHfEdDJHocERzQsZyGwiV9rZsc4pwdgBZ-xao50cVQ%3D%40pm.me.

[Mark Salter]

'They' are?

First you have mentioned needing to receive a message.

'They' (or you) need to comply with the visa spec if Visa are the source or the target.

-- 
Mark

-------- Original Message --------

To view this discussion visit https://groups.google.com/d/msgid/jpos-users/CAKxXs%2BN-YUEwZqgKEugwxONh7HK3aH%2BrUE-7UPyoN_sR_A%3DrzQ%40mail.gmail.com.

[Sree Sija]

They means visa team will send the request and our application switch recieve the message so that time visa team sends the DE34 with more than 9999 length.

So we couldn’t unpack the message 

Regards,

S.Sreekumar

To view this discussion visit https://groups.google.com/d/msgid/jpos-users/zUbElC99N-ANlHUqC72W6NPBXLrd7lCaELR3JuWte3BUPTwzuEfD-FO3rQtjJSUUv3NGFWof4gAEfqiOK2GyncoiGhoIZVbhyVKphrKWdU4%3D%40pm.me.

[Mark Salter]

Ask Visa for the specification their message complies with.

You have the wrong spec or are misparsing their message.

Check with Visa first for their spec and while waiting for a response check your packager.

-- 
Mark

-------- Original Message --------

To view this discussion visit https://groups.google.com/d/msgid/jpos-users/CAKxXs%2BPYDH1or%3DMiSoHTmGSaiMuLfooQqh78gQzY9h-qtfWDAw%40mail.gmail.com.

[Mark Salter]

Especially any fixed length fields present before these ones you are having trouble receiving.

-- 
Mark

-------- Original Message --------

To view this discussion visit https://groups.google.com/d/msgid/jpos-users/DaOKyUh8Y2IUNMpRMPx6KS8FG1NJnvobNYY6NTx5k9_Ch6jOJdaMu2mKPkqinVHSIm9SmHUY4aIcgqgvTXTtsAlf_MHpOdUwPjcYSBoxgcw%3D%40pm.me.

[chhil]

We use de34 with the 1500 limit. If you don't pack the subfields correctly you will cross the limit.
You should show the hexdump of de34 by just setting the mti and de34 and include the contents of each tlv that you are setting.

-chhil

To view this discussion visit https://groups.google.com/d/msgid/jpos-users/nS0jfyHlia5qdSL5R0N1CyieSWAzntmxfc7F2a2ewGWjcsNkfKVJAjeTmnclR4U2ICVNNxsgWI1CBWDpkmfCH39eAnlPUwFezPKCYbKM_SA%3D%40pm.me.