writing track2
JPractitioner
Need advise on writing track2.
Suppose my PAN : [1000000000000000012]
The track2 must : [1000000000000000012=000000 ]
following the format
19 digit PAN+"=000000 "
right?
Thanks.
Victor A. Vega-Lozada
http://en.wikipedia.org/wiki/ISO_7813
Hope helps
Victor A. Vega-Lozada
1645 Pecos Street
Paradise Hills
San Juan, PR 00926
Tel. 787-384-3838
Fax. 847-241-7098
E-mail(1). veg...@gmail.com
E-mail(2). veg...@yahoo.com
E-mail(3). veg...@hotmail.com
David Bergert
1000000000000000012=YYDD if it is key entered, but this really depends on
what you are trying to do and who you are talking to and what there specs
are to see if they support this or require the other fields that Victor
provided in the wikipedia link,
David Bergert, CISSP, CISA, CPISM/A
www.paymentsystemsblog.com
JPractitioner
but generally, if its ATM card.. there's not much to it right. I mean,
there should be only the PAN on it right?
the rest of the partitions is not present and should be addressed with
dummy 0s or empty spaces or anything that will work among the parties
involve.
chhil
discretionary data.
At times you can have the pin offset embbeded in it too.
If you get a chance see the track2 data coming in a consumer
request/transaction request from the Atm .... I have not seen one that
contains just the pan.
The expiry date will be used to validate the card.
-chhil
JPractitioner
Is there anyway i can get complete track2 just base on the PAN only?
By the way, what I'm trying to do is to allow end users/public use
their ATM cards on a web based internet banking system.
This system will be linked to an ISO system.
The ISO system requires track2 data but the end user can only provide
PAN (i don't think ATM cards have exp date printed on it).
At first i thought, I could construct the track2 data because i
thought only the PAN is needed on the track2 .
Now that chhil mentioned the exp date, my solution won't do the job.
Hmm.. any suggestions on workaround guys?
On Jan 9, 4:02 pm, chhil <chil...@gmail.com> wrote:
> Each card should have a track2 that has the expiry date and some
> discretionary data.
> At times you can have the pin offset embbeded in it too.
>
> If you get a chance see the track2 data coming in a consumer
> request/transaction request from the Atm .... I have not seen one that
> contains just the pan.
> The expiry date will be used to validate the card.
>
> -chhil
>
chhil
Mark Salter
> i see..i think i have issue now.
> Is there anyway i can get complete track2 just base on the PAN only?
within the track, so you will not be able to accurately rebuild it.
You seem to be trying to present a *swiped* transaction where perhaps
only keyed data is available?
>
>
> By the way, what I'm trying to do is to allow end users/public use
> their ATM cards on a web based internet banking system.
How are you intending getting the card's details?
How are you getting the PIN?
Are these cash transactions? How are you dispensing the cash 8) ?
What product do the cardholders take away?
>
> This system will be linked to an ISO system.
>
> The ISO system requires track2 data but the end user can only provide
> PAN (i don't think ATM cards have exp date printed on it).
They may not, because they are intended to be read by the ATM - are they
chip cards too?
> Hmm.. any suggestions on workaround guys?
Depending on your answers to my questions above, I think you need to be
treating the transactions as keyed at an unattended terminal.
You should be capturing all the detail you can (expiry date and CVV2) at
the very least and perhaps even address details (AVS) to enhance your
chances of getting an auth that will also 'settle' which is therefore
not fraudulent and will not cause you or your company a financial loss.
I have the feeling that you are bending too many rules to be able to
make this work for you, sorry.
--
Mark
Aissa.Slimani
Track 2 Format :
Track2 = PAN+Separator+Expiry Date+ServiceCode+Pvk Index+ PVV + CVV
Pan : Is Variable length
Separator : is one character "=" or "D"
Expiry Date : YYMM
Pvki : is Pin verification key index usually "1"
PVV : Pin verification value 4 digits
CVV : Card verification value 3 digits
-----Message d'origine-----
De : jpos-...@googlegroups.com [mailto:jpos-...@googlegroups.com] De la
part de JPractitioner
Envoyé : vendredi 9 janvier 2009 03:32
À : jPOS Users
Objet : writing track2
Mark Salter
>
> Track 2 Format :
>
> Track2 = PAN+Separator+Expiry Date+ServiceCode+Pvk Index+ PVV + CVV
Not in every case I'm afraid, some tracks are a bit longer, and
everything following the service code can vary - across the schemes.
--
Mark
JPractitioner
something like that. I checked my ATM card too.. can't see any exp
date or cvv2 printed/embossed on it.
Is it purposely not printed/embossed on the card while actually the
value can be found on the magnetic stripe in it's track2?
On Jan 9, 5:08 pm, chhil <chil...@gmail.com> wrote:
> I think they would have a exp date please double check. Once you have the
> expiry you can manually create the track2 . This usually how they do it when
> the card swipe does not work and they person manually enters the values in
> at a POS. I also assume you would enforce cvv2 values entered on the web
> along with address verification.
>
> If the expiry is not present I am not sure the implications of using the
> other available data from a authorization perspective.
>
> -chhil
>
Mark Salter
> this is just plain ATM card without association with Visa Debit or
> something like that. I checked my ATM card too.. can't see any exp
> date or cvv2 printed/embossed on it.
This could mean it is simply for use in a specific ATM and not anywhere
else?
>
> Is it purposely not printed/embossed on the card while actually the
> value can be found on the magnetic stripe in it's track2?
The card Issuer decides - within guidelines - what goes on the card and
where.
It is really a balance between making it easy for the cardholder/ATM,
whilst giving the Issuer enough detail to provide the instruction to
dispense cash with the confidence of knowing that the cardholder is the
person the card suggests they are and that the card is the one they
produced.
A card that is meant only to be inserted into an ATM - along with a PIN?
- does not need extra security.
A card that can be used under chip, keyed or acquired via an impression
needs to have more details available to the merchant/cardholder so that
they may gather the evidence needed to go to the Issuer.
It is all down to risk.
Ask yourself how certain you will be that the card number keyed in
belongs to the cardholder at your web interface?
Are you happy to take all financial losses/costs if a transaction you
acquire is fraudulent? Be certain that neither the card Issuer nor the
cardholder will accept a loss in this scenario.
--
Mark
JPractitioner
David Bergert
Does it look to match the expdate or simply check to see if it is in the
future, - then you can pass a *cough* hard-coded exp-date in this case. Also
you said it is an ISO system, does it not support a PAN in DE 2 in some
transaction set ?
David Bergert, CISSP, CISA, CPISM/A
www.paymentsystemsblog.com
> -----Original Message-----
> From: jpos-...@googlegroups.com [mailto:jpos-...@googlegroups.com] On
> Behalf Of JPractitioner
JPractitioner
It might not need a date at all, we still to find out for sure.
but i'll take a note on this
Mark Salter
>
> It might not need a date at all, we still to find out for sure.
> but i'll take a note on this
>> What are the "Expiration Date" Checking Rules on the authorzation host ?
>
> yes they require DE 2 for PAN, no issue with that. Why do you ask ya?
They might not need track2 (DE35?) if they can accept a keyed style of
transaction.
They still might need more detail though to complete this flavour, which
will then depend on what is available on the card (CVV2) or from the
cardholder (Address perhaps).
--
Mark