How does POS decide to generate a 100 message or a 200 message during a payment - payment

Based on what data does a POS terminal decide if it needs to generate a ISO 8583 100 (Authorization Request) message or a ISO 8583 200 (Acquirer Financial Request) message.
Also how does POS decide if it needs to prompt the user to enter his card PIN or not.
Any reference to documents on ISO 8583 message generation at the POS will be very useful.
Thanks

A 200 message is what ISO 8583 calls a Financial Message. It is used to transfer funds into or out of a cardholder's account.
A 100 message is what ISO 8583 calls an Authorization Message. It is used to check that the card holder's account has enough funds to cover the amount of the transaction and to reserve that amount (and sometimes a little more) for a certain period of time. It does not actually take any funds from the account. At a later time, a 200 (actually a 220) message can be sent to take the money from the account).
100 message are usually used in situations where the transaction amount is not known at the time or where the delivery of the good or service is not immediate.
So for example, when you check into a hotel, the hotel wants to know that your account has enough funds to cover your expected stay (and maybe a little extra in case you order room service or use some other service), so a 100 message might be sent when you check in, and then at checkout time, a 220 message is sent to actually transfer the funds from your account.
See the "Message Class", "Message Function" and the "Examples" sections of this Wikipedia entry on ISO 8583.
As far as, "how does the Point of Sale (POS) device decide if it needs to prompt the user to enter his card PIN or not", there is no one answer that works in all situations, for all merchants, and in all countries.
For example, in some cases, PIN entry is required for all debit cards but not allowed for any credit cards. In these cases, the POS device needs to know whether the card being used is a debit card or a credit card. It can either ask the operator or it can attempt to use the card number and/or mag stripe to determine this. A table of account numbers or Account BIN numbers (the first few digits or the account number) can be stored in the POS and used to identify the type of card (sometimes). see Bank Card Number).
Sometimes just knowing whether a card is credit or debit is not enough, there are cards that can be used as either, there are debit card that can used without a PIN, and there are credit cards that allow/require PIN entry.

Both credit card terminal and credit card have a list of preferred customer verification methods, the most common ones being 'signature', 'PIN', and 'identification'.
The terminal then takes the verification method that is ranked highest by the card and supported by the terminal.

Related

Is it possible to test card mask number if it's applepay/googlepay or not?

I have card numbers in format like 123456xxxxxx7890. How can i test if it's regular card or any other service like ApplePay/GooglePay/etc?
Just boolean answer yes/no is more than enough for my needs. Is there any logic? Or database?
I've tried to look up at binlist.net service but it doesn't detect it unfortunately (shows wrong banks for 10 card IINs that i have).
we will never know if the card is regular card or applepay /google pay card
applepay/gpay generates a unique card number for each original card and we cannot obtain the original card details from it

UML Exercise ATM Use-case diagram

