Wallet pass API ช่วยให้ระบบหลังบ้านของคุณสร้างบัตรให้ลูกค้าแต่ละคน พร้อมชื่อ ยอดคงเหลือ บาร์โค้ด และสถานที่ของคนนั้น แล้วอัปเดตบัตรทุกครั้งที่ข้อมูลเปลี่ยน คุณออกแบบเทมเพลตครั้งเดียว ส่งค่าเฉพาะบุคคลรายผู้ใช้ แล้วได้ลิงก์ติดตั้งสำหรับ Apple Wallet หรือลิงก์บันทึก (save link) สำหรับ Google Wallet กลับมา ในไทยที่ผู้ใช้ Android กับ iOS ใกล้เคียงกัน (ราว 60/40) การออกบัตรทั้ง 2 แพลตฟอร์มจากข้อมูลชุดเดียวจึงเป็นเรื่องปกติ ไม่ใช่ทางเลือกเสริม
ไม่ใช่ทุกทีมที่ต้องใช้ API ตัวอย่างในบทความนี้ใช้ Wallet passes API ของ Pushwoosh ซึ่งบัตรทุกใบผูกกับ User ID เดียวกับที่ใช้ขับเคลื่อน push, อีเมล และ journey ของคุณครับ
เมื่อไรที่ API ดีกว่า builder
Builder เหมาะกับการออกแบบบัตรและการส่งจำนวนน้อยหรือครั้งเดียว API จะเข้ามารับงานเมื่อบัตรต้องพึ่งข้อมูลที่อยู่ในระบบของคุณเอง เช่น ระบบสมาชิกของเครือค้าปลีก ระบบจองของโรงแรม หรือระบบ core banking
| งาน | Builder | API | ขั้นตอนใน journey |
|---|---|---|---|
| ออกแบบเทมเพลต | ได้ | ได้ | ไม่ได้ |
| ออกบัตรให้ลูกค้า 1 คน | ได้ | ได้ | ได้ |
| ออกบัตรหลายพันใบ แต่ละใบมีค่าของตัวเอง | ไม่ได้ | ได้ | ได้ |
| อัปเดตแบบเรียลไทม์จาก POS หรือระบบจอง | ไม่ได้ | ได้ | ไม่ได้ |
| เลือก 10 สาขาที่ใกล้ลูกค้าแต่ละคนที่สุด | ไม่ได้ | ได้ | ไม่ได้ |
ดูคอลัมน์ journey ก่อนเขียนโค้ดบรรทัดแรก ถ้า trigger คือการกระทำของลูกค้าที่ Pushwoosh ติดตามอยู่แล้ว ขั้นตอน Issue Wallet Pass ใน Customer Journey มักทำให้ไม่ต้องเขียนโค้ดเองเลย
เทมเพลตและค่าเฉพาะบุคคล
รูปแบบเหมือนกันทั้ง 2 แพลตฟอร์ม เทมเพลตเก็บเลย์เอาต์ แบรนด์ และโครงสร้างฟิลด์ ส่วนค่ารายผู้ใช้จะถูกเติมลงไปตอนออกบัตร
ค่าเฉพาะบุคคลคือสิ่งที่ต่างกันในลูกค้าแต่ละคน ได้แก่ ชื่อ หมายเลขสมาชิก แต้ม ระดับสมาชิก ค่าบาร์โค้ด วันหมดอายุ และสาขาที่ใกล้ที่สุด สำหรับโรงแรมอาจเป็นหมายเลขการจองและวันเช็กอิน ที่เหลือทั้งหมดมาจากเทมเพลต การเปลี่ยนดีไซน์จึงมีผลกับบัตรใหม่ทุกใบโดยไม่ต้องแตะ integration ของคุณ
ใน journey ขั้นตอน Issue Wallet Pass รับแคมเปญบัตร Apple และ Google (apple_campaign_id, google_campaign_id) และ personal_values ที่จะเติม ขั้นตอนเดียวออกบัตรได้ทั้ง 2 เวอร์ชันให้ User ID เดียวกัน
ขั้นตอนฝั่ง Apple Wallet
ทุกอย่างที่ Apple pass builder ทำได้ ใช้ผ่าน Apple Wallet PassKit API ได้เช่นกัน ทั้งสร้าง อัปเดต แสดงรายการ ดาวน์โหลด และลบบัตร
integration ทั่วไปมี 4 ขั้นตอน
- 1
ตรวจสอบ
ตรวจข้อมูลบัตรเทียบกับข้อกำหนดของ Apple ก่อนสร้างอะไรทั้งนั้น การจับฟิลด์ที่ผิดตรงนี้ถูกกว่าไปเจอใน wallet ของลูกค้า
- 2
สร้าง
สร้างบัตรให้ User ID พร้อมค่าเฉพาะบุคคล Pushwoosh สร้างบัตรและเซ็นด้วยใบรับรอง Pass Type ID ของคุณ
- 3
แชร์
แชร์ลิงก์ติดตั้งทางอีเมล, SMS, push, QR หรือแนบในข้อความ LINE
- 4
อัปเดต
อัปเดตบัตรเมื่อข้อมูลของคุณเปลี่ยน Pushwoosh แจ้งอุปกรณ์ที่ลงทะเบียนไว้ และ iOS ดึงเวอร์ชันใหม่มาในเบื้องหลัง
คุณต้องมีใบรับรอง Pass Type ID (.p12) ต่อแอปพลิเคชัน และบัญชี Apple Developer ($99 ต่อปี) การตั้งค่าดูได้ใน เอกสารการตั้งค่า iOS Wallet pass
ขั้นตอนฝั่ง Google Wallet
Google Wallet API ครอบคลุมวงจรชีวิตเดียวกันสำหรับบัตร Google
- 1
สร้าง
สร้าง pass object ให้ User ID พร้อมค่าเฉพาะบุคคล
- 2
รับ save link
รับ save link ซึ่งเป็น URL ที่ขึ้นต้นด้วย pay.google.com/gp/v/save/ แล้วแชร์ออกไป
- 3
อัปเดต
อัปเดตบัตร Google จะซิงก์การเปลี่ยนแปลงไปยังทุกเครื่องที่บันทึกบัตรไว้
- 4
เปลี่ยนสถานะ
เปลี่ยนสถานะเมื่อจำเป็น ได้แก่ invalidate, reactivate หรือ delete
คุณต้องมี Issuer ID จาก Google Pay & Wallet Console และเชิญ service account ของ Pushwoosh เข้า issuer ของคุณ ตั้งค่าครั้งเดียวต่อแอปพลิเคชัน การตั้งค่าดูได้ใน เอกสารการตั้งค่า Google Wallet
อัปเดตในวงกว้าง
การอัปเดตคือจุดที่ API คุ้มค่าที่สุด บัญชีแต้มสะสมหรือระบบจองอัปเดตบัตรได้ทันทีที่ค่าเปลี่ยน บัตรใน wallet ของลูกค้าจึงตรงกับข้อมูลต้นทางของคุณเสมอ ซึ่งสำคัญมากในช่วงที่ยอดพุ่งอย่างสงกรานต์หรือ 11.11
3 กฎที่ทำให้การอัปเดตจำนวนมากปลอดภัย:
- เริ่มจากบัตรปัจจุบัน การอัปเดตของ Apple รับ pass object ทั้งก้อน จึงต้องดึงบัตรมาก่อนแล้วเปลี่ยนเฉพาะค่าที่ขยับ ส่วนการอัปเดตของ Google เป็นการ patch object
- ตัดสินใจเรื่องการแจ้งเตือนทีละฟิลด์ บน Apple เฉพาะฟิลด์ที่มี change message เท่านั้นที่แสดงการแจ้งเตือนบนหน้าจอล็อก บน Google
notifyOnUpdateขอให้ Google ส่งการแจ้งเตือนของตัวเอง ซึ่งทำงานเฉพาะบัตรสะสมแต้ม บัตรอีเวนต์ และบัตรเที่ยวบิน ไม่เกิน 3 ครั้งต่อบัตรใน 24 ชั่วโมง ส่วนnotifyMessageส่งข้อความแจ้งเตือน Android ของคุณเองได้กับบัตรทุกประเภท - ให้การแจ้งเตือนเป็นเรื่องของบัตร Apple และ Google อนุญาตการแจ้งเตือนเกี่ยวกับบัตร ไม่ใช่โปรโมชัน
อ่านเพิ่มเติม: วิธีอัปเดต wallet pass หลังลูกค้าเพิ่มบัตรแล้ว
ตัวอย่างโค้ด
ทั้ง 2 API ใช้ base URL https://apple-passkit.svc-nue.pushwoosh.com และ API access token ของ Pushwoosh ใน header Authorization: Token <api-token> body ของ request ด้านล่างคือตัวอย่างจากเอกสารอ้างอิง API
สร้างบัตร Apple Wallet: POST /api/pass/create response จะคืน serialNumber ของบัตร
{ "applicationCode": "XXXXX-XXXXX", "userId": "user-123", "pass": { "description": "Acme loyalty card", "logoText": "Acme", "backgroundColor": "rgb(60, 65, 76)", "foregroundColor": "rgb(255, 255, 255)", "labelColor": "rgb(255, 255, 255)", "storeCard": { "primaryFields": [ { "key": "balance", "label": "BALANCE", "value": "1200 pts" } ], "secondaryFields": [ { "key": "member", "label": "MEMBER", "value": "Jane Doe" } ] }, "barcodes": [ { "format": "PKBarcodeFormatQR", "message": "1234567890", "messageEncoding": "iso-8859-1" } ] }, "images": [ { "imageType": "icon", "data": "<base64>", "contentType": "image/png" }, { "imageType": "logo", "data": "<base64>", "contentType": "image/png" } ]}สร้างบัตร Google Wallet: POST /api/google/pass/create response จะคืน serialNumber และ saveLink
{ "applicationCode": "XXXXX-XXXXX", "userId": "user-123", "pass": { "hexBackgroundColor": "#3c414c", "logoUrl": "https://cdn.acme.com/logo.png", "loyalty": { "programName": "Acme Rewards", "accountName": "Jane Doe", "accountId": "1234567890", "pointsLabel": "Points", "pointsBalance": "1200", "rewardsTier": "Gold" }, "barcode": { "format": "QR_CODE", "value": "1234567890" } }}การอัปเดตให้ส่งเนื้อหาใหม่พร้อม serial number ไปที่ POST /api/pass/update/{serialNumber} สำหรับ Apple และ POST /api/google/pass/update/{serialNumber} สำหรับ Google
Builder, API หรือ journey: หลักง่าย ๆ
ใช้ builder เพื่อออกแบบและทดสอบ ใช้ขั้นตอนใน journey เมื่อ trigger คือ event ของลูกค้าที่อยู่ใน Pushwoosh อยู่แล้ว เช่น การสมัครสมาชิกหรือการซื้อครั้งแรก ใช้ API เมื่อ trigger หรือข้อมูลอยู่ในระบบหลังบ้านของคุณ เช่น การยืนยันการจองห้องพักหรือการเปลี่ยนระดับสมาชิกบัตรเครดิต
ทีมส่วนใหญ่ลงเอยด้วยการใช้ทั้ง 3 อย่าง และนั่นไม่ใช่ปัญหา builder สำหรับดีไซน์ journey สำหรับช่วงเวลาในวงจรชีวิตลูกค้า และ API สำหรับยอดคงเหลือและสถานะแบบเรียลไทม์ ความผิดพลาดคือการบังคับให้อย่างใดอย่างหนึ่งทำงานแทนอีก 2 อย่าง
ปรับบัตรทุกใบให้เป็นของแต่ละคนในวงกว้างด้วย Pushwoosh
Pushwoosh ให้ทั้ง visual builder ขั้นตอนใน journey และ API สำหรับ บัตร Apple Wallet และ Google Wallet แบบ native โดยไม่มีผู้ให้บริการบัตรแยกคั่นกลาง บัตรแต่ละใบใช้ User ID ร่วมกับ push, in-app, อีเมล, SMS และ LINE ข้อมูลชุดเดียวจึงขับเคลื่อนทุกช่องทาง
การปรับให้เป็นเฉพาะบุคคลในวงกว้างไม่ได้อยู่ที่จำนวนเทมเพลต แต่อยู่ที่ข้อมูลต้นทางชุดเดียวที่บัตรทุกใบในทุก wallet สะท้อนออกมา
คำถามที่พบบ่อย