การชำระเงินมาตรฐานของ Google:

FOP ที่ใช้เทคโนโลยีโทเค็น

ภาพรวม

FOP ที่แปลงข้อมูลเป็นโทเค็น (รูปแบบการชำระเงิน) คือการผสานรวมการชำระเงินรูปแบบหนึ่งกับแพลตฟอร์มการชำระเงิน สำหรับผู้ใช้ในการชำระเงินด้วยรูปแบบการชำระเงินนี้ Google และผู้รวมระบบการชำระเงินต้องทำการแลกเปลี่ยนข้อมูลเข้าสู่ระบบเฉพาะของบัญชีแบบครั้งเดียว ซึ่งจะเข้าสู่ขั้นตอนการสร้างโทเค็น ซึ่งจะแสดงรูปแบบการชำระเงินนั้นสำหรับผู้ใช้นั้นๆ และสามารถใช้โทเค็นนี้ในการชำระเงินซ้ำได้ ปัจจุบันมี API เหล่านี้ 2 เวอร์ชัน เวอร์ชัน 2 รองรับผู้ให้บริการเครือข่ายมือถือและผู้ให้บริการหมายเลขอ้างอิง ผู้ให้บริการ FOP ที่แปลงเป็นโทเค็นรายอื่นๆ ทั้งหมดควรใช้เวอร์ชัน 1 ส่วนที่เหลือของเอกสารนี้เน้นที่เวอร์ชัน 1

Google ใช้ 2 ขั้นตอนในการสร้างข้อมูลประจำตัวและสร้างโทเค็นนี้

1. ขั้นตอนการตรวจสอบสิทธิ์: ระบุและยืนยัน (ตรวจสอบสิทธิ์) ผู้ใช้
2. กระบวนการเชื่อมโยง: สร้างโทเค็นสำหรับผู้ใช้ (ขั้นตอนการเชื่อมโยงใหม่หรือที่ระบุและตรวจสอบสิทธิ์แล้วก่อนหน้านี้) โทเค็นนี้แสดงถึงรูปแบบการชำระเงินหนึ่งๆ โดยผู้ใช้รายหนึ่งๆ ทำให้สามารถใช้โทเค็นนี้ในการซื้อในอนาคต

เมื่อสร้างโทเค็นแล้ว Google จะใช้โทเค็นดังกล่าวในระหว่างขั้นตอนการซื้อเพื่อประสบการณ์การชำระเงินที่รวดเร็วและราบรื่นสำหรับผู้ใช้ Google จะใช้โทเค็นนี้เพื่อแสดงอินสแตนซ์ของวิธีการชำระเงินที่ลูกค้าใช้ หรือที่เรียกว่าเครื่องดนตรี ลูกค้า Google อาจมีเครื่องมือมากกว่า 1 อย่างในการชำระเงินค่าสินค้าและบริการ

ในขั้นสุดท้าย การส่งเงินทั้งหมดระหว่างธนาคารของผู้รวมบริการและธนาคารของ Google จะดำเนินการในขั้นตอนการส่งเงิน

1) ผู้ใช้เลือกผลิตภัณฑ์ที่จะซื้อ

2) ถัดไป ผู้ใช้เลือกวิธีการชำระเงิน

3) ตอนนี้ลูกค้าเพิ่มวิธีการชำระเงินใหม่

4) ระบบเปลี่ยนเส้นทางผู้ใช้เพื่อตรวจสอบสิทธิ์

5) สุดท้ายคือการตรวจสอบสิทธิ์และซื้อได้

แผนภาพนี้แสดงภาพรวมอย่างกว้างๆ ของโฟลว์

ภาพรวมรูปแบบ FOP ที่ใช้เทคโนโลยีโทเค็น

ในระดับสูง การเพิ่มบริการเป็นรูปแบบการชำระเงินให้กับผลิตภัณฑ์ของ Google จะมีขั้นตอนดังต่อไปนี้

1. ขั้นตอนการตรวจสอบสิทธิ์
2. โฟลว์การเชื่อมโยง
3. ขั้นตอนการซื้อ
4. ขั้นตอนการคืนเงิน
5. ขั้นตอนการส่งเงิน

