I am developing an android payment application which is emv compatible. In this application con-tactless card acceptance has been integrated, how ever for the certification purposes it is required to determine the CVM applied on the transaction. for a con-tactless transaction how do we determine the CVM method applied for the transaction ? for example if the transaction amount is above the CVM limit and the user entered online pin, at the end I want to determine that ,the user has entered online PIN
There is no update from terminal to mobile app on the used CVM during tap. If using a a mobile wallet( with Wallet providers Visa and MasterCard ) you will get a notification from MDES/VTS after transaction completion, in which you can see(give a try ) whether the CVM used is present along with the transaction Approved/Declined status. If that too is not available, the only way left behind is to get it from the issuer system.
If you have "lame" EMV kernel which don't provide CVM output for CTLS then your only option is to parse it from transaction output. Unfortunately every card issuer using their specific way of "handling" CVM output.
Step 1
Determine card issuer and card type. Use AID (tag 4F) to do it.
Step 2
Visa and UnionPay EMV - you need to parse tag 9F6C - Card Transaction Qualifiers where
Byte 1 bit 8 set to 1 means Online PIN. Byte 1 bit 7 set to 1 means Signature.
JCB EMV - (JCB have 2 other modes but it's not in use in my region. Possibly it's already deprecated for whole world.) you need to parse tag 9F50 - Cardholder verification status where 00 means No CVM. 10 means Signature. 20 means Online PIN.
MasterCard EMV - (MasterCard have also MSR mode but it's not in use in my region) you need to parse tag 9F34 - CVM Results. This is same tag as for contact transactions so just check and follow contact EMV book rules.
MasterCard Mobile - I'm not 100% sure but it has to be same as for MasterCard EMV.
Amex EMV - parse tag 95 - Terminal Verification Result. When Byte 3 bit 3 is set to 1 then CVM is Online PIN else No CVM.
Amex Mobile - parse tag 9F71 - Mobile CVM Results. Check corresponding EMV Contactless book for specs.
For other issuers you have to check corresponding EMV Contactless books.
Related
I was trying to build an application which will monitor activities on Peripheral through XFS.
Whenever there is a change in Cash Units, application receives CASHUNITINFO_CHANGED event.
Based on which I fetch the Cash Unit Information using CASHUNITINFO command.
I find that the Dispenser XFS API does not give me the correct counter in one of the NCR ATM. I have tested the same code in both Diebold and Wincor and I am getting correct counter values.
I am using the WFS_INF_CDM_CASH_UNIT_INFO command to fetch ulInitialCount, ulCount, ulRejectCount, ulDispensedCount, ulPresentedCount for each logical cash unit.
For example, this is what I see in XFS...
FROM XFS
but in ATM cash counter admin screen, the counters is different as shown below.
FROM ATM
Thanks,
Srivathsan
I read here that EVM cards will sign some transaction data.
I would like to do this with my card, using my phone, and verify that the signature on the result is correct.
To start, I issued this command ("request APDU"):
00:A4:04:00:0E:32:50:41:59:2E:53:59:53:2E:44:44:46:30:31:00
One of the "Application IDs" was this:
A00000038410
So then I issued this command ("Select Payment application"):
00:A4:04:00:07:A0:00:00:00:03:10:10:00
and it returned this "Processing Options Data Object List (PDOL)":
9F66049F02069F37045F2A02
I read here how to decode this, because I couldn't find the official spec anywhere:
9F6604 - the tag 9f 66 represents the terminal transaction qualifiers
9F0206 - tag 9f 02 stands for authorized amount. The PDOL list must have the amount, authorized, coded into 6h bytes added to it.
9F3704 - tag 9f 37 stands for unpredictable number, thus encode such a number in 4 bytes and add it to the list
and here how to decode this:
5F2A02 - TX currency code
I understand the next step is to run "Get Processing Options" but this is where I got stuck. I tried:
80:A8:00:00:02:83:00:00
80:A8:00:00:12:83:10:01:02:03:04:05:06:07:08:01:02:03:04:05:06:07:08:00
80:A8:00:00:12:83:10:F3:20:40:00:00:00:00:01:00:00:04:04:06:03:05:08:00
80:A8:00:00:02:83:10:F3:20:40:00:00:00:00:01:00:00:04:04:06:03:05:08:00
All gave back a result of 6D:00 (Instruction code not programmed or invalid).
I tried looking in "emv book 3" and "emv book 4" but neither seem to contain the relevant information.
What do I need to do next in order to make a transaction, sign, and check the result?
Your GPO commands needs to provide the PDOL values requested by the card. The requested tags are:
9F66 - 4 bytes
9F02 - 6 bytes
9F37 - 4 bytes
5F2A - 2 bytes
So the commands needs to provide these in the same order, with expected lengths.
Assuming you want to send the following sample values:
9F66: 11223344
9F02: 112233445566
9F37: 11223344
5F2A: 1122
Your GPO command will look like this:
80A800001283101122334411223344556611223344112200
Where the PDOL data is 11223344112233445566112233441122.
Hope this helps
If PDOL found in response of select application, here you need to pass the value of PDOL tags in GPO command,
can find a very good article Here. hope it helps.
I want to define a Ring Group that, when called, rings one extension and one external number (mobile phone). What is the best way to achieve that?
Right now only the extension is called. So just entering an external number in the Destination field does not work, the logs say
[NOTICE] switch_cpp.cpp:1376 [ring groups][call forward all] user_exists id <mobileno> <domainname>
and later
[DEBUG] switch_ivr_originate.c:3865 Originate Resulted in Error Cause: 27 [DESTINATION_OUT_OF_ORDER]
It will check all calls using the dialplan to see if the destination is a local number for an external number it should say user_exists false every time.
This [DESTINATION_OUT_OF_ORDER] indicates that it may not have found a matching outbound route that matches the number of digits of the external phone number. Or it may mean that your carrier rejected the call maybe didn't like the caller ID that was sent. Easiest thing to try is attempt it with an outbound rout to different carrier.
In case you weren't aware FusionPBX 4.4 was release on 5 April 2018. Instructions to upgrade are post on docs.fusionpbx.com. Search term upgrade (version upgrade).
I'm having a problem with an EMV MTIP contactless test and I don't understand why. The transaction is being accepted, but my test tool is displaying some failures around the cardholder verification and the CVM used (or not used).
The issues are:
TVR Byte 3, bit 8, expecting 0, Received 1 (cardholder verification was not successful)
CVM Results are equal to 3F0001, 5F0302/0 were expected
My understanding of this is both of these are saying no CVM occurred, although it should have. I don't understand why, as the amount of 3000 is above the CVM required limit. I have my terminal capabilities for contactless set to 60 B8 C8, which indicated support for:
Plaintext on ICC
Signature
Enciphered PIN Offline
No CVM Required
As I see it, 5F0302 would indicate the successful use of No CVM Required, where as 3F0001 indicates that CVM verification failed.
Can anyone shed some light on why this would happen, and if I'm doing something wrong?
A full log of the transaction is too big to include in the post, but can be found here: Pastebin Transaction Log
Edit 1:
I'm fairly certain I'm loading the correct CAPK's. They're being loaded from an XML file as per the terminal vendor's example, with the following values:
<tag id="E2">
<tag id="DFC316">A000000004</tag>
<tag id="9F22">EF</tag>
<tag id="DFC317">A191CB87473F29349B5D60A88B3EAEE0973AA6F1A082F358D849FDDFF9C091F899EDA9792CAF09EF28F5D22404B88A2293EEBBC1949C43BEA4D60CFD879A1539544E09E0F09F60F065B2BF2A13ECC705F3D468B9D33AE77AD9D3F19CA40F23DCF5EB7C04DC8F69EBA565B1EBCB4686CD274785530FF6F6E9EE43AA43FDB02CE00DAEC15C7B8FD6A9B394BABA419D3F6DC85E16569BE8E76989688EFEA2DF22FF7D35C043338DEAA982A02B866DE5328519EBBCD6F03CDD686673847F84DB651AB86C28CF1462562C577B853564A290C8556D818531268D25CC98A4CC6A0BDFFFDA2DCCA3A94C998559E307FDDF915006D9A987B07DDAEB3B</tag>
<tag id="DFC318">03</tag>
<tag id="DFC31A">21766EBB0EE122AFB65D7845B73DB46BAB65427A</tag>
</tag>
<tag id="E2">
<tag id="DFC316">A000000004</tag>
<tag id="9F22">F1</tag>
<tag id="DFC317">A0DCF4BDE19C3546B4B6F0414D174DDE294AABBB828C5A834D73AAE27C99B0B053A90278007239B6459FF0BBCD7B4B9C6C50AC02CE91368DA1BD21AAEADBC65347337D89B68F5C99A09D05BE02DD1F8C5BA20E2F13FB2A27C41D3F85CAD5CF6668E75851EC66EDBF98851FD4E42C44C1D59F5984703B27D5B9F21B8FA0D93279FBBF69E090642909C9EA27F898959541AA6757F5F624104F6E1D3A9532F2A6E51515AEAD1B43B3D7835088A2FAFA7BE7</tag>
<tag id="DFC318">03</tag>
<tag id="DFC31A">D8E68DA167AB5A85D8C3D55ECB9B0517A1A5B4BB</tag>
</tag>
<tag id="E2">
<tag id="DFC316">A000000004</tag>
<tag id="9F22">FA</tag>
<tag id="DFC317">A90FCD55AA2D5D9963E35ED0F440177699832F49C6BAB15CDAE5794BE93F934D4462D5D12762E48C38BA83D8445DEAA74195A301A102B2F114EADA0D180EE5E7A5C73E0C4E11F67A43DDAB5D55683B1474CC0627F44B8D3088A492FFAADAD4F42422D0E7013536C3C49AD3D0FAE96459B0F6B1B6056538A3D6D44640F94467B108867DEC40FAAECD740C00E2B7A8852D</tag>
<tag id="DFC318">03</tag>
<tag id="DFC31A">5BED4068D96EA16D2D77E03D6036FC7A160EA99C</tag>
</tag>
Edit 2: The Terminal Risk Managment Data in use is 0CB4000000000000, which shows support for:
Contactless
No CVM required
On Device CVM
Contact
Plaintext PIN
Signature
Enciphered Offline
On Device CVM
Edit 3: The terminal type as set in 9F35 is 22 = Attended, Offline with Online Capability
Edit 4: The TAC for Denial is all zeros. The TAC for Default and Online is FC50808800, indicating:
Offline data authentication was not performed
SDA failed
ICC data missing
Card appears on the terminal exception file
DDA failed
Combined DDA/AC generation failed
Expired application
Requested service not allowed for card product
Cardholder verification not successful
Transaction exceeds floor limit
Merchant forced transaction online
TVR Byte 1 bit 8 = 1 - Offline data authentication was not performed
TVR Byte 3 bit 8 = 1 - Cardholder verification was not successful
This show that your terminal have no required Certification Authority Public Keys (CAPK) loaded for Offline data authentication. Load correct test Public Keys with indexes 0xEF, 0xF1, 0xFA. These keys used for both contact and contactless M-TIP cards.
You did not mention your MasterCard contactless tag 0x9F1D value - The Terminal Risk Management Data.
You did not mention your Terminal MasterCard/Maestro Online, Denial, and Default TACs.
You did not mention your Terminal Type. Attended/Unattended. Maestro should have specific implementation for unattended environment regarding NoCVM.
Terminal Capabilities Tag 0x9F33 you noticed usually replaced by your terminal brand Contactless Kernel initialization settings/tags.
I see SDA enabled in your case. According PayPass M/Chip Requirements - "Newly deployed PayPass terminals do not support SDA, and are not configured to support SDA." SDA is a weak authentication.
In the terminal Contactless Kernel you should have configured different CVM capabilities for transaction amounts below CVM Required Limit (NoCVM) and above CVM Required Limits. Because of Market requirements Online PIN might not be supported, Signature should not be supported for Unattended terminals, so, only NoCVM can be used in this case for amounts above CVM required limit. Plus specific implementation for Maestro processing.
I would suggest to look into MasterCard PayPass—M/Chip Requirements and open another interesting items about the MasterCard/Maestro contactless cards processing.
I was wondering if anyone could help me understand difference between ISO 8583 Field 22 i.e. POS Entry Mode. I already know that:
52 means ICC Card
80 in case of fallback
But what I want to know is difference between
22 (Magnetic Stripe)
and 90
Can anyone help me on this?
The length of Field 22 usually 3-digits (or 4-digits in case it is BCD packed into two Bytes) in protocols based on ISO 8583:1987 or 12-digits in case protocols based on ISO 8583:1993 version. Customized protocols could use different sub-fields content and values meaning behind.
While you use short values in the requested question, I guess, your Field 22 based on ISO 8583:1987 version and you lost the leading and/or ending zero. So, your sample values becomes 3 digits length - 052, 800, 022, and 090 or 900.
Usually the 3-digits Field 22 splited into two sub-fields:
Position 1 and 2 - Personal Account Number (PAN) Entry (or capability);
Position 3 - Personal Identification Number (PIN) Entry (or capability);
Here are the possible interpretations:
02 - PAN auto-entry via magnetic stripe, track data is not required, 2 - no PIN.
05 - PAN auto-entry via chip, 2 - no PIN.
09 - E-Commerce, 0 - unknown PIN capability.
80 - Fallback to magnetic stripe, 0 - unknown PIN capability.
90 - PAN auto-entry via magnetic stripe, track data should be transmitted within the authorization request, 0 - unknown PIN capability.
etc.
90 used in case track data present in the ISO 8583 request message, 02 - if, for same reason, acquirer or terminal device not qualified to transfer track data in the request messages.
Depending of protocol requirements could be exceptions with Field 22 values. It is usually checked during the terminal device and communication interface certifications.
I will elaborate few things here. From above comments I can see that 09 is for E commerce transactions,but as per my knowledge for E commerce transactions we should use PAN Entry mode as 01(manual entry). Because for card not present transactions entry mode has always in manually.
POS Entry mode says whether the particular transaction is E commerce or POS. The possible values are :
01 Manual entry
02 Magnetic Stripe,track 2 data will ignore
05 Smart card,track 2 data required
90 Magnetic stripe no track 2 data
91 contactless card
95 Smart card , track2 data not required
Thanks share your ideas on this