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

รูปแบบการชำระเงินที่ใช้เทคโนโลยีโทเค็น

ภาพรวม

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

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

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

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

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

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

วันที่ 2) ต่อไป ลูกค้าเลือกวิธีการชำระเงิน

วันที่ 3) ตอนนี้บริษัทเพิ่มวิธีการชำระเงินใหม่

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

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

แผนภาพนี้แสดงภาพรวมของขั้นตอนต่างๆ

ภาพรวมรูปแบบการชำระเงินที่ใช้เทคโนโลยีโทเค็น

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

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

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

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

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

คีย์เวิร์ด "ต้อง" "ต้องไม่" "ต้องระบุ" "จะ" "จะไม่" "ควร" "ไม่ควร" "แนะนำ" "พฤษภาคม" และ "ไม่บังคับ" ในเอกสารเหล่านี้ ให้ตีความไว้ตามที่อธิบายไว้ใน RFC 2119

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

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

เช่น

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

จำนวนเงิน

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

เช่น

• USD$1.23 = 1230,000 Micro 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 เนื่องจากมีข้อมูลทั้งหมดที่จำเป็นในการซื้อ โทเค็นจึงเป็นเครื่องมือหนึ่งด้วย ซึ่งอาจรวมถึงข้อมูล เช่น หมายเลขบัญชีที่ผู้ใช้มีกับผู้ผสานรวมระบบ

โฟลว์คีย์

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

หลังจากขั้นตอนการตรวจสอบสิทธิ์ผ่านกลไกอย่างใดอย่างหนึ่งที่กล่าวข้างต้น ผู้ใช้จะดำเนินการตามขั้นตอนการเชื่อมโยง วัตถุประสงค์ของขั้นตอนการเชื่อมโยงคือการสร้างโทเค็นของ Google Payments (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) และรหัสการเชื่อมโยง

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

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