วิธีการดักจับและตรวจสอบ Stripe Webhooks ใน CI ด้วย Apidog

เมื่อลูกค้าชำระเงิน Stripe จะส่งเหตุการณ์ payment_intent.succeeded ไปยังแบ็กเอนด์ของคุณ และเอนด์พอยต์ของคุณควรจะระบุว่าคำสั่งซื้อนั้นชำระเงินแล้ว ขั้นตอนสุดท้ายนี่เองที่มักจะล้มเหลวอย่างเงียบๆ เมื่อ webhook มาถึง ตัวแฮนเดอร์ของคุณเกิดข้อผิดพลาด และไม่มีใครสังเกตเห็นจนกว่าจะมีตั๋วสนับสนุนแจ้งว่า “ฉันชำระเงินแล้ว แต่บัญชีของฉันยังคงแสดงว่ายังไม่ได้ชำระ” คุณต้องการการทดสอบใน CI ที่พิสูจน์ว่าเหตุการณ์มาถึงและได้รับการจัดการอย่างถูกต้องทุกครั้งที่คุณปล่อยโค้ด

ส่วนที่ยุ่งยากคือ webhook เป็นการเรียก HTTP ขาเข้าจาก Stripe มายังคุณ ไม่ใช่คำขอที่คุณสร้างขึ้น เครื่องมือทดสอบ API ส่วนใหญ่สร้างมาเพื่อส่งคำขอและตรวจสอบการตอบกลับ ซึ่งเป็นรูปแบบที่ตรงกันข้าม ดังนั้นคำถามคือ: คุณจะยืนยันสิ่งที่มาถึงตามกำหนดเวลาของมันเอง ภายในการทำงานของ CI โดยไม่มีคนคอยดูได้อย่างไร? คู่มือนี้แสดงวิธีที่ตรงไปตรงมาและได้รับการสนับสนุนในการทำสิ่งนี้ด้วย Apidog และเริ่มต้นด้วยข้อจำกัดที่คุณต้องทราบล่วงหน้า หากคุณต้องการภาพรวมที่กว้างขึ้นของการทดสอบเอนด์พอยต์ที่ขับเคลื่อนด้วยเหตุการณ์ก่อน คู่มือของเราเกี่ยวกับ วิธีการทดสอบ webhooks จะเป็นตัวเริ่มต้น และ เอกสาร webhooks ของ Stripe เองก็ครอบคลุมโมเดลการส่งเหตุการณ์

ข้อจำกัดที่คุณต้องออกแบบให้รองรับ

นี่คือข้อเท็จจริงสำคัญที่ระบุไว้อย่างชัดเจนใน เอกสารของ Apidog: “ApiDog ไม่รองรับการรับฟัง webhooks โดยกำเนิด” Apidog ไม่ได้อยู่บน URL สาธารณะและดักจับการเรียกเข้าจาก Stripe แบบเรียลไทม์ หากคุณหวังที่จะชี้ Stripe ไปยังตัวรับฟังของ Apidog และดูเหตุการณ์เข้ามา ทางนั้นไม่มีอยู่จริง

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

รูปแบบการบันทึกแล้วสอบถามนั้นเป็นอย่างไร

รูปแบบที่เอกสารของ Apidog แนะนำมีสี่ส่วนประกอบ:

สร้างเอนด์พอยต์ในบริการแบ็กเอนด์ของคุณเพื่อบันทึก webhook ขาเข้าของ Stripe
จัดเก็บข้อมูลเหตุการณ์ webhook ในตาราง Stripe event logs ในฐานข้อมูลของคุณ
ใช้ Post-Request Processor ของ Apidog เพื่อสอบถามฐานข้อมูลของคุณ
ดึงข้อมูลเหตุการณ์ webhook ที่จัดเก็บไว้และตรวจสอบกับผลลัพธ์ที่คาดไว้

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

ขั้นตอนที่ 1: สร้างเอนด์พอยต์สำหรับการบันทึก

