อภิธานศัพท์

รหัสบัญชี

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

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

แพ็กเกจแอปพลิเคชัน Android (APK)

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

การกำหนดเวอร์ชัน API

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

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

รหัสการเชื่อมโยง

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

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

ผู้รวมบริการชำระเงินจะต้องจัดเก็บรหัสการเชื่อมโยงทั้งหมดและเชื่อมโยงรหัสเหล่านั้นกับบัญชีผู้รวมบริการหนึ่งๆ ตลอดอายุสัญญาระหว่างผู้รวมระบบกับ Google

รหัสคำขอการตรวจสอบสิทธิ์

การบันทึกเมธอด refreshToken, associateAccount และ (ไม่บังคับ) จะใช้การอ้างอิงไปยังการตรวจสอบสิทธิ์ ข้อมูลอ้างอิงนี้อยู่ในรูปแบบ requestId ของการตรวจสอบสิทธิ์ที่เจาะจงที่ Google ใช้อ้างอิง ผู้ผสานการชำระเงินจะใช้ช่องนี้ในการตรวจสอบว่าระบบได้ดำเนินการตรวจสอบสิทธิ์สำเร็จเรียบร้อยแล้ว

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

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

บริษัท

บริษัทคือแนวคิดที่กำหนดไว้ในการกำหนดค่าและสัญญาของ Google บริษัทจะกำหนดความสัมพันธ์ระหว่างผู้ผสานการทำงานระบบและ Google คีย์ PGP และ (ไม่บังคับ) CA ระดับรูท SSL เชื่อมโยงกับบริษัท สิ่งสำคัญที่สุดคือบริษัทหนึ่งๆ จะเชื่อมโยงกับรหัสบัญชีของผู้รวมการชำระเงินอย่างน้อย 1 รหัส GPT ที่สร้างขึ้นภายในบริษัทมักจะทำงานกับรหัสบัญชีของผู้รวมการชำระเงินทั้งหมดภายในบริษัท มีข้อยกเว้นบางประการ ตัวอย่างเช่น หาก GPT เชื่อมโยงกับบัญชีที่ใช้สกุลเงินหนึ่ง (และไม่รองรับค่าธรรมเนียม FX) และพยายามทำการซื้อด้วยรหัสบัญชีของผู้รวมการชำระเงินในสกุลเงินอื่น

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

ธุรกรรมทั้งหมดประกอบด้วยรูปแบบการชำระเงิน (FOP) อย่างน้อย 1 รูปแบบ เช่น บัตรเครดิตหรือการโอนเงินทางอิเล็กทรอนิกส์ ซึ่งผู้ใช้ใช้เพื่อชำระเงินให้กับ Google สำหรับผลิตภัณฑ์หรือบริการ หรือโดย Google เพื่อชำระเงินแก่ผู้ใช้ในกรณีของผู้ใช้ AdSense และนักพัฒนาซอฟต์แวร์ของ Google Play รูปแบบการชำระเงินยังมักเรียกว่าเครื่องมือการชำระเงิน เครื่องมือ และวิธีการชำระเงิน

โทเค็นการชำระเงิน Google (GPT)

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

GPT แตกต่างจาก associationId เนื่องจาก associationId ไม่ได้รับการปกป้องและส่งผ่านวิธีการสาธารณะได้อย่างอิสระ (URL, การเชื่อมต่อที่ไม่ปลอดภัย) เฉพาะ Google และผู้รวมระบบเท่านั้นที่จะรู้จัก GPT

เราคาดหวังว่าผู้ผสานการชำระเงินจะจัดเก็บ GPTS ทั้งหมดและเชื่อมโยง GPTS เข้ากับบัญชีผู้รวมบริการโดยเฉพาะตลอดอายุสัญญาระหว่างผู้ผสานการทำงานระบบกับ Google

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

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

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

โปรดดูตัวอย่างของลักษณะการทำงานที่เป็นนิจพลใน เอกสารอ้างอิง

ตัวระบุ (ID)

ตัวระบุแสดงถึงธุรกรรมหรือการสื่อสารระหว่างผู้รวมการชำระเงินกับ Google

เครื่องมือ

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

