I would like to get sample Issuer Script Template 1(Tag 71) or Issuer Script Template 2(Tag 72) value for testing the Kernel Application.
Thanks for the help....
In order that not just anyone pass some issuer script to a card and change its counters, SMI Secure messaging for Integrity( to make sure the data is not altered) and SMC - Secure messaging for confidentiality (to make sure none other can read) is used. Read EMV Book 2 Section 9
Secure Messaging for this.
Once you are done with this part, you can check Book 3 on what script you need to pass to the card.
This is packed in a Template 71 or 72 for the below reason.
Issuer scripts with tag '71' shall be processed prior to issuing the
final GENERATE AC command.
Issuer scripts with tag '72' shall be processed after issuing the
final GENERATE AC command.
Since this involves a MAC( based on your SMI Session Key) and a Cryptogram( based on SMC Session Key), I don't think a sample would help.
Related
I am working on MasterCard Acquisition project using emv Module 6.2. I can successfully generate 1st Ac and retrieve tags from it properly but i am asked to include also the result of the 2nd AC in my ICC data before transmission to the issuer.
How can i generate the 2nd AC and include it in my field 55?
There looks to be some misunderstanding in what you need. can you explain the complete context. Below is how you deal in ideal environment.
In first generate AC
if you get ARQC you send it online to issuer.
If you receive TC you approve the transaction offline.
If it is AAC you decline offline.
Now assume you get ARQC and you are not able to go online, you check default action codes and if allowed you request for TC in second generate. If you get TC your transaction is approved offline, else you get AAC and transaction is declined!!!
---------------------05-Dec-2016-----------------------
Ok then i guess this is what you are looking for. CVR Byte 1 Bit 8 will tell whether second generate AC was requested or not. In an online transaction(after 1st Gen AC) this will be 1.Can you check what is it that you are sending now ?. Check the image for more information.
Now you may not need action codes but fyi, you have three types of action codes. denial (to decline the transaction offline), online( to send transactions to issuer), default( to decide on how to proceed when online was opted but unable to. There are two sets of action codes - Terminal( which is used in terminal action analysis) and issuer( which is used by card action analysis). download emv books here to read more.
Btw, are you doing M-TIP ?
I am new to EMV development. My question is regarding Tag 91 (Issuer Authetication Data) which is sent by Issuer in EMV response. In my case, when tag 91 is missing in response packet then chip card decides to decline the transaction even if issuer has approved transaction online. So I am wondering whether Tag 91 is a mandatory tag which needs to be sent by issuer each time it approves a transaction online and what is industry wide understanding about it. Please let me know thoughts on it.
Also, In my case, Application Interchange Profile Byte 1, Bit 3 = 1 which means external authentication is required.
Are you working for Card Application or Terminal Application ?
Issuer authentication always have to be performed unless you are doing a partial chip implementation. I am sure you know that it is an additional level of security that ensures that the response came from the correct issuer.
When AIP B1B3 is on, it means card will expect tag 91.
In some cases it is even default. eg. D-PAS( Diners/Discover) AIP B1B3 is off, since it does not support External Authenticate. It is verified during second Gen AC. In such cases if the issuer wants card to not decline the transaction when ARPC not present, in the ACO( Application configuration Option), it is explicitly mentioned about partial chip implementation.
Check each payment scheme card and terminal specifications manual careful before you implement, as any loop holes in implementation may help a fraudster skip the security you wish to provide.Thumb rule, if you get ARPC from issuer, always sent it to card. Let the card decide.
From Card Application side I can add that "Application Interchange Profile Byte 1, Bit 3 = 1 means external authentication is supported, but not required. What does it mean ? Card may support Issuer Authentication, but may not required it for online transaction (issuer authentication can be mandatory or optional in card internal parameters). I.e. for optional it would be great to do auth, but if not - no problem, do online. And if Issuer have not sent tag 91 card may aprove transaction.
I'm in IT support. We have two types of correspondence:
With final users. The usual external communication with them.
With service providers (DBA, etc) Internal communication that can't be seen for the requestors.
For the first one, we use the 'answer to requestor'.
For the service providers, we use a comment and send CC to the service provider. But when they reply, RT considers their reply as correspondence and execute the actions for the 'correspondence' condition.
Then, when i wanna customize the scrips, RT doesn't distinguish between the actions: an email to the user and a replay from the provider (internal CC) are both "on correspondence" for RT, and send them both to the requestor.
I don't realize how to configure RT for send 1 y 2 to different actions.
Have I configurated something wrong? Which must I consider?
Or must I use a custom user scrip?
Thanks a lot!
RT should do what you are expecting, which is send correspondence (replies) to the requestor and send comments only to staff. There are two areas to look at to sort out why this isn't happening:
1) By default, RT's notification scrips use the Cc role to add another requestor. If you want to add a "commenter," you want to use the AdminCc role rather than Cc. This is likely the problem.
2) If that doesn't fix it, make sure you have two email addresses set up, one for correspondence and one for comment, something like support#example.com (correspond address) and support-comment#example.com (comment address). Then make sure you have your /etc/aliases file set up to route correspond with --action correspond and comment with --action comment. An initial example is provided in step 10 in the RT README.
Does anyone know how the issuer script processing flow is supposed to work on VeriFone PIN pads? As I understand it, the card processor sends back the script(s) in a 9f18 tag. The scripts marked with 71 tag are to be processed prior to the second Generate AC and the one marked with 72 tag are to be processed after. My question is, what are the sequence of commands, C34, C25 in each case? I suppose you can have one or more 71s and 72s at the same time. The VeriFone API specification says this:
Re C25: "This command contains the scripts that are received from the host. The script results are returned in the C34 response."
Also, "All scripts need to be initialized by sending a C34 to the PINpad"
So, it's not clear if you send all the C25s, one for each script, and then a C34 or perhaps the 71s before and then the 72s after the C34.
Send multiple C25's as needed, C25 only supports one script at a time. Do not try to distinguish the 71 and 72 scripts, just send them. After all the scripts, send the C34.
From the Integrators Guide FAQ section:
Q: When receiving a 72 script when do we send the C34 to the pinpad?
A: C34 is always sent after the C25. The pinpad will process based on the script before or after the second generate AC.
I read some code, it calls hunt() function of OSE(Operating System Embedded), anyone knows what is the propouse of this function?
can anyone help me on this?
According to this document Porting OSE Systems to Linux(PDF), hunt() is used to obtain a process ID from a process name for later use in sending signals, etc.
Quote from same, page 7:
When a process is started in OSE it
has to have a name assigned to it.
This name is a simple (human readable)
text string that can then be used by
other processes that wants to
communicate with the process. The name
is sent to the hunt() call which is
used to obtain the ID of the process.
The ID can then be used as an address
to send signals to.
see also the sample implementation of send_sig based on same on page 8.