0

scenario: a customer shops and creates an e-commerce order. there is a customer db table, and a shipping table. a customer can have more then shipping address. if the customer logs in to do another order, the shipping address(es) are pulled from the shipping table based on customer id.

the shipment is boxed, the store admin orders a shipping label and the address is sent to be "verified". when the shipping address is Verified, a new version of the shipping address is returned. There are 4 possibilities here:

1) there is no change at all to the Verified address except the letters might have been changed to upper case.

2) there is some slight change to the Verified address that doesn't affect the original version. maybe Ave was added to a street name field or a 5 digit zip code is updated to the 9 digit version.

3) the original submitted shipping address had a minor error - but the Verification was able to correct it. for example the zip code had a wrong digit.

4) the original submitted address has a major error that cannot be resolved by the Verification. either it can be figured out by the admin and resubmitted or the customer must be contacted.

so the questions are:

A) do we always update shipping tables with the (new) Verified address?

B) or do we do some kind of check and compare the original and verified to see if there is a change and then only update if the address has been changed?

C) or should we update the address AND keep a backup copy of the original address?

choice A seems like the simplest but am curious how people are dealing with this. note that this is probably most relevant for shipping with USPS postal in terms of the rigor of their verification.

====== edit

validating the shipping to address when the customer enters it in is obviously the most optimal but e-commerce merchants can get orders from different "channels" that the merchant has no control over. so validation at the time of creating the shipping label is still required.

Marc Sances
  • 2,402
  • 1
  • 19
  • 34
cartalot
  • 3,147
  • 1
  • 16
  • 14

3 Answers3

0

D) Interaction with the customer at point of entry.

At that point of creating an eCommerce order - is that where they enter the address? That is the point that you should be validating the details. That is the point that you can ask for more information and clarity.

For example, if you validate afterwards then simple corrections (or changes over time) can be applied, but if there are major changes or the customer did not enter their apartment information there is no way to guess that afterwards and it can be a costly and time consuming task to create (call the customer back etc).

There are a few ways you can do this, I'm not sure what you use at the moment. If you are using third party solutions (such as my company's offering: https://www.edq.com/address-verification) they probably have services you can use which provide the interaction and prompts required. A solution such as this has the advantage that it can speed the capture of an address and ease the check out process but also makes sure that the addresses are validated and corrected at the point of capture.

If you do the above, then you only need to store the one, correct, customer accepted address. If they enter it correctly first time then it goes straight through with a lovely user experience, if there are problems then minor ones are fixed with extra interaction (appending Zip +4 perhaps) or they are prompted and guided to correct their address.

Al Mills
  • 1,072
  • 6
  • 22
  • Hi -- i appreciate your answer, and i'm amending the question somewhat to take into account sales through other "channels" that the retailer has no control over. – cartalot Mar 04 '15 at 19:40
0

The USPS address validation only corrects addresses if they're positive that it does not actually change the intended address. Whenever the address validation is ambiguous, the address validation service returns the original address (or an error) and usually includes a message such as "ZIP and city are a match, but street address is invalid".

Thus you should be able to go with options A or B. That being said, most carrier APIs (including address validation) are unfortunately not 100% reliable, thus it might be reasonable to go with option C to have a backup.

If you need access to an easy-to-use address validation interface, my company Shippo offers an easy-to-use address validation REST API.

Simon Kreuz
  • 575
  • 3
  • 8
0

You can try Pitney Bowes “IdentifyAddress” Api available at - https://identify.pitneybowes.com/

The service analyses and compares the input addresses against the known address databases around the world to output a standardized detail. It corrects addresses, adds missing postal information and formats it using the format preferred by the applicable postal authority. I also uses additional address databases so it can provide enhanced detail, including address quality, type of address, transliteration (such as from Chinese Kanji to Latin characters) and whether an address is validated to the premise/house number, street, or city level of reference information.

You will find a lot of samples and sdk available on the site and i found it extremely easy to integrate. Here is the small sample - JSON Request -

  {
  "options": {
    "OutputCasing": "M"

  },
  "Input": {
    "Row": [
      {
        "AddressLine1": "13 milk st",
        "AddressLine2": "",
        "City": "boston",
        "Country": "us",
        "StateProvince": "ma",
        "PostalCode": "",
        "user_fields":[
          { 
                "name": "User1",
                "value": "Value1"
          }
          ] 
      }

    ]
  }
}
  }

JSON Response

 {"Output": [{
   "Status": "F",
   "Status.Code": "UnableToDPVConfirm",
   "Status.Description": "Address Not Deliverable",
   "AddressLine1": "13 Milk St",
   "City": "Boston",
   "StateProvince": "MA",
   "PostalCode": "02109-5402",
   "Country": "United States of America",
   "BlockAddress": "13 Milk St Boston MA  02109-5402 United States of America",
   "PostalCode.Base": "02109",
   "PostalCode.AddOn": "5402",
   "user_fields": [   {
      "name": "User1",
      "value": "Value1"
   }]
}]}