ขั้นตอนเหล่านี้มีคำอธิบายโดยละเอียดในส่วนด้านล่างและในส่วนคู่มือ

แนวคิดและคำศัพท์

สัญลักษณ์และการประชุม

คำสำคัญ เช่น "ต้อง" "ต้องไม่" "จำเป็น" "จะ" "ไม่" "ควร" "ไม่ควร" "แนะนำ" "อาจ" และ "ไม่บังคับ" ในเอกสารเหล่านี้จะมีการตีความตามที่อธิบายไว้ใน RFC 2119

การประทับเวลา

การประทับเวลาทั้งหมดจะแสดงเป็นมิลลิวินาทีนับตั้งแต่ Unix Epoch (1 ม.ค. 1970) ใน UTC

เช่น

• 23 เมษายน 2019 เวลา 20:23:25 น. GMT = 1556051005000 มิลลิวินาที
• 16 สิงหาคม 2018 เวลา 12.28.35 น. GMT = 1534422515000 มิลลิวินาที

จำนวนเงิน

มูลค่าทางการเงินใน API นี้อยู่ในรูปแบบที่เรียกว่า "ไมโคร" ซึ่งเป็นมาตรฐานที่ Google ไมโครคือรูปแบบความแม่นยำคงที่ที่เป็นจำนวนเต็ม หากต้องการแสดงมูลค่าเงินในหน่วยไมโคร ให้คูณค่าสกุลเงินมาตรฐานด้วย 1,000,000

เช่น

• USD$1.23 = 1230000 ไมโคร USD
• USD$0.01 = 10,000 ไมโคร USD

การแสดงถึงตัวตน

การเรียกเมธอดทั้งหมดภายใน API นี้ต้องมีลักษณะการทำงานแบบเป็นนิรันดร์ Google จะส่งคำขออีกครั้งเป็นระยะๆ เพื่อตรวจสอบว่าธุรกรรมของทั้ง 2 ฝั่งมีสถานะเดียวกัน ผู้รวมบริการไม่ควรพยายามดำเนินการกับคำขอที่ประมวลผลเสร็จสมบูรณ์แล้วอีกครั้ง ควรรายงานการตอบกลับสำหรับการประมวลผลที่สำเร็จแทน วิธีการทั้งหมดมี RequestHeader ทั่วไปซึ่งมี requestId requestId นี้เป็นคีย์ประจำตัวสำหรับการเรียกทั้งหมด

การตอบกลับที่ไม่ใช่เทอร์มินัล (ไม่ใช่ HTTP 200 ที่สำเร็จ) จะต้องประมวลผลไม่สำเร็จ ดังนั้น คำขอที่ก่อนหน้านี้ได้รับ 400 (คำขอที่ไม่ถูกต้อง/เงื่อนไขเบื้องต้นที่ล้มเหลว) เมื่อเรียกใช้เป็นครั้งที่ 2 จะต้องไม่แสดงผล 400 โดยไม่ได้ตั้งใจ คำขอต้องได้รับการประเมินอีกครั้ง ขณะประเมินอีกครั้ง ระบบอาจแสดงผลคะแนน 400 หรือได้รับการประมวลผลสำเร็จ

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการมีตัวตน โปรดดูคำแนะนำโดยละเอียดนี้

ผู้รวมบริการ

บริษัทที่ใช้แพลตฟอร์มการชำระเงินของ Google สำหรับธุรกิจ ซึ่งอาจเป็นธุรกิจภายใน (บุคคลที่หนึ่ง) เช่น YouTube หรือ AdWords หรืออาจเป็นธุรกิจภายนอก (3P) ที่ต้องการผสานรวมบริการของตนเพื่อให้ทำงานร่วมกับระบบนิเวศของ Google ได้เช่นกัน

รูปแบบการชำระเงิน

รูปแบบการชำระเงิน วิธีนี้เป็นแบบทั่วไปมากกว่าเครื่องดนตรี Visa, MasterCard และ PayPal ทั้งหมดเป็น FOP

เครื่องมือ