แบ็กเอนด์ของคุณต้องการเส้นทางที่ Stripe สามารถ POST ได้ นี่คือโค้ดแอปพลิเคชันธรรมดา ไม่ใช่คุณสมบัติของ Apidog ตัวจัดการ Express ขั้นต่ำที่ตรวจสอบลายเซ็นและบันทึกเหตุการณ์จะมีลักษณะดังนี้:

import express from "express";
import Stripe from "stripe";

const app = express();
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);
const endpointSecret = process.env.STRIPE_WEBHOOK_SECRET;

app.post(
  "/webhooks/stripe",
  express.raw({ type: "application/json" }),
  async (req, res) => {
    let event;
    try {
      event = stripe.webhooks.constructEvent(
        req.body,
        req.headers["stripe-signature"],
        endpointSecret
      );
    } catch (err) {
      return res.status(400).send(`Signature check failed: ${err.message}`);
    }

    // Persist the event so a test can read it back later.
    await db.query(
      `INSERT INTO stripe_event_logs (event_id, type, payload, handled_at)
       VALUES ($1, $2, $3, now())
       ON CONFLICT (event_id) DO NOTHING`,
      [event.id, event.type, JSON.stringify(event.data.object)]
    );

    if (event.type === "payment_intent.succeeded") {
      const intent = event.data.object;
      await markOrderPaid(intent.metadata.order_id);
    }

    res.json({ received: true });
  }
);

มีสองสิ่งสำคัญที่นี่ ประการแรก คุณตรวจสอบลายเซ็น Stripe ด้วย constructEvent ก่อนที่จะเชื่อถือสิ่งใดๆ ซึ่งเป็นขั้นตอนความปลอดภัยที่ต่อรองไม่ได้สำหรับตัวรับ webhook ใดๆ หากคุณต้องการเหตุผลทั้งหมดเบื้องหลังการตรวจสอบนั้น บทความของเราเกี่ยวกับ การยืนยันลายเซ็น webhook จะอธิบายว่าทำไมการเปรียบเทียบข้อมูลดิบเป็นวิธีที่ปลอดภัยเพียงวิธีเดียว ประการที่สอง คุณเขียนเหตุการณ์ลงในตาราง Stripe event logs แถวนั้นคือสิ่งที่ Apidog จะอ่าน ส่วน ON CONFLICT DO NOTHING จะทำให้การบันทึกเป็น idempotent เนื่องจาก Stripe สามารถส่งเหตุการณ์เดียวกันได้มากกว่าหนึ่งครั้ง

ขั้นตอนที่ 2: เชื่อมต่อฐานข้อมูลของคุณในสภาพแวดล้อม Apidog

Apidog รองรับการเชื่อมต่อกับฐานข้อมูลในสภาพแวดล้อมที่เกี่ยวข้อง และการเชื่อมต่อนั้นคือสิ่งที่ทำให้รูปแบบนี้ทั้งหมดทำงานได้ ตั้งค่าการเชื่อมต่อฐานข้อมูลสำหรับสภาพแวดล้อมที่ CI ของคุณกำหนดเป้าหมาย ไม่ว่าจะเป็น Postgres สำหรับ staging หรือฐานข้อมูลทดสอบเฉพาะ เมื่อการเชื่อมต่อพร้อมแล้ว ขั้นตอนการทดสอบสามารถรัน SQL กับมันและดึงแถวข้อมูลจริงกลับมาได้

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

ขั้นตอนที่ 3: เพิ่ม Post-Request Processor เพื่อสอบถามบันทึก

นี่คือหัวใจสำคัญ Post-Request Processor เป็นคุณสมบัติของ Apidog ที่สอบถามฐานข้อมูลของคุณและตรวจสอบเหตุการณ์ webhook ที่ถูกบันทึกไว้ภายในชุดทดสอบ คุณแนบมันเข้ากับคำขอในสถานการณ์ทดสอบของคุณ หลังจากคำขอทำงาน ตัวประมวลผลจะรัน SQL ของคุณ อ่านเหตุการณ์ที่จัดเก็บไว้ และให้คุณยืนยันผลลัพธ์ได้