I have an assignment in which the following conditions are set forth:
Brief Statement of Purpose:
An ATM is an electronic device designed for automated dispensing of money. A user can withdraw money quickly and easily after authorization. The user interacts with the system through a card reader and a numerical keypad. A small display screen allows messages and information to be displayed to the user. Bank members can access special functions such as ordering a statement
Brief Summary of Requirements: The ATM is required 1. To allow authorized card holders to make transactions
Card holders shall view and/or print account balances
Card holder shall make cash withdrawals
Card holder shall make cash or check deposits
Card holder shall quit session
To allow bank members to access additional, special services
A bank member shall be able to order a statement
A bank member shall be able to change security details (e.g. PIN number)
To allow access to authorized bank staff
Authorized staff can gain access to re-stock the machine
Authorized staff are able to carry out routine servicing and maintenance
To keep track of how much money it contains and alert bank staff when stocks are getting low
Additional Notes:
Users shall be able to access the ATM by punching in their account number and PIN. Once the system has verified that the account is active and the PIN matches with the account number, the system offers the users four choices. Users can withdraw money, deposit money, check balance or quit the session.
The user must have a minimum of $100 in his / her account. At the end of any transaction a printed copy of the transaction is provided to the user. A transaction could be - withdraw money, deposit money or check balance. Once the user has completed a transaction, the system offers the user the same four choices, until the user decides to quit.
The system shall interface with the device to dispense cash, the device to accept cash or check and the printer. Since we have not studied databases in this course, the system will keep all the information in two RandomAccess files. One file will hold the passwords and the other account balances.
I have built the following use-case diagram but am confused about how detailed it's supposed to be and what should be an extension/inclusion and what should just be a base case. Any feedback would be welcomed.
Should bank members and card holders be separate or together? Technically bank members can do more than a card holder like update security details or order statements, but aren't all bank members card holders?
Here is the other version I have, minus quit not being a use case, are there other factors that are incorrect?
Here are a couple of observations:
As commented, Quit is no use case as it does not add any value to the actor. Rather it looks like post-conditions for other use cases.
Generalizing use cases is a bad idea (although allowed per UML). A use case shows a single unique piece of added value for a actor using the system under consideration. In that context grouping serveral use cases under the hat of a "common" use case is not helpful. Rather connect the specializations directly with the actor and remove that Transaction.
Instead of duplicating the Bank Members's associations to Quit/Transaction you can draw a generalization to Auth Card Holders.
Better use the singular for an actor. It's a general role name and per se covers any amount of real persons/machines.
A part of the requirement/description are scenarios which go into use cases. It's common mistake to try to expose these in functional decomposition in use cases.
Your attempt is not bad. But creating use cases from requirements is not easy and needs a lot of experience. So (like always) I recommend to read Bittner/Spence about use cases. (Do not read the UML specs to get an idea of UC synthesis. They are at best able to give the syntax how to use bubbles and stick men.)
As commented by www.admiraalit.nl there "might be" applications for generalizing use cases and you can discuss that controversially. It's my own preference to not use them since using it wrongly is more easy than using it right. The same goes for export/import. Avoid it as long as you don't know exactly what it's good for. You tend to starting functional decomposition which is not what UCs are good for.

Stripe Widget converts balance to thousands on declined card

We have integrated the Stripe widget into our checkout, works great! UNTIL a customers card is declined then the total for some reason converts into thousands
E.g if a customers is paying for goods worth £520 and the card is declined the balance is converted to £52,000.
Stripe's amount parameters are in pence for British Pounds, and cents for US Dollars. You're likely doing some conversions wrong on your own end.
Also, you have provided 0 code, so this question kinda violates the SO rules. You should add more information and code snippets of what you've already tried or this question may be at risk of being closed.

Struggling in drawing State machine diagram

Hey there I'm trying to draw state machine diagram for this scenario but It's missing lots of information. If someone here could help out with it.
The Scenario
Tourists will start the journey by selecting the trip using the
Automated Ticketing system (ATS).
The Automated Ticketing System (ATS) will display the trip details.
This Trip details will include the seat-number and destination.
Based on provided trip details, the ATS will compute payment.
The tourist has the option to pay the payment by cash or credit
card.
If the tourist will insert a wrong amount of cash, the ATS will
display "Insert More Cash" message on the screen until the correct
amount will be inserted.
If payment by card was selected by the tourist, the ATS will perform
two parallel tasks. It will validate the expiration date of the card
and check the credit balance. If card is accepted, the bank will
authorize the payment and will update the account of the tourist.
However, if card is not accepted or invalid, the ATS will again ask
for payment option (back to step 5) from the tourist.
After payment is complete, the ticket and receipt are printed by the
ATS.
Cash payment might result in some change, so the change is also
dispensed by the ATS. The tourist will then get the ticket and the
change.
ATS will display the message "Transaction Complete" at the end of
the transaction.
My Drawing:
Ok, so I try to give you some hints. A state machine is always created for a single class, not the overall system under consideration. So let's assume the ATS is a single class (in reality it will probably be more a component consisting of several classes). Now this ATS will in the beginning be idle. It is triggered somehow when a trip is selected. It then has to complete the journey details. It waits for payment and finally it will spit out a ticket. Now (basically!) the state machine looks like this:
This is a scaffold and it was done without reading the details above. Note that instead of the cancel transitions you could use a general exception from an interruptible region which eventually clears payments. In practice you would likely do that since a cancellation should (from a user perspective) be possible at any point. A time out of course would also be possible (what if already some cash had been paid?).
Also I did not include the do/entry/exit actions. For the cash this would be something like add new cash sum so we know when enough money has been paid.

Storing partial credit card numbers

