UPS Address Validation API คืออะไร และทำงานอย่างไร?
UPS Address Validation API เป็นบริการสำหรับนักพัฒนาที่ตรวจสอบที่อยู่จัดส่งกับข้อมูลที่อยู่ของ UPS และส่งคืนข้อมูลที่ช่วยให้แอปพลิเคชันระบุ แก้ไข หรือเติมข้อมูลที่อยู่ให้สมบูรณ์ได้ก่อนสร้างการจัดส่ง บริการนี้ออกแบบมาสำหรับเวิร์กโฟลว์ซอฟต์แวร์ เช่น การชำระเงิน การจัดการคำสั่งซื้อ การสร้างฉลากจัดส่ง และเครื่องมือบริการลูกค้า ควรถือว่าบริการนี้เป็นบริการตรวจสอบคุณภาพที่อยู่ ไม่ใช่การรับประกันว่าพัสดุจะจัดส่งสำเร็จ
ในเวิร์กโฟลว์ทั่วไป ธุรกิจจะส่งช่องข้อมูลที่อยู่ไปยัง UPS API รับการตอบกลับที่มีผลการตรวจสอบและคำแนะนำที่อยู่ที่เป็นไปได้ จากนั้นจึงตัดสินใจว่าจะยอมรับที่อยู่เดิม ขอให้ลูกค้าเลือกการแก้ไข หรือหยุดคำสั่งซื้อไว้เพื่อตรวจสอบด้วยตนเอง ฟิลด์การตอบกลับและตัวเลือกที่รองรับที่แน่นอนควรตรวจสอบจากเอกสารสำหรับนักพัฒนาของ UPS ฉบับปัจจุบันก่อนการติดตั้งใช้งาน
UPS Address Validation API ทำอะไรได้บ้าง
การตรวจสอบที่อยู่จะเปรียบเทียบข้อมูลที่แอปพลิเคชันส่งมากับข้อมูลที่อยู่ที่ผู้ให้บริการขนส่งมีอยู่ ผลการตอบกลับอาจระบุได้ว่าระบบรู้จักที่อยู่นั้นหรือไม่ และอาจส่งคืนที่อยู่ในรูปแบบมาตรฐานหรือเวอร์ชันที่แก้ไขแล้ว ทั้งนี้ขึ้นอยู่กับคำขอและที่อยู่ บริการนี้ช่วยให้แอปพลิเคชันตรวจพบปัญหาที่พบบ่อยได้ เช่น:
- ไม่มีข้อมูลถนนหรือบรรทัดที่อยู่ไม่สมบูรณ์
- ค่าเมือง รัฐ จังหวัด หรือรหัสไปรษณีย์ไม่ถูกต้องหรือไม่สอดคล้องกัน
- ความแตกต่างด้านการสะกดและรูปแบบการเขียน
- มีรายการที่ตรงกันได้หลายรายการสำหรับที่อยู่เดียวกันที่ลูกค้าป้อน
- ที่อยู่ที่ไม่สามารถจับคู่กับข้อมูลของผู้ให้บริการขนส่งที่มีอยู่ได้อย่างมั่นใจ
เป้าหมายในทางปฏิบัติคือการปรับปรุงที่อยู่ก่อนการจัดการคำสั่งซื้อ ที่อยู่ที่สะอาดและถูกต้องมากขึ้นสามารถลดปัญหาการจัดส่งที่หลีกเลี่ยงได้ แต่การตรวจสอบไม่ได้ขจัดความเสี่ยงในการจัดส่งทั้งหมด ที่อยู่ที่จัดรูปแบบถูกต้องอาจยังเข้าถึงไม่ได้ ปิดทำการ มีผู้รับรายอื่นอยู่ หรือได้รับผลกระทบจากเงื่อนไขการจัดส่งในพื้นที่
API ทำงานอย่างไร
โดยปกติกระบวนการมีห้าขั้นตอน ชื่อ ฟิลด์ และโครงสร้างการตอบกลับอาจเปลี่ยนแปลงได้เมื่อ UPS อัปเดตแพลตฟอร์มสำหรับนักพัฒนา ดังนั้นนักพัฒนาควรใช้เอกสารอ้างอิง API ฉบับปัจจุบันแทนการอาศัยตัวอย่างโค้ดเก่า
1. แอปพลิเคชันขอสิทธิ์การใช้งาน
ขั้นแรก ธุรกิจจะสร้างหรือใช้แอปพลิเคชันสำหรับนักพัฒนาของ UPS และรับข้อมูลประจำตัวที่จำเป็นสำหรับการเข้าถึง API UPS API ใช้เวิร์กโฟลว์สำหรับนักพัฒนาที่ผ่านการยืนยันตัวตน และควรศึกษาเอกสาร UPS ฉบับปัจจุบันเกี่ยวกับข้อกำหนดเบื้องต้นของบัญชี การจัดการข้อมูลประจำตัว สภาพแวดล้อม และการจัดการโทเค็น ข้อมูลประจำตัวควรเก็บไว้บนเซิร์ฟเวอร์ที่ปลอดภัย และไม่ควรเปิดเผยในโค้ดเบราว์เซอร์หรือแพ็กเกจแอปมือถือ
2. แอปพลิเคชันรวบรวมช่องข้อมูลที่อยู่
ระบบชำระเงินหรือระบบคำสั่งซื้อจะรวบรวมที่อยู่ที่จะใช้ในการจัดส่ง ข้อมูลทั่วไปได้แก่ ชื่อผู้รับ ที่อยู่ถนน เมือง รัฐหรือจังหวัด รหัสไปรษณีย์ และประเทศหรือดินแดน ฟิลด์แต่ละรายการไม่ได้มีความสำคัญเท่ากันในทุกตลาด และโครงสร้างคำขอที่ต้องใช้จะขึ้นอยู่กับการทำงานของ UPS API ที่เลือกใช้
การจัดการข้อมูลนำเข้าที่ดีควรเริ่มก่อนเรียกใช้ API แบบฟอร์มควรแยกบรรทัดที่อยู่ออกจากเมืองและรหัสไปรษณีย์ เก็บข้อมูลห้อง ยูนิต หรืออพาร์ตเมนต์ไว้ และหลีกเลี่ยงการลบรายละเอียดที่ผู้ใช้ป้อนโดยไม่แจ้งให้ทราบ การปรับรูปแบบที่อยู่เพื่อแสดงผลแตกต่างจากการเปลี่ยนข้อมูลที่จะปรากฏบนฉลากจัดส่งในท้ายที่สุด
3. ระบบส่งคำขอตรวจสอบ
เซิร์ฟเวอร์จะส่งที่อยู่ไปยังปลายทางการตรวจสอบของ UPS โดยใช้เมธอด ส่วนหัว โทเค็นการอนุญาต และสคีมาคำขอที่ UPS ระบุ ควรส่งคำขอจากแบ็กเอนด์ ซึ่งสามารถจัดการข้อมูลประจำตัว การบันทึกข้อมูล การควบคุมอัตราการเรียกใช้ และการจัดการข้อผิดพลาดได้
การติดตั้งใช้งานจริงควรกำหนดด้วยว่าจะเกิดอะไรขึ้นเมื่อคำขอหมดเวลา ส่งคืนข้อผิดพลาดด้านการยืนยันตัวตน หรือถึงขีดจำกัดการใช้งาน การตรวจสอบที่อยู่ควรช่วยปรับปรุงกระบวนการชำระเงิน ไม่ใช่ทำให้ร้านค้าทั้งหมดใช้งานไม่ได้เมื่อบริการภายนอกไม่พร้อมใช้งานชั่วคราว
4. UPS ส่งคืนผลลัพธ์หรือคำแนะนำ
การตอบกลับอาจมีสถานะการตรวจสอบ ข้อมูลอธิบาย และรายการที่อยู่ที่เป็นไปได้หนึ่งรายการหรือมากกว่า รายการที่เป็นไปได้ไม่ได้หมายความว่าควรแทนที่ที่อยู่ของลูกค้าโดยอัตโนมัติ ตัวอย่างเช่น ที่อยู่ที่แนะนำอาจไม่มีหมายเลขห้องชุด หรืออาจเป็นที่อยู่ใกล้เคียง แอปพลิเคชันต้องแสดงผลอย่างชัดเจนและคงความสามารถของลูกค้าในการยืนยันที่อยู่สุดท้ายไว้
อินเทอร์เฟซที่มีประโยชน์ควรแยกผลลัพธ์ออกเป็นสามประเภท:
- ยอมรับ: ที่อยู่ดูเหมือนถูกต้องเพียงพอสำหรับเวิร์กโฟลว์ของธุรกิจ
- มีคำแนะนำให้แก้ไข: บริการส่งคืนการปรับปรุงที่เป็นไปได้ ซึ่งลูกค้าหรือผู้ปฏิบัติงานควรตรวจสอบ
- ไม่สามารถสรุปผลได้: ระบบไม่สามารถจับคู่ที่เชื่อถือได้ จึงต้องรับข้อมูลเพิ่มเติมหรือตรวจสอบด้วยตนเอง
ป้ายกำกับเหล่านี้เป็นตัวเลือกด้านการออกแบบแอปพลิเคชัน ไม่จำเป็นต้องเป็นถ้อยคำที่ UPS ใช้โดยตรง การติดตั้งใช้งานควรจับคู่รหัสการตอบกลับตามเอกสารอย่างรอบคอบ แทนที่จะถือว่าการตอบกลับที่ไม่ใช่ข้อผิดพลาดทุกรายการเป็นที่อยู่ที่ยืนยันแล้วว่าสามารถจัดส่งได้
5. ระบบคำสั่งซื้อตัดสินใจว่าจะดำเนินการอย่างไร
หลังจากได้รับการตอบกลับ ผู้ค้าสามารถอัปเดตแบบฟอร์มชำระเงิน ขอให้ลูกค้ายืนยันคำแนะนำ ส่งคำสั่งซื้อไปยังคิวปฏิบัติการ หรือดำเนินการจัดการคำสั่งซื้อต่อไป ผลการตรวจสอบยังสามารถจัดเก็บไว้กับคำสั่งซื้อได้ โดยต้องเป็นไปตามนโยบายด้านความเป็นส่วนตัว การเก็บรักษาข้อมูล และความปลอดภัยของบริษัท
ควรดำเนินการตรวจสอบในจุดที่เหมาะสมของเวิร์กโฟลว์ การเรียกใช้ระหว่างการชำระเงินสามารถป้องกันข้อผิดพลาดที่เห็นได้ชัดก่อนการชำระเงินหรือการจัดการคำสั่งซื้อ การเรียกใช้อีกครั้งก่อนสร้างฉลากสามารถตรวจพบที่อยู่ที่ป้อนผ่านมาร์เก็ตเพลส การนำเข้าข้อมูล การแก้ไขโดยฝ่ายบริการลูกค้า หรือคำสั่งซื้อเก่า ควรควบคุมการเรียกใช้ซ้ำเพื่อไม่ให้ระบบสร้างทราฟฟิกหรือความยุ่งยากที่ไม่จำเป็น
การตรวจสอบที่อยู่กับการยืนยันที่อยู่
คำสองคำนี้มักใช้แทนกัน แต่จริง ๆ แล้วแสดงถึงระดับความมั่นใจที่แตกต่างกัน โดยทั่วไปการตรวจสอบจะถามว่าที่อยู่ตรงกับข้อมูลที่อยู่ที่รู้จักหรือไม่ และสามารถทำให้เป็นรูปแบบมาตรฐานได้หรือไม่ ส่วนการยืนยันอาจสื่อถึงการตรวจสอบที่เข้มงวดกว่า เช่น การยืนยันว่าจัดส่งได้จริง หรือการยืนยันความสัมพันธ์ระหว่างที่อยู่กับผู้รับรายใดรายหนึ่ง ไม่ควรนำเสนอ UPS Address Validation API ว่าเป็นหลักฐานว่าบุคคลใดอาศัยอยู่ที่ที่อยู่นั้น หรือเป็นหลักฐานว่าการจัดส่งจะสำเร็จ
ความแตกต่างนี้มีความสำคัญต่อกฎทางธุรกิจ ผู้ค้าอาจยอมรับที่อยู่ที่ผ่านการตรวจสอบสำหรับคำสั่งซื้อความเสี่ยงต่ำ แต่กำหนดให้ตรวจสอบเพิ่มเติมสำหรับการจัดส่งสินค้ามูลค่าสูง คำสั่งซื้อที่มีขนาดผิดปกติ หรือปลายทางที่เคยมีปัญหาการจัดส่ง การตรวจสอบที่อยู่เป็นเพียงหนึ่งในมาตรการควบคุมกระบวนการตรวจสอบคุณภาพคำสั่งซื้อ ไม่ใช่สิ่งทดแทนการตรวจจับการฉ้อโกง การยืนยันจากลูกค้า หรือการตรวจสอบความสามารถในการให้บริการของผู้ให้บริการขนส่ง
สิ่งที่ API ไม่ได้รับประกัน
ควรตีความผลการตรวจสอบภายในขอบเขตที่ระบุไว้ในเอกสาร ผลการตรวจสอบไม่ได้ยืนยันสิ่งต่อไปนี้ทั้งหมดเสมอไป:
- ผู้รับที่ระบุชื่อมีความเกี่ยวข้องกับสถานที่นั้น
- ที่อยู่นั้นปลอดภัยหรือเข้าถึงได้สำหรับบริการทุกระดับ
- อพาร์ตเมนต์ ห้องชุด แผนกธุรกิจ หรือห้องรับจดหมายแห่งใดแห่งหนึ่งจะรับพัสดุ
- ที่อยู่นั้นมีสิทธิ์ใช้กับผลิตภัณฑ์ UPS ทุกประเภท การคิดค่าธรรมเนียมเพิ่มเติมทุกรูปแบบ หรือตัวเลือกการจัดส่งทุกแบบ
- สามารถสร้างฉลากได้โดยไม่ต้องตรวจสอบการจัดส่ง การเรียกเก็บเงิน หรือบริการแยกต่างหาก
ความครอบคลุมและพฤติกรรมของระบบอาจแตกต่างกันตามประเทศ ดินแดน ประเภทที่อยู่ และเวอร์ชัน API ก่อนสัญญากับลูกค้าว่าจะครอบคลุมในระดับใด ควรตรวจสอบเอกสาร UPS อย่างเป็นทางการสำหรับตลาดและการทำงานที่ธุรกิจของคุณตั้งใจจะใช้
การตัดสินใจด้านการติดตั้งใช้งานที่ส่งผลต่อผลลัพธ์
แยกค่าดั้งเดิมและค่าที่แก้ไขแล้วออกจากกัน
จัดเก็บข้อมูลเดิมที่ลูกค้าป้อนแยกจากคำแนะนำที่ผ่านการทำให้เป็นมาตรฐาน วิธีนี้ช่วยรองรับการตรวจสอบย้อนหลังและทำให้ตรวจสอบการจัดส่งที่ล้มเหลวได้ง่ายขึ้น นอกจากนี้ยังป้องกันไม่ให้อัลกอริทึมแก้ไขลบข้อมูลที่ผู้ให้บริการขนส่งในพื้นที่หรือผู้จัดการอาคารจำเป็นต้องใช้โดยไม่แจ้งให้ทราบ
จัดการรายละเอียดอพาร์ตเมนต์และยูนิตอย่างระมัดระวัง
ข้อมูลยูนิตอาจมีความสำคัญต่อการปฏิบัติงาน แม้ที่อยู่ในระดับถนนจะดูถูกต้องก็ตาม หาก API ส่งคืนรายการที่ไม่มีข้อมูลยูนิต อินเทอร์เฟซควรขอให้ลูกค้ายืนยัน แทนที่จะถือว่ารายการนั้นเป็นข้อมูลทดแทนที่สมบูรณ์
ออกแบบเพื่อรองรับความคลุมเครือ
เมื่อมีการส่งคืนรายการที่เป็นไปได้หลายรายการ ควรแสดงบริบทที่เพียงพอให้ผู้ใช้แยกแยะรายการเหล่านั้นได้ หลีกเลี่ยงการเลือกผลลัพธ์แรกโดยอัตโนมัติ เว้นแต่ธุรกิจจะทดสอบพฤติกรรมนั้นแล้วและยอมรับความเสี่ยงที่เกี่ยวข้องได้ สำหรับที่อยู่ธุรกิจ ตัวเลือกให้ตรวจสอบด้วยตนเองอาจเหมาะสมกว่าการแก้ไขโดยอัตโนมัติซ้ำ ๆ
ตรวจสอบเวิร์กโฟลว์ทั้งหมด
ติดตามข้อผิดพลาดจากการตรวจสอบ การแก้ไขโดยลูกค้า คำแนะนำที่ถูกปฏิเสธ ปัญหาการจัดส่งจากผู้ให้บริการขนส่งที่เกี่ยวข้องกับที่อยู่ และการจัดส่งที่สำเร็จ ตัวชี้วัดเหล่านี้ช่วยระบุว่าการติดตั้งใช้งานกำลังลดปัญหาด้านการปฏิบัติงานหรือไม่ อัตราการยอมรับที่สูงเพียงอย่างเดียวไม่ได้พิสูจน์ว่าบริการกำลังปรับปรุงผลลัพธ์การจัดส่ง
ธุรกิจควรใช้บริการนี้เมื่อใด
API มีประโยชน์มากที่สุดเมื่อคุณภาพที่อยู่ส่งผลต่อต้นทุนการจัดการคำสั่งซื้อหรือประสบการณ์ของลูกค้า กรณีการใช้งานทั่วไป ได้แก่ การชำระเงินในอีคอมเมิร์ซ การนำเข้าคำสั่งซื้อจากมาร์เก็ตเพลส การเรียกเก็บเงินแบบสมัครสมาชิกที่มีการจัดส่งจริง การปล่อยคำสั่งซื้อจากคลังสินค้า และเวิร์กโฟลว์การสร้างฉลาก บริการนี้มีประโยชน์เป็นพิเศษเมื่อธุรกิจได้รับที่อยู่จากช่องทางการขายหลายช่องทางและไม่สามารถพึ่งพาแบบฟอร์มมาตรฐานเพียงแบบเดียวได้
บริการนี้อาจไม่จำเป็นสำหรับรายการสถานที่ธุรกิจภายในจำนวนน้อยที่มีการควบคุมดูแล อาจไม่เพียงพอหากใช้เพียงอย่างเดียวสำหรับการจัดส่งที่อยู่ภายใต้ข้อกำกับ สินค้ามูลค่าสูง หรือการจัดส่งที่มีความเสี่ยงด้านการฉ้อโกง ในกรณีเหล่านั้น ควรใช้ร่วมกับการตรวจสอบโดยบุคคล และการควบคุมด้านความสามารถในการให้บริการ การจัดส่ง และความปลอดภัยที่ธุรกิจกำหนด
รายการตรวจสอบสำหรับการติดตั้งใช้งานจริง
- ยืนยันการทำงานของ UPS API ตลาด และประเภทที่อยู่ที่ต้องรองรับให้แน่นอน
- ทบทวนเอกสารปัจจุบันเกี่ยวกับการยืนยันตัวตน คำขอ การตอบกลับ ข้อผิดพลาด และการใช้งาน
- สร้างบริการแบ็กเอนด์แทนการเปิดเผยข้อมูลประจำตัวในโค้ดฝั่งไคลเอนต์
- เก็บข้อมูลอพาร์ตเมนต์ ห้องชุด อาคาร และคำแนะนำการจัดส่งไว้
- สร้างสถานะที่ชัดเจนสำหรับยอมรับ มีคำแนะนำ และไม่สามารถสรุปผลได้ในอินเทอร์เฟซผู้ใช้
- ทดสอบที่อยู่ระหว่างประเทศ ที่อยู่ชนบท ที่อยู่เชิงพาณิชย์ ที่อยู่หลายยูนิต และที่อยู่ไม่สมบูรณ์ที่เกี่ยวข้องกับธุรกิจ
- กำหนดเส้นทางสำรองสำหรับกรณีระบบขัดข้อง หมดเวลา และผลลัพธ์คลุมเครือ
- วัดผลลัพธ์การจัดส่งที่เกี่ยวข้องกับที่อยู่หลังเปิดใช้งาน
สรุป
UPS Address Validation API ทำงานโดยรับที่อยู่ เปรียบเทียบกับข้อมูลที่อยู่ของ UPS และส่งคืนผลลัพธ์หรือการแก้ไขที่เป็นไปได้ให้แอปพลิเคชันผู้เรียกประเมิน คุณค่าของบริการนี้มีมากที่สุดก่อนการจัดการคำสั่งซื้อ ซึ่งผู้ค้ายังสามารถขอข้อมูลที่ขาดหายหรือป้องกันข้อผิดพลาดในการจัดส่งที่หลีกเลี่ยงได้ การติดตั้งใช้งานที่ปลอดภัยที่สุดควรถือว่าผลการตอบกลับเป็นข้อมูลสนับสนุนการตัดสินใจ เก็บข้อมูลที่ลูกค้าป้อนไว้ ตรวจสอบคำแนะนำที่คลุมเครือ ยืนยันขอบเขตทางภูมิศาสตร์ปัจจุบัน และอย่าสับสนระหว่างการจับคู่ที่อยู่กับการรับประกันการจัดส่ง
คำถามที่พบบ่อย
UPS Address Validation API ยืนยันหรือไม่ว่าที่อยู่สามารถจัดส่งได้
ไม่จำเป็นเสมอไป บริการนี้ช่วยจับคู่และปรับปรุงข้อมูลที่อยู่ได้ แต่ผลการตรวจสอบไม่ใช่สิ่งเดียวกับหลักฐานว่าผู้รับ อาคาร ยูนิต หรือบริการจัดส่งพร้อมให้บริการ ควรตรวจสอบเอกสาร UPS ฉบับปัจจุบันและใช้การตรวจสอบความสามารถในการให้บริการและการปฏิบัติงานแยกต่างหากเมื่อจำเป็น
API สามารถแก้ไขที่อยู่ของลูกค้าโดยอัตโนมัติได้หรือไม่
แอปพลิเคชันอาจใช้คำแนะนำที่ส่งคืนมาเพื่อเสนอการแก้ไข แต่การแทนที่โดยอัตโนมัติเป็นการตัดสินใจทางธุรกิจ ลูกค้าควรสามารถตรวจสอบการเปลี่ยนแปลงได้ โดยเฉพาะเมื่อหมายเลขยูนิต ชื่อธุรกิจ หรือรายละเอียดการจัดส่งอื่น ๆ อาจสูญหาย
ควรเรียกใช้การตรวจสอบระหว่างการชำระเงินหรือก่อนจัดส่ง
ทั้งสองช่วงเวลาสามารถมีประโยชน์ การตรวจสอบระหว่างการชำระเงินช่วยตรวจพบปัญหาได้ตั้งแต่เนิ่น ๆ ขณะที่การตรวจสอบก่อนสร้างฉลากช่วยตรวจจับการแก้ไขและคำสั่งซื้อที่นำเข้า ธุรกิจจำนวนมากใช้ทั้งสองวิธีอย่างมีการควบคุม พร้อมการแคชและพฤติกรรมสำรองเพื่อหลีกเลี่ยงคำขอที่ไม่จำเป็น
การใช้ API ต้องมีข้อมูลประจำตัวนักพัฒนาหรือไม่
ต้องมี โดยทั่วไปธุรกิจจำเป็นต้องเข้าถึงแพลตฟอร์มสำหรับนักพัฒนาของ UPS และมีข้อมูลประจำตัวสำหรับการยืนยันตัวตนที่จำเป็นต่อ API ที่เลือกใช้ ควรยืนยันข้อกำหนดด้านบัญชี แอปพลิเคชัน สภาพแวดล้อม และการใช้งานโดยตรงกับ UPS
การตรวจสอบที่อยู่เหมือนกับการป้องกันการฉ้อโกงหรือไม่
ไม่เหมือนกัน การตรวจสอบที่อยู่เกี่ยวข้องกับคุณภาพและการจับคู่ที่อยู่ ไม่ได้ระบุว่าใครเป็นผู้สั่งซื้อ การชำระเงินได้รับอนุญาตหรือไม่ หรือปลายทางการจัดส่งเหมาะสมกับธุรกรรมนั้นหรือไม่
แหล่งข้อมูล
- UPS Developer Portal — จุดเริ่มต้นอย่างเป็นทางการสำหรับผลิตภัณฑ์ UPS API แอปพลิเคชัน การยืนยันตัวตน และแหล่งข้อมูลสำหรับนักพัฒนา
- เอกสารอ้างอิง UPS Address Validation API — เอกสารอ้างอิงอย่างเป็นทางการสำหรับการทำงานด้านการตรวจสอบที่อยู่ โครงสร้างคำขอ การตอบกลับ และรายละเอียดการติดตั้งใช้งาน
- UPS Application Programming Interfaces — ภาพรวมอย่างเป็นทางการของ UPS เกี่ยวกับการผสานรวมเทคโนโลยีผ่าน API
