What is the best way to collect a phone number? I struggled with this a few months ago, so maybe some things have been updated since then. I ended up creating a collect phone number action that would convert 10 concepts (one for each phone digit) to a string and then send that in an api call. I did not see a library capsule that took care of this but whether library capsule or not, is there a better way to collect a phone number? hopefully this question saves a lot of people the trouble of defining 10 concepts!
You would not need a separate concept per digit; a text primitive concept that holds a full number is all you would need.
Additionally, using an input-view to show the user a form requesting their phone number would be the best method of implementing your use case.
This input-view form can be additionally modified with a mask attribute to ensure that invalid entries are checked as the user enters them. You can learn more about how to further customize your mask attribute here in our documentation.
For example, the following code snippet would only allow a phone number with the pattern (100) 000-0000.
text-input {
id (pnumber)
type (PhoneNumber)
label (Phone Number)
pattern {
mask ("(100) 000-0000")
}
value ("#{raw(this.phoneNumber)}")
}
In the chat application i am developing with dialog flow has scenario like this. Users can ask details about loans that they can get. that is a one intent. once user says the loan type they want i need to save it and use it every where when they ask question. for one example i have a another intent called loan payments.
In that intent they can ask questions like
I am interested in getting a personal loan for a duration of 5 years
and the loan amount would be 5 million rupees. Can you let me know the
monthly repayment amount?
to calculate that, loan type is a must (personal loan in this case). so if any user has specified the loan type before i need to use it here other wise i need to ask users to provide it again. but if i am using context i cant add add required. how to achieve this. also since i have already set the parameters i cant change the value of them. this is how my parameters look like
This is where your business logic comes in picture. Chat application can be built in two ways, directional & open-ended. In first one, you can explicitly go on asking few questions with set options/buttons for the services that you're offering & user has to select any one of them or in the second one, you keep it open for people to type-in anything & then you extract values & respond them based on their inputs.
Now that you're of second type, even if you use contexts, dialogflow offers you a favor to extract parameter values of first intent in the second one. You just have to use, #context_name.parameter_name. But now, if you're saying that if user has already defined loan type in earlier intent then you don't want to ask him again it in next intent, then this is purely a business logic that you will have to code in your webhook. Dialogflow won't do it for you.
I hope, this answers your question & if you don't want to do it that way, go for directional flow.
I was wondering if it is possible to create a address book or contacts app, like Apple's, that uses Core Data and an SQLite storage file.
The part I am not sure if it is possible, or how to do it is having multiple properties for phones. So a user could input five different phone numbers for the same contact.
The only way I could think of doing it is say... have one entity for the person... then another entity for phones with them having a relationship. So one person could have multiple phones but one phone could only have one person. But that didn't seem to like it would be a good way to do it... anyone have a suggestion?
I don't see how you came to the conclusion that several entities are not a good way to do something like this. That's the only way to do it if you want flexibility. Adding three phone number attributes to your entity is definitely the wrong way.
I would use a simple data model like this:
Each record has a type (e.g. email, phone, fax, IM contact) a key (e.g. office, home, mobile, twitter, jabber) and a value (e.g. 55512345, foo#bar.com, #foobar).
Such a model offers the most flexibility and it's not very complicated to implement.
Though you need a couple of predicates to get phone numbers, emails etc.
I am writing an application that run only that user's phone. If the phone is stolen, application will never work anytime. For this scenario, I must used IMEI and SIM number but I develop application on SDK 60 2nd edition. So getting these numbers is not easy.
I used Bluetooth ID instead of IMEI, but I could not found any specific ID instead of SIM number. If any suggestion have been, I' d be glad. Thanks...
There are some examples on how to accomplish this with the IMEI in different phone manufacturers:
http://mobilepit.com/10/how-to-get-imei-number-in-j2me-javame.html
Seems like there's no "universal" method for any of those. In S60 (I guess this is what you mean by 'SDK 60') the appropiate code is:
System.getProperty("phone.imei");
For IMSI I think you have to get the operators signing, but you could use:
System.getProperty("com.nokia.mid.imsi");
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.