I am reading card data for contact or contactless mode perfectly, but my query is how I can identify that is the card chip data is read using contactless mode or contact. It would be great If someone guide me about specific emv tag or other way to identify this difference for MPOS solution.
If you are looking as a terminal you know from the processing that the card is processed on a contact or a contactless interface. If you are looking as an acquirer or payment scheme or as a card issuer, De22( pos entry code ) will tell you the mode, the transaction was acquired.
There are no specific tags for MPOS transactions, it is just like any other POS transaction. As an acquirer you will have details of the terminals and so you can identify whether the terminal is an MPOS or not.
When you send the transaction to MasterCard you set Data Element 60 Sub Element 10 to 9 to indicate that the transaction was acquired on an MPOS, on a Visa you would send DE 60 SE 1 to 9. For each payment scheme this may differ. Refer the specific interface manuals.
Related
In an EMV chip card with two AIDs, it is correct to use different IMK-AC keys for each AID or the same IMK-AC key for both AIDs?
I'm asking this question because we are having problems validating the ARQC for an EMV chip card. The ARQC validation is success only when the card is using one AID, and the ARQC validation is failing when the card is using the other AID. We have tested this several times and have the same result. My theory is the IMK-AC used to issue the AIDs are different, but I don't know if that makes sense?
Is there any way to know the IMK-AC KCV in an AID EMV chip card?
Also, In the TVR (terminal verification result) for the transactions are:
ARQC Success: 8000048000 (Online PIN entered ON)
ARQC Failing: 8000008000 (Online PIN entered OFF)
I don't know if the TVR could affect in any way the ARQC validation?
I'll appreciate any help on this issue.
Thanks!
Two different applications and hence two different card numbers, correct ?
While you personalize, IMK AC will not be sent to card, it is a key derived from the IMK-AC, diversified with pan and card sequence number, called Unique derivation key sent to the card, and hence both cards will have two UDKs even though the IMK-AC is same.
Since AID is different, ensure the ARPC verification is appropriate for the Cryptogram Verification Number. You can get this from 9F10(Issuer Application Data).
The value in TVR do not matter for ARQC validation, but what received from the terminal should be used for verification since it was used for generation by the chip.
You can add some logs from terminal, host and HSM here ( after masking sensitive data if performed using a live card ).
We are saving client cards on file to charge them at a later date.
We are getting a lot of declines and would like to know which banks are declining our payments.
Is there anyway to easily see this info?
All the data about the issuing institution is encoded in the credit card number itself.
https://www.creditcardinsider.com/learn/anatomy-of-a-credit-card/
https://chargebacks911.com/bank-identification-numbers/
Basically, the first six digits encode the type of card, and the issuing institution. This should give you enough to get on with.
I'm currently evaluating using Plaid or Yodlee for transaction aggregation (I'm using the Dev environments for both right now). I really prefer almost everything about Plaid, but I'm having trouble with transaction name/description. Yodlee has a data field called the "simple description":
From their docs: "The transaction description that appears at the FI site may not be self-explanatory, i.e., the source, purpose of the transaction may not be evident. Yodlee attempts to simplify and make the transaction meaningful to the consumer, and this simplified transaction description is provided in the simple description field."
I'm displaying the transaction name to my end-users and I'm looking for something more user friendly than the transaction name field which often returns strings like "Withdrawal Check Card MOE'S BROADWAY BAGE BOULDER CO Date 01/06/19 0 9006020339 0 5812 Card [XXXX]".
I'm sure I'm not the first plaid customer to have this need. How do Plaid reliant apps solve this problem?
Plaid doesn't offer a simple description field as far as I know, but they do clean up transaction names.
I've found that when a new pending transaction comes in, the name is messy like you mention (e.g. UBER *TRIP 5VVB2). But once the transaction is confirmed, Plaid normalizes it for common merchants (e.g. Uber). I don't know why Plaid doesn't offer this normalization for pending transactions, but I have brought it up with them before. Perhaps this is something that could change in the future?
A solution, albeit complicated, is to build a custom model that normalizes transaction names. That's what we are doing at Pluto Money to supplement Plaid's transaction data.
I received a direct response by email from Plaid Support:
Thanks for reaching out to us here on Plaid Support, I'm sorry about
our delay.
Our name field for each transaction represents our best effort to
balance detailed transaction information while providing a clean and
consistent API response. This behavior does vary across banks, both
due to bank behavior and our own integration quality. Generally at
larger banks our integrations do a better job at returning clean
transaction names with appropriate transaction detail but for some of
our smaller banks transaction names may be more "raw".
If you never want additional detail beyond the merchant/transaction
name in your app I would encourage you to implement some filtering on
Plaid's name field to make sure that no date- or account number-like
character strings pass through into your user facing stream.
Is it possible to anonymously programmatically verify that a transaction has reached n number of validations without running a full node? If so, what is the best means to do this?
Basically I want it to build a payment system where after the transfer is initially detected, the customer sees a message thanking them and telling them that their purchase will be processed within 24 hrs and that they'll receive an email once confirmation is complete. Then throughout the day maybe run a cron job that checks that each transaction reaches the desired number of validations and if so divide the money between two wallets and mark the product to be sent. I also don't want it to be with a service like Coinbase or Bitpay where they have control of your coins.
So far I've been experimenting with Blocktrail and mycelium gear. Both have some elements I like but still not everything that I need. With mycelium you can set the number of verifications but for instance if I want to set it for 6 verifications the customer would have to sit there possibly an hour before they see the next screen. Blocktrail allows me to query that a transaction is validated but it only has the ability to check that 1 validation was completed as far as I can tell. Can anyone suggest an API or widget that can accomplish these things? Preferably PHP or if not JQuery.
Blockchain.info has a simple Query API for querying how much bitcoin an address has received. You can add a confirmations=n parameter that will only include bitcoin that has been confirmed 'n' times. It returns a simple value in satoshis.
For example to check how much bitcoin was received with at least 2 confirmations at a specific address you could have your code query the API like this:
https://blockchain.info/q/getreceivedbyaddress/1PFtyX9nQvjP8U2N3iUk2oNorzPfpjX9sK?confirmations=2
During testing of tokenization when we supply a postal code with a card we get
attribute postal_code_check passed
The documentation states "Supplying a postal_code during tokenization initiates the AVS check."
So in our live marketplace, can we verify AVS as part of the tokenization process or does the testing environment nor match the live one?
To give an example; when I tokenize a card and then check the card object I can read
postal_code_check: passed
security_code_check: passed
I know the security_code_check should not be getting done until an "authenticated operation" is performed so it should not be happening here, worrying. Where as postal_code_check may be "initiated" during tokenization.
In a test environment, Balanced does not call out to the credit card networks at all. Therefore, it cannot verify postal codes or CVV. Please look at https://docs.balancedpayments.com/1.1/overview/resources/#test-credit-card-numbers, which provides test credit cards numbers for simulating different scenarios.