• หมายเลขบัตรเครดิตที่บันทึกไว้
• บัญชีธนาคารและ Routing Number

ผู้ใช้สามารถเชื่อมโยงเครื่องมือหลายอย่างกับข้อมูลประจำตัวของ Google

Micros

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

เช่น

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

ผู้รวมการชำระเงิน

ผู้รวมบริการภายนอกที่ประมวลผลการชำระเงินสำหรับธุรกรรมของผู้ใช้

รหัสบัญชีของผู้รวมการชำระเงิน

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

ตัวระบุนี้จะไม่เปลี่ยนแปลงตลอดอายุของธุรกรรม ในกรณีที่มีการจับภาพและการคืนเงิน จะมีการใช้ตัวระบุเดียวกัน

ในสัญญาจะเป็นผู้กำหนดข้อจำกัดของรหัสบัญชีผู้รวมบริการ โดยทั่วไปแล้ว ข้อจำกัดจะขึ้นอยู่กับการแจ้งหนี้ ตัวอย่างเช่น ผู้รวมบริการรองรับ CAD และ MXN ที่ออกใบแจ้งหนี้เป็น USD แต่ธุรกรรม EUR ต้องออกใบแจ้งหนี้เป็น EUR ในกรณีนี้จะใช้รหัสบัญชีของผู้รวมชำระเงิน 2 รหัสที่ต่างกัน รหัสหนึ่งใช้สำหรับการแจ้งหนี้ USD และอีกรหัสหนึ่งสำหรับการแจ้งหนี้ EUR

คุณสามารถเลิกใช้ตัวระบุเพื่อเปลี่ยนไปใช้ตัวระบุใหม่ ในกรณีที่มีการเลิกใช้งานตัวระบุ Google จะหยุดการดักจับตัวระบุดังกล่าว แต่ผู้รวมบริการต้องคืนเงินสำหรับธุรกรรมที่ดำเนินการโดยใช้ตัวระบุดังกล่าวเป็นเวลา 1 ปีนับจากเริ่มการบันทึกครั้งล่าสุด (การเริ่มจับภาพหมายถึง requestTimestamp ที่พบใน requestHeader)

PII

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

ID คำขอ

requestId จะระบุการสื่อสารทั้งหมดระหว่าง Google กับผู้รวมการชำระเงิน

SPII

ข้อมูลส่วนบุคคลที่ระบุตัวบุคคลนั้นได้ (SPII) ที่ละเอียดอ่อนคือชุดย่อยของข้อมูลส่วนบุคคลที่ระบุตัวบุคคลนั้นได้ (PII) ซึ่งมีความเสี่ยงสูงต่อผู้ใช้หากมีการบุกรุกหรือใช้ในทางที่ผิด บ่อยครั้งที่ SPII มีข้อกำหนดการจัดการและการจัดเก็บที่เข้มงวดซึ่งกำหนดโดยหน่วยงานด้านกฎหมาย หน่วยงานกำกับดูแล หรือผู้ปฏิบัติตามข้อกำหนด

โทเค็น

โทเค็นจะเพิ่มความปลอดภัยอีกชั้นหนึ่งเมื่อมีการแลกเปลี่ยนข้อมูลเข้าสู่ระบบที่มีความละเอียดอ่อน เช่น PII หรือ SPII ระหว่าง Google กับผู้ผสานการทำงาน

ที่อยู่ของผู้ใช้

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

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

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

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

การเข้ารหัส Base64 ที่ใช้กับเว็บได้อย่างปลอดภัย

มาตรฐานการเข้ารหัสที่ระบุใน RFC 4648 ส่วนที่ 5 การเข้ารหัส Base 64 ด้วย URL และตัวอักษรที่ปลอดภัยสำหรับชื่อไฟล์ หรือบางครั้งเรียกว่าการเข้ารหัส "web-safe Base64" หรือ "base64url" (เหมือนกับการเข้ารหัส base64 ด้วย URL และตัวอักษรที่ปลอดภัยของชื่อไฟล์จาก RFC 3548 ส่วนที่ 4) ค่าที่เข้ารหัสและแบบมีลายเซ็นทั้งหมดต้องเข้ารหัสโดยใช้มาตรฐานนี้