ในโลกของการชำระเงินมาตรฐานของ Google การเรียกเก็บเงินผ่านผู้ให้บริการมือถือถือเป็นรูปแบบการชำระเงิน (FOP) ที่แปลงข้อมูลเป็นโทเค็น ซึ่งหมายความว่า Google และผู้รวมการชำระเงินจะแลกเปลี่ยนข้อมูลเข้าสู่ระบบข้อมูลประจำตัวของบัญชีแบบครั้งเดียวเพื่อสร้างโทเค็น ภายหลัง ระบบจะแสดงโทเค็นนี้ต่อผู้รวมการชำระเงินเพื่อระบุบัญชีที่จะเรียกเก็บเงินจาก
รูปแบบการชำระเงินแบบอื่นๆ ก็ใช้การแปลงข้อมูลเป็นโทเค็นเช่นกัน เราจึงมีภาพรวมทั่วไปของ FOP ที่ใช้เทคโนโลยีโทเค็น ซึ่งส่วนใหญ่แล้วจะเกี่ยวข้องกับการเรียกเก็บเงินผ่านผู้ให้บริการเครือข่ายมือถือเป็นส่วนใหญ่ ขั้นตอนการตรวจสอบสิทธิ์ การเชื่อมโยง การซื้อ และการส่งเงินมีรายละเอียดเพิ่มเติมในภาพรวม หน้านี้จะให้รายละเอียดเพิ่มเติมในบริบทของ การเรียกเก็บเงินผ่านผู้ให้บริการมือถือโดยเฉพาะ
ผู้ให้บริการเริ่มต้นใช้งาน Google Standard Payments ด้วยการใช้ API ที่ประกอบด้วยขั้นตอนต่อไปนี้
| น้ำไหล | คำอธิบาย | เทียบเท่ากับข้อกำหนด DCB3 |
|---|---|---|
| การตรวจสอบสิทธิ์ | ระบุและตรวจสอบสิทธิ์บัญชีของผู้ใช้ในระบบของผู้รวมการชำระเงินที่จะใช้ในการชำระเงิน DCB | SMS-MO กับ GoogleUserToken |
| การเชื่อมโยง | แลกเปลี่ยนโทเค็นที่ใช้ได้นานซึ่ง Google และผู้รวมการชำระเงินตกลงกันไว้ สามารถใช้ในการชำระเงินได้โดยใช้บัญชีผู้รวมการชำระเงิน | อนุมัติการเรียกกลับของผู้ใช้ ด้วย OperatorUserToken และ GetProvisioning() |
| FundsTransfer | ย้ายเงินออกจากบัญชีผู้รวมการชำระเงินของผู้ใช้แบบพร้อมกัน โอนความรับผิด ไปยังผู้รวมการชำระเงิน | บรรทัด Auth() และ CHARGE ในไฟล์คำขอแบบกลุ่ม |
| การคืนเงิน | จะส่งคืนเงินทุนบางส่วนหรือทั้งหมดที่เชื่อมโยงกับ การโอนเงินก่อนหน้านี้ ไปยังบัญชี ผู้รวมการชำระเงิน ของผู้ใช้แบบซิงโครนัส โอนความรับผิด ไปยัง Google | บรรทัดการคืนเงินในไฟล์ คำขอแบบกลุ่ม |
| การโอนเงิน | ข้อตกลงแบบ API โดยเฉพาะในแต่ละวัน | ไฟล์รายละเอียดใบแจ้งหนี้รายเดือนในรูปแบบไฟล์ PDF ไฟล์รายละเอียดใบแจ้งหนี้รายเดือน ไฟล์สรุปรายวัน |
| UpdateAssociatedAccount | แจ้งให้ Google ทราบถึง การเปลี่ยนแปลงในบัญชี ผู้รวมการชำระเงิน ของผู้ใช้ (เช่น ขีดจำกัดธุรกรรมหรือสถานะการจัดสรร) | โพล GetProvisioning() |
| การประพฤติมิชอบ | แจ้ง Google เกี่ยวกับธุรกรรมที่ถูกยกเลิกเนื่องจากการโต้แย้งของผู้ใช้ กระบวนการนี้ ใช้เพื่อปรับปรุง เครื่องมือความเสี่ยงของ Google แต่ไม่ส่งผลกระทบต่อ หนี้สินเงิน | ไม่มี |
การเปรียบเทียบโดยรวมกับข้อมูลจำเพาะของ DCB3
ข้อกำหนดของการชำระเงินมาตรฐานของ Google จะแก้ไขปัญหาเดียวกับที่ข้อมูลจำเพาะของ DCB3 แก้ไข แต่ใช้เทคโนโลยีและการออกแบบ API ต่างๆ เพื่อปรับปรุงโซลูชัน ความแตกต่างที่สำคัญโดยสรุปมีดังนี้
การเปรียบเทียบเทคโนโลยีสแต็ก
การสื่อสารของ API ทั้งหมดดำเนินการโดยใช้ HTTPS POST กับ JSON ที่เข้ารหัสโดย PGP และลงชื่อ ซึ่งหมายความว่า Google และผู้รวมการชำระเงินแต่ละรายจะมีคีย์ PGP ให้หมุนเวียนเพียงคีย์เดียวเท่านั้น เทคโนโลยีเหล่านี้มีการสนับสนุนที่ดีกว่า SOAP ด้วย ดูรายละเอียดเพิ่มเติมเกี่ยวกับสแต็กการสื่อสารได้ที่นี่
การเปรียบเทียบปรัชญา API
DCB3 อาศัยไฟล์อย่างมากในการปรับยอดสถานะการชำระเงิน การชำระเงินมาตรฐานของ Google ไม่มีไฟล์ การเรียก API จะลองใหม่ไปเรื่อยๆ ไปเรื่อยๆ จนกว่าจะกำหนดสถานะสุดท้าย
สถานะสุดท้ายถือเป็นค่าสุดท้ายอย่างแท้จริงสำหรับคีย์ประจำตัว ข้อบกพร่องและสถานะที่ไม่แน่นอนจะไม่ได้รับการประมาณเป็นการปฏิเสธ แต่จะเป็นการตอบกลับ HTTP ที่ไม่ใช่ 200 วิธีนี้ช่วยให้เราตรวจจับข้อบกพร่องได้เร็วขึ้นและหลีกเลี่ยงการมาสก์เป็นการปฏิเสธ
ฟีเจอร์ใหม่
การชำระเงินแบบมาตรฐานของ Google รองรับฟีเจอร์ใหม่ ดังนี้
- Fraud API เพื่อระบุเครื่องมือความเสี่ยงของ Google ว่าเป็นผู้ฉ้อโกง
- อัปเดต API ของบัญชีที่เชื่อมโยงเพื่อแจ้งให้ Google ทราบเกี่ยวกับการจัดสรร ขีดจำกัดธุรกรรม และการเปลี่ยนแปลงสถานะบัญชี
- รองรับการยืนยันเพิ่มมากขึ้นในระหว่างการซื้อ เช่น PIN ของ USSD
- รอบการส่งเงินประจำวัน
การจับคู่คำศัพท์จาก DCB3 มาเป็นการชำระเงินมาตรฐานของ Google
ในเอกสารประกอบนี้และข้อมูลจำเพาะ คุณจะเห็นคำศัพท์ใหม่ๆ แต่ที่จริงแล้วเป็นคำที่ต่างกันสำหรับแนวคิดที่มีอยู่
- ผู้ให้บริการ -> ผู้รวมการชำระเงิน
คำเตือน: เพื่อหลีกเลี่ยงความสับสนเกี่ยวกับแนวคิดผู้ผสานการชำระเงิน DCB เอกสารฉบับนี้จะพยายามใช้ "ผู้รวมการชำระเงิน" และ "ผู้ผสานการชำระเงิน DCB" แทนที่จะใช้แค่ "ผู้ผสานการชำระเงิน" อย่างไรก็ตาม เอกสารทั่วไปของ Google เกี่ยวกับการชำระเงินแบบมาตรฐานจะใช้คำว่า "ผู้รวมบริการ" เป็นคำย่อสำหรับ "ผู้รวมการชำระเงิน" อย่างอิสระ
- รหัสข้อตกลงการเรียกเก็บเงิน -> รหัสบัญชีผู้รวมการชำระเงิน
- OperatorUserToken (OUT) -> GooglePaymentToken (GPT)
- relion_id -> requestId
- ส่วนแบ่งรายได้ -> ค่าธรรมเนียม
ขั้นตอนการตรวจสอบสิทธิ์
ดูภาพรวมทั่วไปของขั้นตอนการตรวจสอบสิทธิ์สำหรับ FOP ที่ใช้เทคโนโลยีโทเค็น โปรดดูหน้านี้
รายละเอียดการเรียกเก็บเงินผ่านผู้ให้บริการมือถือ
สำหรับการเรียกเก็บเงินผ่านผู้ให้บริการมือถือ เป้าหมายของขั้นตอนการตรวจสอบสิทธิ์คือการพิสูจน์ว่าผู้ใช้ได้ควบคุมซิมการ์ดที่เชื่อมโยงกับบัญชีผู้ให้บริการของตน ผู้ใช้การเรียกเก็บเงินผ่านผู้ให้บริการมือถือสามารถตรวจสอบสิทธิ์ได้โดยใช้กลไกทั้ง 3 นี้
- การตรวจสอบสิทธิ์ SMS-MO (คำนิยามในภาพรวม FOP ที่ใช้เทคโนโลยีโทเค็น)
- การตรวจสอบสิทธิ์การเปลี่ยนเส้นทาง (คำนิยามในภาพรวม FOP ที่ใช้เทคโนโลยีโทเค็น)
- SMS-MT OTP (คำจำกัดความใน FOP ที่ใช้เทคโนโลยีโทเค็น)
โปรแกรมรวมการชำระเงินสามารถทำงานร่วมกับ Google เพื่อเลือกกลไกการตรวจสอบสิทธิ์ที่เหมาะกับผลิตภัณฑ์ของตนมากที่สุด
เปรียบเทียบกับ DCB3
ขั้นตอนการตรวจสอบสิทธิ์จะแทนที่โค้ดเรียกกลับ approveuser ไปยัง Google โดยไม่ใช้ข้อมูลจำเพาะของ DCB3
ใน DCB3 การตรวจสอบสิทธิ์และการเชื่อมโยงได้รวมกันเป็นขั้นตอนเดียว สำหรับ การชำระเงินมาตรฐานของ Google การตรวจสอบสิทธิ์จะเป็นคนละเรื่องกับ การเชื่อมโยงบัญชี
โฟลว์การเชื่อมโยง
โปรดดูภาพรวมทั่วไปของขั้นตอนการเชื่อมโยงสำหรับ FOP ที่ใช้เทคโนโลยีโทเค็น โปรดดูหน้านี้
ความแตกต่างหลักระหว่างขั้นตอนการเชื่อมโยงที่ใช้สำหรับเครื่องมือการเรียกเก็บเงินผ่านผู้ให้บริการเครือข่ายมือถือกับขั้นตอน FOP ที่ใช้เทคโนโลยีโทเค็นทั่วไปคือ หลักฐานการตรวจสอบสิทธิ์ที่ระบุไว้ในวิธี associateAccount จะต่างกันไปขึ้นอยู่กับว่าผู้รวมการชำระเงินขอการยืนยันตัวตนผู้ใช้เพิ่มเติมหรือไม่
หากผู้รวมการชำระเงินตอบกลับว่าพวกเขาต้องการคำท้าจากผู้ใช้เพิ่มเติม หลักฐานการตรวจสอบสิทธิ์คือหลักฐานยืนยันตัวตนใดๆ ก็ตามที่ผลิตโดยกลไกการตรวจสอบสิทธิ์ที่ Google ใช้ในการตอบคำถามเพิ่มเติม เช่น หลักฐานการตรวจสอบสิทธิ์ที่สร้างขึ้นโดยกลไก SMS-MT OTP คือ requestId ของเมธอด sendOtp บวกกับ OTP เอง
แอตทริบิวต์ของเครื่องมือ
ส่วนแอตทริบิวต์เครื่องมือของภาพรวม FOP ที่ใช้เทคโนโลยีโทเค็นจะพูดถึงแนวคิดของ accountAlias, accountNickname และ fullAccountNickname
รายละเอียดการเรียกเก็บเงินผ่านผู้ให้บริการมือถือ
accountAliasควรเป็นหมายเลขโทรศัพท์ของผู้ใช้ ซึ่งจะใช้เพื่อช่วยระบุเครื่องมือในกรณีที่ผู้ใช้ติดต่อทีมสนับสนุนของ Google เกี่ยวกับบัญชีของตนaccountNicknameและfullAccountNicknameคือชื่อที่แสดงซึ่งใช้เพื่อระบุเครื่องมือใน UI
การเปรียบเทียบกับข้อมูลจำเพาะของ DCB3
ขั้นตอนการเชื่อมโยงจะใช้แทนคอมโพเนนต์ต่อไปนี้ของข้อกำหนด DCB3
- การเรียก SOAP ของ GetProvisioning
- การเรียกใช้ SOAP ของ GetSubscriberAddress
- OUT ที่สร้างโดยผู้ให้บริการ
ความแตกต่างที่สำคัญคือ Google จะสร้าง Google Payment Token (GPT) ในขั้นตอนการเชื่อมโยงแทนที่จะสร้างโทเค็นโดยผู้ให้บริการ
สิ่งสำคัญอีกอย่างคือ GPT ไม่ได้จำกัดขอบเขตที่ PaymentIntegratorAccountID ใดโดยเฉพาะ ซึ่งต่างจาก DCB3 ที่ OUT กำหนดขอบเขตไปที่ BillingAgreementId ที่เฉพาะเจาะจง
ขั้นตอนการรีเฟรชโทเค็น
สำหรับภาพรวมทั่วไปของขั้นตอนโทเค็นการรีเฟรชสำหรับ FOP ที่ใช้เทคโนโลยีโทเค็น โปรดดูหน้านี้
รายละเอียดการเรียกเก็บเงินผ่านผู้ให้บริการมือถือ
สำหรับเครื่องมือการเรียกเก็บเงินผ่านผู้ให้บริการมือถือ เราไม่สนับสนุนให้โทเค็นการชำระเงิน Google หมดอายุ เนื่องจากจะทำให้ใบสั่งซื้อการสมัครรับข้อมูลถูกยกเลิก แทนที่จะอาศัยขั้นตอนการรีเฟรชโทเค็นเพื่อแก้ไขโทเค็นที่หมดอายุ กรณีการใช้งานของคุณมักจะสามารถทำได้โดยใช้ขั้นตอนการอัปเดตบัญชีที่อธิบายไว้ด้านล่างแทน
ขั้นตอนการอัปเดตบัญชี
ขั้นตอนการอัปเดตบัญชีช่วยให้ผู้รวมการชำระเงินแจ้ง Google เกี่ยวกับการอัปเดตบัญชีผู้รวมบริการของผู้ใช้ได้ ก่อนหน้านี้ช่องเหล่านี้จะส่งให้ Google ระหว่างขั้นตอนการเชื่อมโยง ตัวอย่างข้อมูลบัญชีที่ ผู้รวมการชำระเงินอาจต้องการอัปเดต ได้แก่
- ขีดจำกัดธุรกรรมรายเดือน รายวัน และต่อรายการของผู้ใช้
- สถานะการจัดสรรของบัญชีผู้ผสานการทำงานของผู้ใช้
- ประเภทบัญชีผู้รวมบริการของผู้ใช้ (ชำระเงินล่วงหน้า ชำระเงินภายหลัง สำหรับองค์กร ฯลฯ)
- "accountAlias" "accountNickname" หรือ "fullAccountNickname" ของผู้ใช้
- ผู้ใช้ได้ตั้งค่า ลบ หรือเปลี่ยนแปลง PIN แบบคงที่ที่แชร์ไว้ล่วงหน้าหรือไม่
- ไม่ว่าผู้ใช้ได้ปิดบัญชีหรือเปลี่ยนหมายเลขโทรศัพท์แล้ว ทำให้เครื่องมือของผู้ใช้ในระบบของ Google ไม่ถูกต้อง
- ลบโฟลว์โทเค็น
การเปรียบเทียบกับข้อมูลจำเพาะของ DCB3
ขั้นตอนการอัปเดตบัญชีจะใช้องค์ประกอบต่อไปนี้ของข้อกำหนด DCB3
- การสำรวจการเรียก SOAP ของ GetProvisioning
- การเลิกใช้โทเค็นเป็นระยะๆ
ขั้นตอนการซื้อ
ดูภาพรวมทั่วไปของขั้นตอนการซื้อสำหรับรูปแบบ FOP ที่ใช้เทคโนโลยีโทเค็น โปรดดูหน้านี้
รายละเอียดการเรียกเก็บเงินผ่านผู้ให้บริการมือถือ
ผู้ให้บริการบางรายใช้ USSD หรือเทคโนโลยีอื่นเพื่อรวบรวม PIN จากผู้ใช้ในระหว่างการซื้อแต่ละครั้ง สำหรับผู้ให้บริการเหล่านี้ แทนที่จะเรียก catch() เราเรียกว่า อะซิงโครนัสแคปเจอร์() และเราให้เวลา 30 วินาทีเพื่อให้ผู้ให้บริการ แจ้ง PIN จากผู้ใช้และทำการบันทึกให้เสร็จสิ้น เมื่อทราบผลการชำระเงินขั้นสุดท้ายแล้ว ผู้ให้บริการจะแจ้งให้ Google ทราบผลโดยเรียก captureResultNotification()
การเปรียบเทียบกับข้อมูลจำเพาะของ DCB3
มีการเปลี่ยนแปลงที่สำคัญ
- การเรียกใช้เมธอดแบบซิงโครนัส -- capture() แทน auth() + ไฟล์กลุ่ม
- ไม่มีไฟล์กลุ่มเลย
- ไม่มีเมธอด cancel() (จับภาพ + คืนเงินแทนการตรวจสอบสิทธิ์ + ยกเลิก)
- ไม่มีช่อง user_message ในการตอบกลับ รหัสการปฏิเสธจะจับคู่กับข้อความที่ Google เป็นเจ้าของซึ่งแปลเป็นภาษาบัญชีของผู้ใช้
- การเปลี่ยนแปลงคำศัพท์ที่สำคัญมีดังนี้
- CorrelationId -> requestId
- รหัสข้อตกลงการเรียกเก็บเงิน -> paymentIntegratorAccountId
- OperatorUserToken -> googlePaymentToken
ขั้นตอนการซื้อที่ประสบปัญหา
การพัฒนาอย่างต่อเนื่องเพื่อรองรับขั้นตอนการซื้อที่มีคำถามเพื่อตรวจสอบสิทธิ์ของผู้ใช้ก่อนการซื้อแต่ละครั้ง วิธีการตรวจสอบสิทธิ์ส่วนใหญ่ที่ใช้ก่อนขั้นตอนการเชื่อมโยงได้ยังใช้ก่อนขั้นตอนการซื้อที่ท้าทายได้ด้วย เพื่อให้มีการตรวจสอบสิทธิ์ผู้ใช้เพิ่มเติม
ขั้นตอนการคืนเงิน
ดูภาพรวมทั่วไปของขั้นตอนการคืนเงินสําหรับรูปแบบ FOP ที่ใช้เทคโนโลยีโทเค็น โปรดดูหน้านี้
รูปแบบ FOP ที่แปลงข้อมูลเป็นโทเค็นรองรับขั้นตอนการคืนเงินข้อความเดียว วิธีการคืนเงินจะรองรับการคืนเงินสำหรับการซื้อเต็มจำนวน หรือการคืนเงินบางส่วน การคืนเงินแบบบางส่วนหลายรายการสามารถคืนเงินการซื้อครั้งเดียวได้
รายละเอียดการเรียกเก็บเงินผ่านผู้ให้บริการมือถือ
ขั้นตอนการคืนเงินไม่ได้มีความพิเศษเกี่ยวกับเครื่องมือการเรียกเก็บเงินผ่านผู้ให้บริการเครือข่ายมือถือ
การเปรียบเทียบกับข้อมูลจำเพาะของ DCB3
ระบบจะทริกเกอร์การคืนเงินโดยการเรียก API แบบพร้อมกันแทนที่จะเป็นไฟล์ นอกจากนี้ ยังอาจมีการคืนเงินบางส่วนหลายครั้งสำหรับการชำระเงินเดิมครั้งเดียว แทนที่จะรองรับการคืนเงินเต็มมูลค่าเพียงครั้งเดียวเท่านั้น
ขั้นตอนการส่งเงิน
ดูภาพรวมทั่วไปของขั้นตอนการส่งเงินสําหรับ FOP ที่ใช้เทคโนโลยีโทเค็น โปรดดูหน้านี้
ขั้นตอนการส่งเงินคือการดำเนินการทำข้อตกลงของ Google และผู้รวมการชำระเงิน Google เป็นระบบบัญชีการบันทึกและรับผิดชอบการโอนการส่งเงิน Google จะส่งใบแจ้งยอดการโอนเงินไปยังผู้รวมการชำระเงินเป็นประจำ ใบแจ้งยอดการชำระเงินมีสรุปจำนวนเงินที่ผู้รวมการชำระเงินค้างชำระกับ Google พร้อมกับวิธีการชำระเงินให้ Google เพื่อให้ผู้รวมการชำระเงินปรับยอดได้ ผู้รวมการชำระเงินสามารถสืบค้นรายละเอียดระดับธุรกรรมจาก Google ที่ประกอบขึ้นเป็นใบแจ้งยอดการชำระเงินได้
รายละเอียดการเรียกเก็บเงินผ่านผู้ให้บริการมือถือ
การเรียกเก็บเงินผ่านผู้ให้บริการเครือข่ายมือถือ remittanceStatementDetails มีช่องอื่นๆ ที่ไม่ได้ระบุไว้ในคำจำกัดความ API ของขั้นตอนการส่งเงิน ซึ่งรวมถึงการใช้งานดังต่อไปนี้
- revshareCategory
- itemPrice
- tax
- การประทับเวลา
สำหรับผู้ให้บริการที่มีข้อตกลงแยกส่วนแบ่งรายได้ 50/50 กับ Google ค่าธรรมเนียมที่แสดงใน remittanceStatementDetails จะรวมเป็นราย revshareCategory แทนที่จะแสดงแยกเป็นรายกิจกรรม
การเปรียบเทียบกับข้อมูลจำเพาะของ DCB3
ขั้นตอนการส่งเงินจะแทนที่แนวคิดต่อไปนี้ในข้อกำหนดของ DCB3
- รายงานการเรียกเก็บเงินรายเดือน/Payment Report PDF
- ไฟล์ CSV รายละเอียดใบแจ้งหนี้รายเดือน
- ไฟล์ CSV การปรับยอดรายวัน
ความแตกต่างที่สำคัญคือการนำไฟล์ออกและการรองรับการส่งเงินรายวัน ระบบจะส่งจำนวนเงินที่ต้องส่งผ่าน API แบบซิงโครนัสและ API อื่นรองรับการค้นหารายละเอียดเกี่ยวกับคำชี้แจงการส่งเงินแทนไฟล์
ขั้นตอนการรายงานการประพฤติมิชอบ
ขั้นตอนการรายงานการประพฤติมิชอบช่วยให้ผู้ผสานรวมการชำระเงินแจ้ง Google เกี่ยวกับธุรกรรมที่อาจเป็นการฉ้อโกงได้โดยการเรียกใช้เมธอด fraudNotification กระบวนการนี้ใช้เพื่ออัปเดตเครื่องมือความเสี่ยงภายในของ Google และไม่ได้ริเริ่มความเคลื่อนไหวของเงิน
รายละเอียดการเรียกเก็บเงินผ่านผู้ให้บริการมือถือ
เครื่องมือการเรียกเก็บเงินผ่านผู้ให้บริการมือถือในขั้นตอนการแจ้งเตือนการดึงเงินคืนไม่ได้มีความพิเศษ