อินสแตนซ์ของรูปแบบการชำระเงินโดยลูกค้าที่เฉพาะเจาะจง เช่น บัตรเครดิตหรือบัญชี PayPal ของผู้ใช้ รูปแบบการชำระเงินที่แปลงสกุลเงินเป็นโทเค็นสำหรับลูกค้ารายหนึ่งๆ ก็เป็นเครื่องมือเช่นกัน เนื่องจากเป็นรูปแบบการชำระเงินสำหรับลูกค้ารายนั้นๆ โดยจัดเก็บไว้อย่างปลอดภัยในระบบของเรา

โทเค็น

การนําเสนอวิธีการชำระเงินของผู้ใช้ในระบบของ Google เนื่องจากโทเค็นดังกล่าวมีข้อมูลทั้งหมดที่จำเป็นในการซื้อ โทเค็นยังเป็นเครื่องมืออีกด้วย ซึ่งอาจรวมถึงข้อมูลอย่างเช่นหมายเลขบัญชีที่ผู้ใช้มีกับผู้ผสานการทำงานของตน

ขั้นตอนของคีย์

ขั้นตอนการตรวจสอบสิทธิ์

การตรวจสอบสิทธิ์เป็นขั้นตอนที่ต้องทำเป็นอันดับแรก วัตถุประสงค์ของขั้นตอนการตรวจสอบสิทธิ์คือการระบุและตรวจสอบสิทธิ์ผู้ใช้กับผู้ผสานรวม การตรวจสอบสิทธิ์เกิดขึ้นได้หลายวิธี FOP ที่ใช้เทคโนโลยีโทเค็นรองรับ 2 วิธีในการระบุและตรวจสอบสิทธิ์ผู้ใช้ ดังนี้

1. การตรวจสอบสิทธิ์ OTP ผ่าน SMS-MT (ยกเลิก SMS บนอุปกรณ์เคลื่อนที่ รหัสผ่านที่สามารถใช้งานได้เพียงครั้งเดียว)
2. การตรวจสอบสิทธิ์การเปลี่ยนเส้นทาง

เมื่อเริ่มต้นใช้งาน ผู้ผสานการทำงานจะทำงานร่วมกับ Google เพื่อเลือกกลไกการตรวจสอบสิทธิ์ที่เหมาะกับผลิตภัณฑ์ของตนมากที่สุด

ขั้นตอนการตรวจสอบสิทธิ์สามารถใช้ได้ 2 บริบท แบบแรกใช้ระบุลูกค้าใหม่เพื่อทำการเชื่อมโยง และขั้นที่ 2 ขอสอบถามข้อมูลเข้าสู่ระบบของเครื่องมือที่มีอยู่จากผู้ใช้ ผลลัพธ์ของขั้นตอนการตรวจสอบสิทธิ์สามารถใช้เป็นอินพุตในหลายๆ ขั้นตอน เช่น ขั้นตอนการเชื่อมโยง ขั้นตอนการรีเฟรช ขั้นตอนการซื้อที่ท้าทาย และอื่นๆ นอกจากนี้ ขั้นตอนการตรวจสอบสิทธิ์ยังใช้ในโหมดเดี่ยวๆ ได้ด้วย ไม่ใช่กับขั้นตอนที่ตามมาใดๆ

การตรวจสอบสิทธิ์ OTP ผ่าน SMS-MT

ในกลไกการตรวจสอบสิทธิ์นี้ ผู้ใช้จะป้อนหมายเลขโทรศัพท์ใน Google UI Google จะส่งหมายเลขโทรศัพท์นี้ไปยังผู้ผสานการทำงานระบบ (ผ่านเมธอด sendOtp) ผู้รวมจะส่งรหัสผ่านที่สามารถใช้งานได้เพียงครั้งเดียวให้กับผู้ใช้ ผู้ใช้ป้อนรหัสผ่านใน UI ของ Google ซึ่งจะส่งรหัสผ่านไปยังผู้ผสานรวม ซึ่งจะทำให้ผู้รวมการชำระเงินตอบสนองสำเร็จ

