Is there any way to understand if the card(emv or magnetic) is used first time at ATM or POS?
For EMV card ATC is reliable?
The "first time" could be different.
You can ask for ATC after selection ( command 80CA9F5200 ) and if it equals 0000, Get Processing Options wasn't performed, what means there wasn't any transaction.
Bit if if > 0000, it does not mean what "full" transaction was on card. ATC shows number of launch command Get Processing Options.
For Visa card you can find specific bit in CVR ( CVR3, BIT5 ) "New card". He shows if successful online transaction was performed with card.
You can trust ATC for EMV transaction but there is no counter for magnetic transaction.
There is one bit( new card bit) that was set in first EMV transaction. If the Last Online ATC Register is 0 then “New card” bit in the TVR will be set to 1. You could check that bit to see if this transaction is first for this card.
I found ATC is incremented just after GPO is performed. It is possible that transaction falied just after GPO,
Next time when we fire GPO, we get the value > 0 ( ATC already incremented) here we can't say that card is not new because yet to processed first transaction successfully.
so I think ATC value is not a parameter to find out whether card is new or already used. [Sometime as per setting we need to check the card is new or not to perform certain activity]
There are two ATC-related values could be read using GET_DATA: the current ATC and Last Online ATC. For a new card that never went online the Last Online ATC would be zero. This should be true for a 'classical' scheme of the EMV technology employment by a traditional payment system.
Hope this helps
Related
I'd like to verify programmatically that a transaction was successful - that is the Etherum network itself recognizes that for a given transaction hash, it was valid.
Using web3.eth.sendSignedTransaction returned a promise, there's two events - one 'confirmation', the other 'receipt'.
Can I rely on the 'receipt' callback to ascertain that a transaction truly occurred? Or do I have to rely on the 'confirmation' call back as well? If so - how?
Similarly, reading getTransactionReceipt it mentions that -
The receipt is not available for pending transactions and returns null.
So, if I do get a receipt then - it means the transaction is no longer 'pending' ? That is, was successful?
_So, if I do get a receipt then - it means the transaction is no longer 'pending' ? That is, was successful?
When the receipt becomes available (or the event is handled in your case), it means that the transaction was mined into a block.
But the tx could have been reverted (if it was a tx to a smart contract that reverted it for some reason). Check the receipt field status
true means that the transaction was successful
false means it was reverted
Mind that the status is not included in pre-Byznatium (October 2017) transactions and can also be missing in some future transaction types. See more about the transaction types in this answer.
What would be the best way to determine the issuer of a contactless EMV card. I am trying to determine if a card was issued by Amex, Visa or Mastercard. Is that information available via a USB EMV reader? I don't need to pull any other information from the card..
I'm assuming that it could be done by some python, or C++ code interacting with the card. I'm looking for a good jumping off point.
You should be able to get this info from the successful response of SELECT. Store the list of RIDs ( AID = RID + PIX ), and do SELECT one by one. On success, it will return status bytes 90 00, otherwise 6A 82( file not found ).
The easiest option would be through SELECT command as mentioned
before. The list of AID:
https://www.eftlab.com/knowledge-base/211-emv-aid-rid-pix/
The other option would be getting it from the PAN. You can define issuer
based on first 6 digits or 8 digits of the PAN, which represents Issuer
Identification Number (IIN)/Bank Identification Number(BIN).
34, 37 - American Express
4 - Visa
51-55, 2221-2720 - MasterCard
https://en.wikipedia.org/wiki/Payment_card_number#Issuer_identification_number_(IIN)
You would have to send commands:
SELECT
GET PROCESSING OPTIONS
READ RECORD
You would look for 5A - PAN and extract first digits.
Good tool that you can just use to read data from contactless EMV card is:
https://www.javacardos.com/tools/pyresman
You can create your own scripts or just proceed with some basic commands like a SELECT command.
I see such code segment in proposer_task(xcom_base.c)
if(threephase || ep->p->force_delivery){
push_msg_3p(ep->site, ep->p, ep->prepare_msg, ep->msgno, normal);
}else{
push_msg_2p(ep->site, ep->p);
}
the threepahse is int const threephase = 0 and force_delivery == 0 here
push_msg_eq is normal paxos include prepare, accept and learn phase
but push_msg_2p will skip prepare phase and directly send accept request
I want to know why, Thanks a lot.
If you look at the paper Paxos Made Simple page 10 paragraph 3 says:
A newly chosen leader executes phase 1 for infinitely many instances
of the consensus algorithm [...]
Then paragraph 4:
Since failure of the leader and election of a new one should be rare
events, the effective cost of executing a state machine command—that
is, of achieving consensus on the command/value—is the cost of
executing only phase 2 of the consensus algorithm. It can be shown
that phase 2 of the Paxos consensus algorithm has the minimum possible
cost of any algorithm for reaching agreement in the presence of faults.
Hence, the Paxos algorithm is essentially optimal.
This is saying that a leader only issues a prepare during a leader failover. After that it streams accept messages. It then has "optimal messaging" in that the leader only needs one round trip to know a value is chosen (the accept message and its acknowledgment).
In a three node cluster, a leader self-accepts instantaneously, then only needs one accept acknowledgment from a second node to have a majority. It then knows the value is chosen without having to await the response from the 3rd node (which could be down). That is as efficient as you can get. The value is known to be accepted at a second node with strong consistency.
Given that is how paxos works to get maximum efficiency we should expect that mysql xcom has a mode that skips the prepare message phase in steady state.
You can read more about the Paxos Made Simple techniques on my blog here.
You might be interested to know about the latest developments of Paxos where you don't need a majority response for accept messages in the cluster using FPaxos and tricks like the even nodes optimization.
I've got this kind of problem with Proton CEP: i currently have a "Sequence" EPA; its input are 2 events. But these events have different granularity: let's say i have A and B events; i receive N "A" events, and M "B" events, where M << N.
So i'd like to have a rule like "if event of type A is not consumed within X seconds, remove it", otherwise i've got a long A events queue; i only need the rule to be evaluated for closest (temporally) events.
Practically, i've got a fake room temperature sensor that sends its temperature updates every 5seconds, and i've got another program that checks external weather and sends it every minute.
Any idea how to solve this situation?
Thank you very much!
I guess that in "consume" you mean arrival, so do you want to evaluate the time the A event took to get to the proton pcoressor? or the time between A events? Do you want to ensure that the A events are indeed continuous in a fix rate? "Removing" an event means to ignore it, since events are not kept anywhere, just processed. At the end, what is that you want to detect here? Like, what is the trend of room temperature compared to the outside temperature? then, emit output events accordingly?
Thanks.
all the relevant event instances are kept within the local state of a corresponding EPA.
For each EPA operand you have policies which dictates how the state is gathered and how the matching set for event derivation is built.
For example, instance selection policy which is defined per operand, and has the values of "Each", "First" and "Last" will tell you if all A instances are examined for match with B instance, or the first (in the order of arrival), or the last.
The consumption policy says what to do with the operand state once a seqence is detected - should the instances of say A which participated in sequence be removed from EPA's state ("consume" value of the policy) or should they remain.
Playing with combination of those policies should give you the behaviour you require
With Zaqar, imagine you have a message M in a queue Queue.
Let Queue.claim_timeout == Queue.message_ttl (please ignore the misuse of the terminology, but also feel free to correct).
Imagine I do a claim(M) and I do no delete!
What happens when the claim_timeout will be reached?
M is still available
that means the message_ttl was "suspended" while the message was claimed
M is autodeleted
because of the message_ttl which will also be reached
Something else.
Any explanation or comment will be of huge help.
Thanks,
Costin
It seams that the answer is 1:
M is still available
; that means the message_ttl was "suspended" while the message was claimed
I base my statement on the Zaqar docs: https://wiki.openstack.org/wiki/Zaqar/specs/api/v1#Claims
The server will extend the lifetime of claimed messages to be at least as long as the lifetime of the claim itself, plus a specified grace period to deal with crashed workers (up to 1209600 or 14 days including claim lifetime). If a claimed message would normally live longer than the grace period, it's expiration will not be adjusted.