Applying for a DUNS Number is required to set up an Apple developer account. I was applying for it and need help with two questions in the DUNS application form:
Apple Tracking Number
Purpose - "Please mention your Purpose"
What should I enter for these fields?
Instead of getting a DUNS number through the dnb.co.in website, you can get Apple to make this request for you. Simply submit the form to "look up" your DUNS number on Look up your D-U-N-S Number even if you don't have it. If the website is unable to find it, it will allow you to submit the form to acquire it.
A few days after submitting this form, I got an email from dnb.com, which warned me that I don't have a company, and therefore can't get a DUNS number:
Case # 2489474 has been resolved.
Tracking Id: REDACTED
Case Number: REDACTED
Resolution Date/Time: December 20, 2021, 05:55 PM (UTC)
Business name: ORGANISATION NAME
Duns:
Location: London Greater London GB
Requester's Own Request Key: REDACTED
Concern category: Add business - Mini Inquiry - Identity Data Only
Resolution: D-U-N-S Number already exists
Sub-Resolution: Verified through national registry
Resolution comment: Please note a search of our database revealed
no listing for ORGANISATION NAME at the address provided. Attempts
to contact the business was unsuccessful to verify the business.
Please note based on the request returning the best partial name
match. Delivered DUNS for ORGANISATION NAME is REDACTED.
Updated Information:
Resolution Duns: REDACTED
Business Name: ORGANISATION NAME
Address
REDACTED, BUT INCORRECT ADDRESS
Your milleage may vary, as I did this in the UK.
Unfortunately, this email from dnb confirmed that I need to be a registered company to get a DUNS number and create an Organization account.
Related
I am successfully using Paypal's Adaptive Accounts API's GetVerifiedStatus endpoint to verify our users' Paypal accounts by first name, last name, and email address. However, a significant fraction of them use Paypal business accounts which don't have a first and last name associated (or else they did provide one and have forgotten it.)
Is there a special way to e.g. enter business name in the "first name" field? Or do all accounts have a first/last name associated and our users need to look that up? Thanks!
Update to clarify: I'm aware that setting matchCriteria to NONE in the request theoretically allows one to perform an email-only search. However, Paypal enables this on a case by case basis, and we haven't been granted NONE status, thus must use NAME which per the docs requires first and last.
I've been playing around with this and found a way to make the call without having to set the option to matchCriteria=NONE. If you make the call by placing the business name twice, both in the first name and last name field, you should be able to get a successful reply from the API.
Looking at the API and playing around with the API explorer, you've got two options.
Set matchCriteria to NONE
In this case sending the first name and last name to the API is optional and the validation will only use the email address.
Set matchCriteria to NAME
In this case sending the first name and last name to the API are required and the validation will use the email address, the first name and last name fields.
You can verify the setting by using the playground, e.g. using test#example.com and any random names.
In your case I would provide the email address, first name and last name as input fields and set matchCriteria to NONE and send the request to the API.
For Every PaypPal interaction we Do:
1.SetExpressCheckoutReq
2.GetExpressCheckoutDetailsReq
3.DoExpressCheckOutPaymentReq
I do create a billing agreement first and only on scheduled/subsequent orders we use this billing agreement for reference transaction.
Our Issue is:
With a new PayPal account (testpaypal#abc.com) DoExpressCheckoutPaymentReq failed for CITY = SuttonsBay, with the address validation error “10736” (Shipping Address Invalid City State Postal Code) for a user (USER A). And this was corrected in the subsequent request as Suttons bay.
But the same PayPal account(testpaypal#abc.com ) used for the second time with a different user (USER B) on the site, DoExpressCheckoutPaymentReq call succeeds for the wrong CITY = SuttonsBay and allows us to complete the order.
It is to be noted that on all scheduled order of the user, we use the DoReferenceTransactionReq, which has strict validation and this fails every time, esp. for the second scenario described above.
I would like to know why there are inconsistencies in Shipping address validation for DoExpressCheckoutPayment. It is because of this difference that our scheduled orders fails (as described in scenario 2 that allows incorrect address)
Do we any way to have strict Validation in DoExpressChecOutPayment - which solves our purpose?
I have a system where users are represented primarily with an integer ID. I have a resource; let's call it X. X is associated with 2 users: one created X and the other will approve X when the creator is done. X's approver is selected by the creator when it is submitted via POST (or can be edited in later), and the request identifies the approver by user ID. There's one additional restriction: approvers and creators are paired together. Approvers can only approve X if the creator is assigned to them.
So I have a few possible failure cases regarding the approver's user ID in the request:
Malformed ID (non-integer)
Approver ID is an integer, but no user with that ID exists.
Approver ID is an existing user, but that user doesn't have the approver role.
Approver ID is an existing approver, but the approver is not assigned to the creator.
400 is obviously the correct status code for case 1, but it doesn't seem like the right status code for 2-4. 400 designates a malformed request, but 2-4 are problems specifically with existing data, not with parsing the request. I considered 409, but that seems to be a problem with the resource itself. This is a problem with additional resources that are related to resource X. I also thought about 406, but that seems to be geared toward providing content in an unknown format (like XML when only JSON is accepted).
So what status code is appropriate to indicate that the client provided well formed but bad data?
Note that for clarity to clients you will always include an explanation of the error, so a slightly inexact code with an appropriate message will most certainly be helpful.
That being said, I would use 404 (Not Found) for 1 and 2. Integer or not, a resource with that ID does not exist.
Both 3 and 4 seem localized to our application, so I would use 400. 403 could be used for 3, but that might imply authentication problems.
I agree with #Will for 1 & 2 - 404.
For 3 & 4, I would go with 409. Since in the general case (you said that the approver can be changed later) there's no real distinction (that I can see) between:
Approver ID is an existing user, but that user doesn't have the approver role.
and
Approver ID is an existing user, and 5 seconds ago they were the approver, but that is no longer the case
So it feels the same as an edit conflict.
I am testing MIGS Virtual Payment Client on a test account. When I select payment, I am directed to the Payment Server page where I can choose between Visa and MasterCard. I have been given the following test data in the MIGS manual:
I use 123 as CSC value. However, the transaction always fail with
vpc_VerStatus=E
vpc_TxnResponseCode=2
vpc_Message=Declined //for Visa
vpc_Message=The+card+holder+was+not+authorised.+This+is+used+in+3-D+Secure+Authentication. //for MasterCard
By the way, if I select MasterCard, I am prompted "Please enter your OSID or the last 5 digits of your NAB ID" and a Credit Limit. I use OSID with value 123456 and Credit Limit 10000 respectively. (These are values I entered by myself as I was not given information what to input there).
I had a look at this Commonwealth bank and MIGS Virtual Payment Client error code but it does not solve my problem.
Any help why the transaction is being declined?
Okay, there's a handful of things here you need to understand/check out.
1. Ensure the transaction value ends in $xyz.00 or it will always decline
MIGS behaves differently in TEST and PROD. In TEST, MIGS uses the "cents" portion of your test transactions to determine what response code to return, NOT whether you have correctly provided the necessary data for the transaction. These cents values are as follows:
$ XXX.00 returns "0 Transaction approved"
$ XXX.10 returns "1 Transaction could not be processed"
$ XXX.05 returns "2 Transaction declined - contact issuing bank"
$ XXX.68 returns "3 No reply from Processing Host"
$ XXX.33 returns "4 Card has expired"
$ XXX.51 returns "5 Insufficient credit"
2. Disable 3-D Secure
It looks like you're also getting caught by 3DSECURE, also known as "Verified by Visa" and "Mastercard SecureCode". Call your acquirer/bank and ask them to disable this in TEST and Prod. Why? Invariably when this goes live, your customers will see a screen they are not expecting that asks for more information and then either pick up the phone and ask you to "fix it" or (even worse) leave your store thinking it's fraud.
Because 3-D secure has such low takeup, even most bank support staff don't know about it. Just today I had one of my clients call me about this "issue". One of their customers had called their card issuer to enquire as to what this "Verified by Visa" screen was. The bank (a major Australian bank) helpfully told them it was probably fraud and to not buy anything from that site.
3-D secure has such low penetration in Australia I'd suggest the only outcome of having it enabled is to reduce sales. Don't use it.
When designing an internation registration form how should I be asking for a user's information. Should name be [First, Last] or [Common, Surname] or simply [Name]. Does first and last name make sense for all names?
When asking for state and zipcode what would alternative terminology be, should I even be collecting this information for some countries?
We're recently getting into international users and methods and I'm hoping someone with experience can weigh in on the proper fields and labels that would be present in a solid international registration form.
I would reccomend just a single input for name, not all names are logically separated into just two parts, some people have just one name (such as Teller, and if used for addresses, the name may be a company name). Labeling is complicated since first and last name is not the same as given and family name, if names in your language is normally in which field should the first/family name go and the last/given name go?
For an address input you need:
Name/Company: <text box; no validation or munging>
Address: <Multiline textbox; no validation or munging>
Country: <text box or select-box if you're paranoid>
Making it more detailed and you're creating problems for foreigners.
The only thing your local post service need for a foreign address is the name of the country. The rest is country specific and may include several fields or in some cases something like "behind the church in the woods" etc.
Do not include zip code or anything country specific like that unless the user has chosen a country you have extensive knowledge about. People tend to know how to type their address in a free form text area, but they may actually mess it up if they have to force their address into foreign fields.
The worst you can do is silently discarding invalid fields. That happened to me when registering my address (in Norway) for a magazine subscription from USA. The norwegian addres format is:
<Name or company>
<Street name> <house number>
<post code> <city or suburb>
NORWAY
But when trying to force these fields into the closest equivalent in a very US-centric form they ended up mailing it to:
<my name> Oslo/OSLO//<And a lot of garbage letters and symbols>
/NORWAY
It eventually arrived, but it was a month delayed. It probably helped that I have a unique name, and that we're only about 5 million people in Norway. I doubt it would have arrived if I my name was "John Smith" and lived in New York and some web form had munged it to John Smith NY/New York;/ USA///
Sorry for the long rant ;)
I would suggest just the name, so that user could enter whatever seems right.
As for State, I quite don't understand what you need this information for. But I am not U.S. citizen, so...
Two address lines (without implied format), zip code (terminology is OK, but do not try to validate) and country name should be sufficient. The problem with "States" is, some countries do not use such concepts (either at all, or use different regional split concepts, i.e. in Poland it is voivodship, in England it would be county, etc.). Again, I wouldn't use such details.
How you accept the user data is based on what you want to do with it. Having said that
Name: This is also country specific but based on the suggestions I've got "family name" and "given name" are generic/common across any country. Some names have multiple "family name"'s.
Address: Different countries have different address formats. You can get different format information here
As a non-US resident, who has a very non-standard address (live on a boat, which requires additional address information, and very often does not have a Royal Mail standarised address) I do find that US-centric registration forms are very irritating. As far as name goes, I have found first and last name appropriate. For addresses I would consider either leaving labels off for most lines or labelling them innocuously as "address line 1", etc. In addition make sure that there are a number of such lines; the dialog box is long enough to accept multiple fields; and the dialogs will accept address delimiters such as comma. The only ones I would leave as they often displayed are Town/City and Country. Zipcodes should not be referred to as such - the minimum courtesy I would expect from a registration form is a request for Zip/Post code.
Though not directly related to registration forms, I have previously provided a (very long) answer to a question on validation/normalisation of international data. It is not a simple topic.