ขั้นตอนที่เหมือนจริงสำหรับกรณี payment_intent.succeeded:

สถานการณ์ทดสอบของคุณเรียกใช้การชำระเงิน นั่นอาจเป็นคำขอที่สร้าง Payment Intent และยืนยันในโหมดทดสอบของ Stripe หรือข้อมูลจำลองที่ส่งเหตุการณ์ทดสอบที่รู้จักไปยังเอนด์พอยต์การบันทึกของคุณ
Stripe ส่ง webhook ไปยังเส้นทาง /webhooks/stripe ของคุณ ซึ่งจะตรวจสอบลายเซ็นและเขียนแถวลงใน stripe_event_logs
Post-Request Processor ในขั้นตอนถัดไปจะสอบถามตารางนั้นเพื่อหาเหตุการณ์

คำสั่ง SQL ที่ตัวประมวลผลรันเป็น SQL ธรรมดา:

SELECT event_id, type, payload, handled_at
FROM stripe_event_logs
WHERE type = 'payment_intent.succeeded'
ORDER BY handled_at DESC
LIMIT 1;

จากนั้นคุณจะยืนยันกับแถวที่ส่งคืน การทดสอบจะผ่านเมื่อข้อมูลที่บันทึกไว้ตรงกับความคาดหวังของคุณ: type เป็น payment_intent.succeeded, event_id ตรงกับที่คุณเรียกใช้, จำนวน payload เท่ากับที่คุณเรียกเก็บ และ handled_at ถูกเติมเต็ม ซึ่งพิสูจน์ว่าตัวแฮนเดอร์ของคุณทำงานจริง ไม่ใช่แค่แถวเป็นตัวยึดตำแหน่ง ดึงเหตุการณ์ webhook ที่จัดเก็บไว้ เปรียบเทียบกับผลลัพธ์ที่คาดไว้ และให้การยืนยันเป็นตัวตัดสินว่าผ่านหรือไม่ผ่าน

เนื่องจากเวลาในการส่ง webhook ไม่ใช่แบบทันที ให้เวลาเหตุการณ์สักครู่เพื่อมาถึงก่อนที่คุณจะสอบถาม ขั้นตอนการหน่วงเวลาสั้นๆ หรือการวนซ้ำแบบ polling ที่พยายามสอบถามซ้ำสองสามครั้งก่อนที่จะล้มเหลว จะช่วยป้องกันไม่ให้การทดสอบแข่งกับการส่งของ Stripe นี่เป็นจุดเดียวที่ลักษณะที่ไม่พร้อมกันของ webhooks รั่วไหลเข้ามาในการออกแบบการทดสอบของคุณ และหน้าต่างการลองใหม่ขนาดเล็กก็จัดการได้สะอาดตา

หมายเหตุเกี่ยวกับการส่งต่อแบบเรียลไทม์ระหว่างการพัฒนาในเครื่อง

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

สำหรับเรื่องนั้น เอกสารของ Apidog ชี้ไปที่บริการถ่ายทอด webhook โดยระบุ Stripe CLI และ Ngrok เป็นตัวอย่าง Stripe CLI สามารถรับฟังและส่งต่อเหตุการณ์ตรงไปยังพอร์ตท้องถิ่นของคุณได้:

stripe listen --forward-to localhost:3000/webhooks/stripe