เมื่อใช้การตรวจสอบสิทธิ์ OTP ของ SMS-MT ในโหมดสแตนด์อโลน ระบบจะส่งค่าของ OTP ไปยังผู้ผสานการทำงานโดยใช้เมธอด verifyOtp วิธีนี้จะช่วยยืนยันว่า OTP ที่ระบุไว้เป็นหมายเลขที่ส่ง

การตรวจสอบสิทธิ์การเปลี่ยนเส้นทาง

การตรวจสอบสิทธิ์การเปลี่ยนเส้นทางจะเกิดขึ้นโดย Google จะเปลี่ยนเส้นทางผู้ใช้ไปยังแอปพลิเคชันของผู้ผสานการทำงานเอง แอปพลิเคชันนี้อาจเป็นเว็บหรือแอปพลิเคชัน Android ก็ได้

การเปลี่ยนเส้นทางของ Android และเว็บมีลักษณะการทำงานที่คล้ายกัน Google จะเปลี่ยนเส้นทางผู้ใช้ไปยังแอปของผู้ผสานการทำงาน ผู้ผสานการทำงานจะระบุและตรวจสอบสิทธิ์ผู้ใช้ในรูปแบบใดก็ตามที่เป็นธรรมชาติมากที่สุดสำหรับผู้รวมระบบดังกล่าว เมื่อตรวจสอบสิทธิ์แล้ว ผู้ผสานรวมจะเปลี่ยนเส้นทางผู้ใช้กลับไปยัง UI ของ Google เพื่อเชื่อมโยงให้เสร็จสิ้น เมื่อเปลี่ยนเส้นทางแล้ว Google จะให้ requestId เพื่อระบุเซสชันการตรวจสอบสิทธิ์นี้ จากนั้นตัวระบุดังกล่าวจะใช้เป็นหลักฐานการตรวจสอบสิทธิ์ในระหว่างการเชื่อมโยง

ตัวรวมที่เลือกขั้นตอนนี้ต้องระบุ URL การตรวจสอบสิทธิ์เว็บเนื่องจากเป็นตัวหารที่ใช้กันมากที่สุดในทุกแพลตฟอร์ม (เดสก์ท็อปหรืออุปกรณ์เคลื่อนที่) อย่างไรก็ตาม เราขอแนะนำอย่างยิ่งให้ใช้การตรวจสอบสิทธิ์ของ Android ซึ่งจะมอบประสบการณ์ที่ดีที่สุดแก่ผู้ใช้ในอุปกรณ์เคลื่อนที่

UI ของ Google จะเลือกเว็บหรือการเปลี่ยนเส้นทางแอป Android โดยขึ้นอยู่กับบริบทของอุปกรณ์และแอปที่ติดตั้ง

กลไกการตรวจสอบสิทธิ์นี้ทำให้ผู้ผสานรวมมีอิสระมากที่สุด การตรวจสอบสิทธิ์และระบุผู้ใช้ทำได้หลายวิธี ชื่อผู้ใช้ + รหัสผ่าน หรือข้อมูลไบโอเมตริกและคำถามเพื่อความปลอดภัย เป็นวิธีแก้ปัญหาที่ใช้ได้ทั้งคู่ Google ไม่ได้มุ่งหมายวิธีที่ผู้ผสานการทำงานยืนยันผู้ใช้ ผู้ผสานการทำงานจะดูแลการตรวจสอบสิทธิ์ผู้ใช้ ด้วยวิธีนี้ Google จะใช้อินเทอร์เฟซผู้ใช้ที่หลากหลายของผู้ผสานการทำงานเพื่อตรวจสอบสิทธิ์ผู้ใช้และเพียงแสดงหลักฐานการตรวจสอบสิทธิ์ให้กับ Google

หมายเหตุ: หากผู้ผสานรวมจะใช้ SMS-MT OTP ระหว่างการเปลี่ยนเส้นทาง Google ขอแนะนำให้ใช้ประโยชน์จากการตรวจสอบสิทธิ์ SMS- MT OTP ข้างต้น ซึ่งช่วยให้ผู้ใช้ได้รับประสบการณ์การใช้งานที่ราบรื่นยิ่งขึ้นในผลิตภัณฑ์และบริการของ Google

