# บันทึกการเปลี่ยนแปลง

## กันยายน 2026

### 10 กันยายน

**ฟอร์ม HTML ส่งเป็นคอนเทนเนอร์ที่เซ็นแล้ว** แทนที่ฟิลด์ใบแจ้งหนี้แยกรายฟิลด์ — `data` (base64url ของ JSON) และ `signature` (HMAC-SHA256 ของสตริง `data`) endpoint เปลี่ยนจาก `invoices/createFromForm` เป็น `invoices/form` ฟอร์มแบบเก่าใช้ไม่ได้อีกต่อไปและต้องสร้างใหม่: ดู[ลายเซ็นฟอร์ม HTML](./creating-invoices/html-forms/form-signature.md)

### 8 กันยายน

**ฟิลด์ตัวเลขในเนื้อหา webhook เป็นตัวเลขแล้ว** หกฟิลด์ที่เคยส่งเป็นสตริงถูกส่งเป็นตัวเลขแล้ว: `project.commissionRate`, `invoice.commissionFiatUSD`, `invoice.amountFiatUSD`, `invoice.amountFiat`, `invoice.calcAmountFiat`, `payment.amount` ชุดฟิลด์ ชื่อ และลำดับไม่เปลี่ยนแปลง

พึงระลึกไว้: ศูนย์ท้ายถูกตัดออก ดังนั้นจำนวน 10.00 มาถึงเป็น 10 จำนวนที่ต่ำกว่า 0.0001 มาถึงในสัญกรณ์เลขชี้กำลัง เช่น 1.0e-6 — การแยกวิเคราะห์ JSON มาตรฐานคืนตัวเลขที่ถูกต้อง มีเพียงการแยกสตริงด้วยตนเองเท่านั้นที่พัง

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

### 6 กันยายน

**ฟิลด์ตัวเลขในการตอบกลับของ API เป็นตัวเลขแล้ว** มีผลกับ `invoices/list`, `payments/list` และ `invoices/create`

| ฟิลด์ | ก่อน | หลัง |
| --- | --- | --- |
| `commissionFiatUSD` | `"0.10"` | `0.1` |
| `amountFiatUSD` | `"10.00"` | `10` |
| `amountFiat` | `"1000.00"` | `1000` |
| `views` | `"0"` | `0` |
| `payment.amount` | `"10.500000000"` | `10.5` |

**คีย์ที่จำกัดไว้กับโปรเจกต์บังคับใช้ข้อจำกัดในทุกเมธอดแล้ว** ก่อนหน้านี้บางเมธอดไม่สนใจโปรเจกต์ ตอนนี้มันเป็นตัวกรองในเมธอดแสดงรายการ และคำขอใบแจ้งหนี้หรือกระเป๋าเงินของโปรเจกต์อื่นถูกปฏิเสธด้วย `Restricted project` เมธอดที่ไม่สามารถปฏิบัติตามข้อจำกัดโปรเจกต์ได้จะถูกปิดสำหรับคีย์แบบนั้น รายละเอียดอยู่ในส่วน “ขอบเขตของคีย์”

**รายการการชำระเงินคืนการชำระเงินที่ยังไม่ได้จับคู่ด้วยแล้ว** ก่อนหน้านี้ `payments/list` คืนเฉพาะการชำระเงินที่ผูกกับใบแจ้งหนี้ ตอนนี้ผลลัพธ์รวมการชำระเงินทั้งหมดจากกระเป๋าเงินของคุณ โดยรายการที่ยังไม่ได้จับคู่จะไม่มีบล็อก `invoice` เหล่านี้คือการชำระเงินที่ต้องใช้สำหรับการจับคู่ด้วยตนเองผ่าน `invoices/bindPayment` พอดี

**การยกเลิกใบแจ้งหนี้แยกแยะสาเหตุการปฏิเสธแล้ว** ก่อนหน้านี้ทั้งกรณีไม่มีใบแจ้งหนี้และกรณีไม่เข้าเงื่อนไขคืน `Invoice not found` แบบเดียวกัน ตอนนี้ `Invoice not found` หมายถึงใบแจ้งหนี้ไม่มีอยู่เท่านั้น ส่วนกรณีไม่เข้าเงื่อนไขคืน `Invoice cannot be canceled`

**ตัวระบุที่ผิดรูปแบบถูกปฏิเสธแล้ว** `invoices/list` ตรวจสอบ `invoiceId`, `invoiceUid` และ `projectId` ส่วน `payments/list` — `walletId` และ `invoiceId` ค่าที่ไม่ถูกต้องคืน `Parameter is filled in incorrectly` พร้อมชื่อฟิลด์ ก่อนหน้านี้พารามิเตอร์แบบนั้นถูกละทิ้งเงียบ ๆ และผลลัพธ์กลับมาโดยไม่ถูกกรอง

**ขอบเขตช่วงเวลารวมทั้งวันที่ระบุแล้ว** `startDate` และ `endDate` ถูกตีความตั้งแต่ `00:00:00` ถึง `23:59:59` ก่อนหน้านี้วันสุดท้ายถูกตัดออกทั้งวัน และการค้นหาช่วงหนึ่งวันคืนเฉพาะระเบียนที่สร้างตอนเที่ยงคืนพอดี มีผลกับ `invoices/list`, `payments/list`, `statistics/invoices` และ `statistics/payments`

**เพิ่มฟิลด์โปรเจกต์ในประวัติยอดคงเหลือ** ทุกการดำเนินการในเมธอด `billing/history` มีฟิลด์ `projectId` แล้ว สำหรับการดำเนินการระดับบัญชี — การเติมเงินและโบนัส — ค่าจะเป็น `null`

### 4 กันยายน

**คำอธิบายและข้อมูลฝั่งบริการถูกส่งกลับในรูปแบบดั้งเดิม** ฟิลด์ `description` และ `serviceData` เคยถูกเก็บแบบเข้ารหัส และในการตอบกลับของ API เครื่องหมายคำพูดมาถึงเป็น `&quot;` ส่วนเครื่องหมายน้อยกว่าเป็น `<` ตอนนี้ค่าที่ส่งกลับคือสิ่งที่ร้านค้าส่งไว้ทุกประการ เมื่อเรนเดอร์ใน HTML ให้ escape ค่าที่ฝั่งคุณเอง

**ฟอร์ม HTML ยอมรับเฉพาะ POST** การสร้างใบแจ้งหนี้โดยเปิดลิงก์ที่มีพารามิเตอร์ในแถบที่อยู่ใช้ไม่ได้อีกต่อไป — พารามิเตอร์ถูกอ่านจากเนื้อหาคำขอเท่านั้น หากคุณเคยใช้ลิงก์ ให้แทนที่ด้วยฟอร์มที่มี `method="post"`

### 3 กันยายน

**การแจ้งเตือน webhook ถูกเซ็นแล้ว** เพิ่ม header `X-Timestamp` และ `X-Signature` โดยลายเซ็นคำนวณด้วย HMAC-SHA256 จากคีย์ลับของ Webhook การตรวจสอบลายเซ็นช่วยแยกการแจ้งเตือนของจริงออกจากของปลอม กลไกและตัวอย่างอยู่ในส่วน “การตรวจสอบลายเซ็น Webhook”

การเปลี่ยนแปลงนี้เข้ากันได้ย้อนหลัง: หากคุณไม่เพิ่มการตรวจสอบ ตัวจัดการของคุณยังทำงานเหมือนเดิม