นั่นทำให้คุณได้รับเหตุการณ์แบบสดๆ ในขณะที่คุณสร้างตัวจัดการ Ngrok ทำงานเดียวกันโดยเปิดเผยพอร์ตท้องถิ่นของคุณบน URL สาธารณะที่คุณลงทะเบียนเป็นเอนด์พอยต์ของ Stripe ใช้สิ่งเหล่านี้สำหรับการวนซ้ำการพัฒนาภายใน จากนั้นพึ่งพาฐานข้อมูลบวกกับการไหลของ Post-Request Processor สำหรับการยืนยันที่ทำงานในไปป์ไลน์ของคุณ ทั้งสองส่วนเสริมกัน: การถ่ายทอดสำหรับการสร้าง, การบันทึกแล้วสอบถามสำหรับการพิสูจน์

อย่าสับสนกับคุณสมบัติ Webhook ดั้งเดิมของ Apidog

Apidog มีคุณสมบัติที่เรียกว่า Webhook จริงๆ และเป็นเรื่องง่ายที่จะคิดว่านั่นคือวิธีที่คุณจะดักจับเหตุการณ์ Stripe แต่มันไม่ใช่ และการสับสนกันจะทำให้คุณเสียเวลาไปครึ่งบ่าย คุณสมบัติ Webhook ดั้งเดิมนี้มีไว้สำหรับกำหนดและจัดทำเอกสาร webhook ขาออก ซึ่งหมายถึงเอนด์พอยต์ HTTP ที่ระบบของคุณเรียกเมื่อเกิดเหตุการณ์ขึ้น ระบบจะเริ่มต้นการเรียกไปยัง URL ภายนอก ซึ่งตรงข้ามกับเอนด์พอยต์ปกติที่ไคลเอนต์เรียกคุณ มันถูกใช้เพื่ออธิบายการแจ้งเตือนการเปลี่ยนแปลงสถานะและผลลัพธ์ของงานแบบอะซิงโครนัสในเอกสาร API ของคุณ ไม่ใช่สำหรับการรับการเรียกเข้าจาก Stripe

หากคุณต้องการจัดทำเอกสาร webhook ขาออกของคุณเอง ขั้นตอนสั้นๆ มีดังนี้:

คลิกไอคอน + ในแถบด้านข้างซ้าย
เลือก New Other Protocol APIs จากนั้นเลือก Webhook
กรอกข้อมูลในช่องที่จำเป็น: Request Method (โดยทั่วไปคือ POST), Webhook Name, Debug URL ที่เป็นตัวเลือกสำหรับการทดสอบเท่านั้น และ Other Info สำหรับส่วนเนื้อหาคำขอ, ส่วนหัว และการกำหนดค่า
คลิก Save

ในการลองใช้ ให้ป้อน URL ในช่อง Debug URL แล้วคลิก Send เพื่อจำลองการเรียก webhook ข้อควรระวังที่ควรจำ: Debug URL ใช้สำหรับการทดสอบเท่านั้น และจะไม่ปรากฏในเอกสารที่เผยแพร่หรือการส่งออก OpenAPI ของคุณ สำหรับการจัดการที่สมบูรณ์ยิ่งขึ้นเกี่ยวกับการออกแบบและจัดทำเอกสารการเรียกกลับเหตุการณ์ บทความของเราเกี่ยวกับ webhooks ในการออกแบบ API ครอบคลุมถึงตำแหน่งที่เหมาะสม เวอร์ชันสั้นๆ สำหรับบทความนี้: คุณสมบัติ Webhook ดั้งเดิมกำหนดเหตุการณ์ขาออกของคุณ และรูปแบบการบันทึกแล้วสอบถามจะตรวจสอบเหตุการณ์ขาเข้าของ Stripe แยกสองสิ่งนี้ออกจากกันในความคิดของคุณให้ชัดเจน

การปรับปรุงและเสริมความแข็งแกร่ง

เมื่อการยืนยันพื้นฐานใช้งานได้แล้ว การปรับปรุงเล็กน้อยจะทำให้มันเป็นระดับ Production ประการแรก ให้ยืนยันมากกว่าประเภทเหตุการณ์ ตรวจสอบ event_id แบบ end-to-end เพื่อให้คุณรู้ว่าเหตุการณ์ที่คุณเรียกใช้คือเหตุการณ์ที่คุณตรวจสอบ ไม่ใช่เหตุการณ์ที่เหลือจากการรันครั้งก่อน ตัดทอนหรือจำกัดขอบเขตของตาราง stripe_event_logs ในแต่ละการรันทดสอบหากมีเหตุการณ์สะสมจำนวนมาก