ดูข้อมูลเพิ่มเติมเกี่ยวกับการตรวจสอบสิทธิ์ได้ในคำแนะนำโดยละเอียดนี้

โฟลว์การเชื่อมโยง

หลังจากขั้นตอนการตรวจสอบสิทธิ์ผ่านหนึ่งในกลไกที่กล่าวถึงข้างต้น ผู้ใช้จะผ่านขั้นตอนการเชื่อมโยง วัตถุประสงค์ของกระบวนการเชื่อมโยงคือการสร้าง Google Payment Token (GPT) เพื่อสร้างเครื่องมือ ขั้นตอนนี้มีขั้นตอนการทำงานดังนี้

1. เจรจาข้อมูลประจำตัวที่เรียกว่าโทเค็นเพื่อแสดงถึงผู้ใช้รายนี้
2. ให้ข้อมูลบัญชีเพื่อแจ้งเครื่องมือความเสี่ยงของ Google
3. รวบรวมข้อมูลที่จำเป็นในการตั้งค่าครั้งแรกเพื่อสร้างและสร้าง GPT

ผลลัพธ์ที่ได้คือ GPT ที่สร้างขึ้นเป็นการเห็นพ้องต้องกันทั้ง Google และผู้รวมบริการ

ผู้ใช้ Google 2 รายจะใช้บัญชีผู้ใช้เดียวกันกับผู้ผสานรวมได้ ในกรณีนี้ ผู้ใช้แต่ละคนจะมีเครื่องมือที่แตกต่างกัน สำหรับแต่ละเครื่องมือจะมีขั้นตอนการเชื่อมโยงเป็นอิสระ ดังนั้นจึงมี GPT ที่ไม่ซ้ำกัน

ภาพนี้จะอธิบาย FOP ที่แปลงข้อมูลเป็นโทเค็นซึ่งมีชื่อว่า InvisiCash ปลอม ซึ่งจะแสดงขั้นตอนที่ผู้ใช้ต้องทำสำหรับขั้นตอนการตรวจสอบสิทธิ์และขั้นตอนการเชื่อมโยง

ภาพรวมโฟลว์การเชื่อมโยง

1. ผู้ใช้ Google ที่มีอีเมล [e-mail] ต้องการเพิ่มบัญชี InvisiCash ไปยัง Google Play Store เพื่อใช้ซื้อสินค้า
2. Google Play Store จะเปิดแอป InvisiCash เพื่อตรวจสอบสิทธิ์

3. ผู้ใช้เข้าสู่ระบบบัญชี InvisiCash ด้วยอีเมล [e-mail] โดยอาจมีการใช้อีเมลของ Gmail สำหรับทั้งสองบัญชีหากเป็นการเข้าสู่ระบบสำหรับบัญชี InvisiCash ของเธอ

   หมายเหตุ: มีการตรวจสอบสิทธิ์ด้วยวิธีอื่นๆ นี่เป็นเพียงตัวอย่างเดียวเท่านั้น หรืออาจดำเนินการผ่านเว็บแทนที่จะเป็นแอป

4. แอป InvisiCash จะส่งรหัสการตรวจสอบสิทธิ์กลับไปยัง Google Play Store

5. Google Play Store จะส่งรหัสการตรวจสอบสิทธิ์ไปยังเซิร์ฟเวอร์ Google

6. เซิร์ฟเวอร์ของ Google จะส่งข้อความไปยังเซิร์ฟเวอร์ InvisiCash เพื่อเชื่อมโยงบัญชี การเชื่อมโยงนี้ประกอบด้วยรหัสการตรวจสอบสิทธิ์ GPT (Google Payment Token) และรหัสการเชื่อมโยง

7. เซิร์ฟเวอร์ InvisiCash จะจัดเก็บ Google Payment Token (GPT) และรหัสการเชื่อมโยง ตอนนี้ทั้ง 2 รายการได้เชื่อมโยงกับบัญชี InvisiCash ของ Sally แล้ว

8. InvisiCash อนุมัติการเชื่อมโยงนี้ จากนั้นเซิร์ฟเวอร์ของ Google จะสร้างเครื่องมือที่สามารถใช้สำหรับการซื้อในอนาคต