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

งานBuilderAPIขั้นตอนใน journey
ออกแบบเทมเพลตได้ได้ไม่ได้
ออกบัตรให้ลูกค้า 1 คนได้ได้ได้
ออกบัตรหลายพันใบ แต่ละใบมีค่าของตัวเองไม่ได้ได้ได้
อัปเดตแบบเรียลไทม์จาก POS หรือระบบจองไม่ได้ได้ไม่ได้
เลือก 10 สาขาที่ใกล้ลูกค้าแต่ละคนที่สุดไม่ได้ได้ไม่ได้

ดูคอลัมน์ journey ก่อนเขียนโค้ดบรรทัดแรก ถ้า trigger คือการกระทำของลูกค้าที่ Pushwoosh ติดตามอยู่แล้ว ขั้นตอน Issue Wallet Pass ใน Customer Journey มักทำให้ไม่ต้องเขียนโค้ดเองเลย

เทมเพลตและค่าเฉพาะบุคคล

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

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

ฟิลด์ของบัตรสะสมแต้มใน Google Wallet pass builder ของ Pushwoosh พร้อมหน้าต่าง Insert a tag สำหรับเติมค่าเฉพาะบุคคล

ใน journey ขั้นตอน Issue Wallet Pass รับแคมเปญบัตร Apple และ Google (apple_campaign_id, google_campaign_id) และ personal_values ที่จะเติม ขั้นตอนเดียวออกบัตรได้ทั้ง 2 เวอร์ชันให้ User ID เดียวกัน

หน้า canvas ของ Customer Journey ใน Pushwoosh ที่มีขั้นตอน Issue wallet pass อยู่ในรายการช่องทาง

ขั้นตอนฝั่ง 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

See Pushwoosh in action
Request a demo

อัปเดตในวงกว้าง

การอัปเดตคือจุดที่ API คุ้มค่าที่สุด บัญชีแต้มสะสมหรือระบบจองอัปเดตบัตรได้ทันทีที่ค่าเปลี่ยน บัตรใน wallet ของลูกค้าจึงตรงกับข้อมูลต้นทางของคุณเสมอ ซึ่งสำคัญมากในช่วงที่ยอดพุ่งอย่างสงกรานต์หรือ 11.11

3 กฎที่ทำให้การอัปเดตจำนวนมากปลอดภัย:

  • เริ่มจากบัตรปัจจุบัน การอัปเดตของ Apple รับ pass object ทั้งก้อน จึงต้องดึงบัตรมาก่อนแล้วเปลี่ยนเฉพาะค่าที่ขยับ ส่วนการอัปเดตของ Google เป็นการ patch object
  • ตัดสินใจเรื่องการแจ้งเตือนทีละฟิลด์ บน Apple เฉพาะฟิลด์ที่มี change message เท่านั้นที่แสดงการแจ้งเตือนบนหน้าจอล็อก บน Google notifyOnUpdate ขอให้ Google ส่งการแจ้งเตือนของตัวเอง ซึ่งทำงานเฉพาะบัตรสะสมแต้ม บัตรอีเวนต์ และบัตรเที่ยวบิน ไม่เกิน 3 ครั้งต่อบัตรใน 24 ชั่วโมง ส่วน notifyMessage ส่งข้อความแจ้งเตือน Android ของคุณเองได้กับบัตรทุกประเภท
  • ให้การแจ้งเตือนเป็นเรื่องของบัตร Apple และ Google อนุญาตการแจ้งเตือนเกี่ยวกับบัตร ไม่ใช่โปรโมชัน

ตัวอย่างโค้ด

ทั้ง 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 สะท้อนออกมา

นัดเดโม Wallet passes
นัดเดโม Wallet passes

คำถามที่พบบ่อย


Pushwoosh Team
Content Team ที่ Pushwoosh
แชร์

บทความที่เกี่ยวข้อง

ดูทั้งหมด