ประการที่สอง ทดสอบเส้นทางที่ล้มเหลว ส่งเหตุการณ์ที่ตัวแฮนเดอร์ของคุณควรปฏิเสธ เช่น ลายเซ็นที่ไม่ถูกต้องหรือประเภทที่ไม่คาดคิด และยืนยันว่าจะไม่มีการเขียน timestamp handled_at ชุดทดสอบ webhook ที่ตรวจสอบเฉพาะเส้นทางที่สำเร็จเท่านั้นจะพลาดกรณีที่ทำให้คุณต้องตื่นตอนตี 2 จริงๆ หมายเหตุของเราเกี่ยวกับ แนวทางปฏิบัติที่ดีที่สุดสำหรับ payment webhook ครอบคลุมถึงพฤติกรรม idempotency และการลองใหม่ที่ควรใส่ไว้ในการทดสอบเหล่านี้

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

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

ทำให้เวิร์กโฟลว์เป็นไปโดยอัตโนมัติด้วย Apidog CLI

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

npm install -g apidog-cli
apidog login --with-token <YOUR_ACCESS_TOKEN>

จากนั้นรันสถานการณ์การตรวจสอบ webhook ที่บันทึกไว้ของคุณแบบ Headless กับสภาพแวดล้อมที่ฐานข้อมูลเก็บข้อมูลบันทึกเหตุการณ์ไว้:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t <SCENARIO_ID> -e <ENV_ID> -r cli

ที่นี่ -t คือรหัสสถานการณ์ทดสอบ, -e คือรหัสสภาพแวดล้อม และ -r เลือกผู้รายงาน ใช้ -r html,cli หากคุณต้องการรายงานที่สามารถเรียกดูได้ควบคู่ไปกับผลลัพธ์คอนโซลสำหรับสิ่งประดิษฐ์ CI ของคุณ สถานการณ์จะประกอบด้วย Post-Request Processor และการสอบถามฐานข้อมูล ดังนั้นคำสั่งเดียวจะเรียกใช้โฟลว์, อ่านแถว stripe_event_logs และส่งคืนรหัสออกที่ไม่ใช่ศูนย์หากการยืนยันล้มเหลว ซึ่งเป็นสิ่งที่ไปป์ไลน์ต้องการอย่างแท้จริงเพื่อป้องกันการรวมกัน คู่มือการติดตั้ง Apidog CLI ครอบคลุมการตั้งค่าโทเค็น และ บทแนะนำการใช้งาน CI/CD pipeline ของเราแสดงการเชื่อมต่อ GitHub Actions ทั้งหมดรอบๆ คำสั่งนี้

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

Apidog สามารถรับ Stripe webhook โดยตรงได้หรือไม่? ไม่ได้ เอกสารของ Apidog ระบุไว้อย่างชัดเจนว่า “ไม่รองรับการรับฟัง webhooks โดยกำเนิด” คุณต้องบันทึกเหตุการณ์ในเอนด์พอยต์แบ็กเอนด์ของคุณเอง จัดเก็บไว้ในฐานข้อมูล และ Apidog จะอ่านกลับมาด้วย Post-Request Processor สำหรับการส่งต่อแบบเรียลไทม์ระหว่างการพัฒนาในเครื่อง ให้ใช้บริการถ่ายทอดเช่น Stripe CLI หรือ Ngrok แทน