Possible Duplicates:
Best practices for taking and storing credit card information with PHP
Storing credit card details
Storing Credit Card Information
I need to store credit card numbers within an e-commerce site. I don't intend on storing the whole credit card number, as this would be highly risky. I would like to store at least the first five digits so I can later identify the financial institution that issued the card. Ideally, I would like to store as much of the credit number as I safely can, to aid any future cross-referencing etc.
How many digits, and which particular digits, can I safely store?
For example, I imagine this would not be safe enough:
5555 5555 555* 4444
Because you could calculate the missing digit.
Similarly, this would be safe, but not be as useful:
5555 5*** **** ****
Is there a well accepted pattern for storing partial credit numbers?
The Payment Card Data Security Standard states that if you are handling cardholder data, then you are subject to the constraints of the PCI DSS (which is very comprehensive and a challenge to comply with). If you want to store part of a card number, and don't want to have to deal with the Standard, then you need to make sure that a) you store NO MORE THAN the first 6 and last 4 digits; b) you don't ever store, process or transmit more than this. That means that the truncation has to be carried out before the data enters your control.
Given that you are talking about an ecommerce site, I think you'll have to deal with the PCI DSS sooner or later (since if you're not taking full PANs, you can't process transactions). Realistically, then, you should avoid storing more than the first 6 and last 4 digits of a PAN; the Standard then does not 'care' about this data, and you can store it in whatever form you see fit. If you store, say, the first 7 digits, then Requirement 3 of the Standard kicks in (and you start having to really understand key management in encryption).
I hope that this is of use.
March 2013 Edit:
A very pertinent resource is the PCI Security Standards Council, an organisation founded in 2006 by five of the biggest global Credit Card brands (AmEx, Visa, MasterCard, JCB International and Discovery) and which is the de facto authority on Security matters for the Payment Card Industry (PCI).
This organization publishes in particular the PCI Data Security Standard, currently in its version 2.0 edition which covers issues such as the management of complete or partial credit card numbers. This document if freely available but requires a simple registration and acknowledgment of license terms.
The following is the original, c. 2009 answer, mostly correct but apocryphal.
A common practice (whether legal or not I do not know) is to store the last 4 digits, as this may be used to help the customer confirm which of his/her credit cards were used for a particular transaction.
Without significantly improving the odds of a malicious person guessing the complete number, one can store the first 4 digits which are representative of the financial institution which issued the card, as mentioned in the question.
Do NOT, save many more digits than these 8 digits because otherwise, given the LUHN-10 checksum, you may provide enough info to make guessing the complete number more plausible (if still relatively hard, even with insight from the series used by a given issuer, in a given time period, but one should be careful...)
To make this whole thing safer, technically and legally, you may consider only storing such info if the customer explicitly allows it. You should also consider masking this info with a simple hash for storing in the database.
Also, what you can / should store following a particular transaction, is the transaction ID supplied by the Credit Card Processor, at the time the transacton is submitted. This ID is the key that allows locating most (all?) of the info you would even need, would there be any issue with a particular transaction. This type of info can typically be queried from a secure web site maintained by the Processing company, along with some aggregate reports which may include a grouping by card-type (Amex, Visa...) if that is why you are thinking of storing the first four.
If you don't need to store the whole credit card number, why do you need to store it at all? If you want to save the financial institution that issued the card, why don't you store the financial institution that issued the card?
Your specific question is answered in sec 3.3 of the PCI/DSS document.
First six and last four are max for display. Customer (paper?) receipts are more restrictive. Those with a legitimiate need to know can see full card data.
My recommendation is to contact your merchant provider and see what options are available to you. A number of the modern transaction gateways have "vault" features where sensitive information is stored at the provider and you simply reference customers by a token number when you want to bill them or check account information.
Along the same lines use of transaction specific tokens can be used to reference needed data stored on the providers system.
However I can't stress enough the importance of reading and understanding PCI DSS. Simply punting secure storage does not magically obsolve you from being subject to PCI compliance requirements!! This is only possible when your system never touches full card data.
The accepted pattern is don't store them at all.
In certain jurisdictions you may be breaking the law by storing them or any part of them.
You could instead, store a one-way (and therefore unrecoverable) hash of the credit card number.
The credit card companies have a standard for this. You'll probably find it buried somewhere in the terms of service of your payment processor that you will obey this standard. It answers you questions. You can find the standard here
Here in Canada, the usual way is to store the first 4 digit ( to identify the financial institution) and the 4 last digit to identify the credit card.
But be sure that you didn't break any laws.

Resources