การยืนยันเกิดขึ้นที่ไหน? ภายในขั้นตอน Post-Request Processor บนคำขอในสถานการณ์ทดสอบของคุณ มันจะสอบถามตาราง Stripe event logs ของคุณผ่านการเชื่อมต่อฐานข้อมูลที่คุณกำหนดค่าไว้ในสภาพแวดล้อม ดึงเหตุการณ์ที่จัดเก็บไว้ และเปรียบเทียบกับค่าที่คุณคาดหวัง การทดสอบจะผ่านเมื่อข้อมูลที่บันทึกไว้ตรงกัน

ฉันจำเป็นต้องมีแผนแบบเสียเงินสำหรับเวิร์กโฟลว์การตรวจสอบฐานข้อมูลหรือไม่? เอกสารของ Apidog สำหรับเวิร์กโฟลว์นี้ไม่ได้ระบุถึงข้อจำกัดของแผนใดๆ ดังนั้นคู่มือนี้จะไม่ได้สร้างขึ้นมาเอง คำตอบที่ซื่อสัตย์คือให้ตรวจสอบรายละเอียดแผนปัจจุบันบนหน้าราคา คุณสามารถ ดาวน์โหลด Apidog และตั้งค่าโปรเจกต์ทดสอบเพื่อดู Post-Request Processor และการเชื่อมต่อฐานข้อมูลสภาพแวดล้อมด้วยตัวคุณเอง

ฉันจะจัดการกับการหน่วงเวลาระหว่างการเรียกใช้และการส่งอย่างไร? การส่ง webhook ไม่ได้เกิดขึ้นทันที ดังนั้นให้เพิ่มการรอสั้นๆ หรือการลองใหม่แบบ polling ก่อนการสอบถาม เพื่อให้การทดสอบของคุณไม่แข่งกับ Stripe การลองใหม่สองสามครั้งในช่วงสองสามวินาทีก็มักจะเพียงพอแล้ว หากคุณยังใหม่กับการยืนยันเอนด์พอยต์แบบอะซิงโครนัส ให้เริ่มต้นด้วยคู่มือทั่วไปเกี่ยวกับ วิธีการทดสอบ webhooks ก่อนที่จะลงรายละเอียดเฉพาะของ Stripe

คุณสมบัติ Webhook ดั้งเดิมมีประโยชน์ที่นี่บ้างไหม? ไม่ได้มีประโยชน์สำหรับการดักจับเหตุการณ์ Stripe คุณสมบัตินั้นใช้สำหรับกำหนดและจัดทำเอกสาร webhook ขาออกของคุณเอง ซึ่งระบบของคุณจะเรียกใช้ URL ภายนอก มันเป็นเครื่องมือสำหรับเอกสารและการออกแบบ ซึ่งแยกออกจากรูปแบบการบันทึกแล้วสอบถามขาเข้าที่บทความนี้ใช้ แยกสองสิ่งนี้ออกจากกันให้ชัดเจน

สรุป

คุณไม่สามารถชี้ Stripe ไปที่ Apidog และดักจับเหตุการณ์แบบสดๆ ได้ และการแสร้งทำเป็นว่าทำได้จะนำไปสู่ความผิดหวังในที่สุด วิธีการที่ได้รับการสนับสนุนนั้นสะอาดกว่าที่เห็นในตอนแรก: บันทึก webhook ในเอนด์พอยต์ของคุณเอง, บันทึกมันลงในตาราง Stripe event logs จากนั้นให้ Post-Request Processor ของ Apidog สอบถามบันทึกนั้นและยืนยันว่าเหตุการณ์ได้รับการจัดการ ห่อหุ้มสถานการณ์ที่บันทึกไว้ใน apidog run และไปป์ไลน์ของคุณจะพิสูจน์ได้ว่า ในทุกการรวมโค้ด เหตุการณ์การชำระเงินจริงทำให้คำสั่งซื้อของคุณเปลี่ยนเป็นชำระเงินแล้ว ลองใช้ฟรี ไม่ต้องใช้บัตรเครดิต และใส่การยืนยันจริงเบื้องหลัง webhook ที่สำคัญที่สุด