สกุลเงินและการตั้งราคาบนเว็บไซต์แบรนด์: แสดงหลายสกุลเงิน อัปเดตอัตราแลกเปลี่ยน คำนวณภาษี และการชำระเงิน
1. กับดักทางเทคนิค 3 ข้อของการแสดงหลายสกุลเงิน
กับดักข้อแรก: หน้าร้านใช้ JavaScript เรียก API อัตราแลกเปลี่ยนแบบเรียลไทม์เพื่อแปลงค่า ราคาที่ผู้ซื้อเห็นตอนเปิดหน้าคืออัตราแลกเปลี่ยน ณ ขณะนั้น แต่พอเขาหยิบสินค้าใส่ตะกร้า กรอกที่อยู่จนถึงขั้นชำระเงิน อัตราแลกเปลี่ยนเปลี่ยนไปแล้ว ราคาตอนชำระกับราคาที่แสดงจึงไม่ตรงกัน เว็บ B2C อัตราการคืนสินค้าจึงสูงขึ้น ส่วนเว็บ B2B ผู้ซื้อทิ้งตะกร้าแล้วไปขอใบเสนอราคาแทน
กับดักข้อที่สอง: ทำแค่การแสดงหลายสกุลเงิน แต่ไม่ทำภาษีให้ตรงท้องถิ่น ผู้ซื้อในสหภาพยุโรปคุ้นเคยกับราคาที่รวมภาษีแล้ว (MwSt. inkl.) ส่วนผู้ซื้อในสหรัฐฯ คุ้นเคยกับราคาก่อนภาษีบวกภาษีขายโดยประมาณ ถ้าคุณแสดงราคาก่อนภาษีให้ผู้ใช้ในสหภาพยุโรป เขาจะคิดว่าต้องบวกภาษีอีก 20% แล้วจากไปทันที กับดักข้อที่สาม: เว็บไซต์แบบ B2B ที่รับใบเสนอราคาแต่ฝืนต่อระบบชำระเงินออนไลน์ คำสั่งซื้อ B2B ปกติมีมูลค่าสูง ต้องขอใบเสนอราคา ต้องมีเครดิตเทอม ช่องทางชำระเงินออนไลน์รองรับไม่ได้ ฝืนต่อกลับเพิ่มความเสี่ยงการปฏิเสธการชำระเงิน ดูการพูดคุยเรื่องกลยุทธ์การตั้งราคาได้ที่การตั้งราคาสำหรับตลาดต่างประเทศ: จากบวกกำไรบนต้นทุนสู่การตั้งราคาตามคุณค่า。
| กับดักทางเทคนิค | ผลลัพธ์ที่ตามมา | วิธีที่ถูกต้อง |
|---|---|---|
| หน้าร้านใช้ JS แปลงค่าอัตราแลกเปลี่ยนแบบเรียลไทม์ | ราคาที่แสดงกับราคาตอนชำระต่างกันเกิน 1% | ดึงข้อมูลวันละครั้ง หน้าร้านและหลังบ้านใช้ชุดเดียวกัน |
| เปลี่ยนแค่สกุลเงิน ไม่เปลี่ยนภาษี | ผู้ซื้อในสหภาพยุโรปคิดว่าต้องบวกภาษี 20% | แสดงตามภาษีรวมหรือก่อนภาษีของประเทศปลายทาง |
| เว็บ B2B ฝืนต่อระบบชำระเงินออนไลน์ | คำสั่งซื้อมูลค่าสูงเสี่ยงถูกปฏิเสธการชำระเงิน | หลายสกุลเงินแค่แสดงผล ให้ยื่นขอใบเสนอราคา |
| ใช้อัตราแลกเปลี่ยนทันทีของร้านค้า | สูงกว่าอัตราธนาคารกลาง 3% ถึง 5% | ใช้ราคากลางธนาคารกลางบวกบัฟเฟอร์ 1% ถึง 2% |
| ไม่มีตัวเลือกสลับสกุลเงินด้วยตัวเอง | ผู้ใช้ VPN เห็นสกุลเงินผิด | เพิ่มตัวเลือกสกุลเงินที่ส่วนท้าย ตั้งค่าเริ่มต้นตาม IP |
2. จังหวะอัปเดตอัตราแลกเปลี่ยน: วันละครั้ง ไม่ต้องเรียลไทม์
ความถี่ในการอัปเดตอัตราแลกเปลี่ยนสำหรับการแสดงหลายสกุลเงิน เว็บไซต์แบรนด์ B2B แนะนำให้ทำวันละครั้ง ดึงข้อมูลเป็นชุดตอน 0 นาฬิกา UTC แล้วเขียนลงแคชฐานข้อมูลไว้ทั้งวัน ไม่ควรเรียก API อัตราแลกเปลี่ยนแบบเรียลไทม์ที่หน้าเว็บ เหตุผลมีสามข้อ: หนึ่ง การเรียกแบบเรียลไทม์เพิ่มความหน่วงในการโหลดหน้าเว็บ กระทบ Core Web Vitals ตัวชี้วัด สอง API อัตราแลกเปลี่ยนมีข้อจำกัดจำนวนครั้งในการเรียก การเรียกแบบเรียลไทม์มีต้นทุนสูง สาม การแปลงค่าแบบเรียลไทม์ทำให้ราคาที่แสดงกับราคาตอนชำระคลาดเคลื่อน
แนะนำแหล่งอัตราแลกเปลี่ยน 3 แหล่ง: อัตราอ้างอิงรายวันของธนาคารกลางยุโรป (ฟรี เสถียร), XE API (โควตาฟรีพอสำหรับเว็บเล็ก), Open Exchange Rates (เวอร์ชันฟรี 1,000 ครั้งต่อเดือน) แนะนำให้บวก buffer 1% ถึง 2% เข้าไปในอัตราแคช เพราะอัตราที่ช่องทางชำระเงินใช้ตัดบัญชีจริงจะสูงกว่าอัตรากลางของธนาคารกลางเล็กน้อย การจัดการความผันผวนของอัตราแลกเปลี่ยนในระดับใบเสนอราคา B2B ดูที่การบริหารความผันผวนของอัตราแลกเปลี่ยน บทความนี้พูดถึงเฉพาะการแสดงผลหน้าร้านเท่านั้น
| แนวทางอัตราแลกเปลี่ยน | ความถี่ในการอัปเดต | เหมาะกับ | ต้นทุน |
|---|---|---|---|
| อัตราอ้างอิงธนาคารกลางยุโรป | วันละครั้ง | เว็บ B2B ที่เน้นยุโรป | ฟรี |
| XE API | วันละครั้ง | เว็บ B2B หลายสกุลเงิน | โควตาฟรีพอสำหรับเว็บเล็ก |
| Open Exchange Rates | ทุกชั่วโมง | เว็บ B2C ที่อัปเดตบ่อย | เวอร์ชันฟรี 1,000 ครั้งต่อเดือน |
| Stripe แปลงอัตโนมัติ | เรียลไทม์ตอนชำระเงิน | ออร์เดอร์ B2C มูลค่าน้อยล้วน | Stripe คิดตามสกุลเงินบนบัตร |
สาม、การคำนวณภาษี: ตามประเทศปลายทาง ไม่ใช่ตามที่ตั้งคลังสินค้า
กฎหลักของการคำนวณภาษีคือคิดตามประเทศปลายทาง ไม่ใช่ตามที่ตั้งคลังสินค้า ลูกค้าเยอรมันซื้อสินค้าของคุณ ไม่ว่าคุณจะส่งตรงจากจีนหรือส่งจากคลังใน EU หน้าร้านเยอรมันต้องแสดงราคาที่รวม MwSt 19% แล้ว ลูกค้าอเมริกันซื้อสินค้า ให้แสดงราคาก่อนภาษี แล้วตอนชำระเงินจึงบวกภาษีขายตามอัตราของรัฐที่เขาอยู่ กฎนี้เรียกว่าหลักแหล่งปลายทาง (destination principle) ทั้งกฎ VAT ของ EU และกฎภาษีขายของสหรัฐฯ ต่างก็ใช้หลักนี้
ตัวอย่างสถานการณ์: บริษัทส่งออกเซ็นเซอร์อุตสาหกรรมแห่งหนึ่ง หน้าร้านแสดงราคาก่อนภาษีเป็น USD โดยค่าเริ่มต้น ลูกค้าเยอรมันเปิดหน้าเว็บ เห็นเซ็นเซอร์ราคา $100 เขาจะบวก VAT เยอรมัน 19% ไว้ในใจ คิดเป็น 119 ดอลลาร์ ถ้าเว็บไม่ได้ทำ localization ด้านภาษี เขาจะรู้สึกว่าราคาไม่โปร่งใส และส่ง inquiry มาถามตรงๆ ว่า “including VAT?” วิธีที่ถูกต้องคือ: เมื่อเข้าจาก IP เยอรมัน ให้สลับเป็นราคา EUR ที่รวมภาษีอัตโนมัติ แสดง “€109.90 inkl. MwSt” เมื่อเข้าจาก IP สหรัฐฯ ให้แสดง “$99.00 + sales tax” ความน่าเชื่อถือของฟอร์ม inquiry ดูที่ความน่าเชื่อถือของฟอร์มสอบถาม。
| ภูมิภาค | วิธีแสดงราคา | การจัดการภาษี | อัตราภาษีทั่วไป |
|---|---|---|---|
| EU (เยอรมนี) | ราคา EUR รวมภาษี | รวม MwSt แล้ว ไม่บวกเพิ่ม | 19% (มาตรฐาน)/7% (ลดหย่อน) |
| EU (ฝรั่งเศส) | ราคา EUR รวมภาษี | รวม TVA | 20% |
| สหรัฐอเมริกา | ราคา USD ก่อนภาษี | บวกภาษีขายตามรัฐตอนชำระเงิน | 0% ถึง 10% แตกต่างกันในแต่ละรัฐ |
| สหราชอาณาจักร | ราคา GBP รวมภาษี | รวม VAT | 20% |
| ญี่ปุ่น | ราคา JPY รวมภาษี | รวมภาษีบริโภค | 10% |
สี่、การชำระเงิน: รับเป็นสกุลเงินหลัก จ่ายตามสกุลเงินบนบัตร
การตั้งราคาหลายสกุลเงินกับการชำระเงินเป็นคนละเรื่องกัน ระดับการตั้งราคา: หน้าร้านแสดงราคาเป็นสกุลเงินท้องถิ่นของผู้ซื้อ ให้เขามองเห็นภาพรวม ระดับการชำระเงิน: ในฐานะผู้ขาย สุดท้ายคุณยังต้องรับเงินเป็นสกุลเงินหลักของคุณ (ปกติคือ USD หรือ CNY) การแปลงสกุลเงินตรงกลางให้ช่องทางชำระเงินจัดการ อย่าทำ logic แปลงสกุลเงินเองบนเว็บไซต์
สถาปัตยกรรมที่แนะนำ: ผู้ซื้อเห็นราคา EUR รวม VAT ตอนชำระเงินเลือก Stripe โดย Stripe จะหักตามสกุลเงินของบัตร (บัตรยูโรหักเป็นยูโร บัตรดอลลาร์หักเป็นดอลลาร์ตามอัตราแลกเปลี่ยนขณะนั้น) ตอน settle Stripe จะแปลงเงินเป็นสกุลเงินหลักของคุณแล้วโอนเข้าบัญชีธนาคาร คุณจึงดูแลราคาแค่สกุลเงินหลักชุดเดียว หน้าร้านแสดงผลด้วยอัตราแลกเปลี่ยนที่แคชไว้ ส่วนการ settle ใช้ payment gateway อย่าเขียนระบบแปลงสกุลเงินเองใน backend เพราะดูแลยากและผิดพลาดง่าย ดูการเลือก payment gateway และเปรียบเทียบค่าธรรมเนียมได้ที่ความน่าเชื่อถือของฟอร์มสอบถาม บทความเกี่ยวกับการชำระเงินในเว็บเดียวกัน
| ขั้นตอน | สกุลเงิน | แหล่งอัตราแลกเปลี่ยน | ข้อควรระวัง |
|---|---|---|---|
| การแสดงผลหน้าร้าน | สกุลเงินของผู้ซื้อ | อัตราแลกเปลี่ยนธนาคารกลางที่แคชรายวัน | บวก buffer ร้านค้า 1% ถึง 2% |
| เพิ่มลงตะกร้า | สกุลเงินของผู้ซื้อ | ใช้แคชเดียวกับหน้าร้าน | ล็อกภายใน session ไม่คลาดเคลื่อน |
| การหักเงินตอนชำระ | สกุลเงินของเจ้าของบัตร | อัตราแลกเปลี่ยนเรียลไทม์ของ Stripe/PayPal | แจ้งผู้ซื้อว่าจะคิดตามอัตรานี้ |
| การ settle ของผู้ขาย | สกุลเงินหลัก (USD/CNY) | อัตราแลกเปลี่ยนตอน settle ของ payment gateway | มีส่วนต่างอัตราแลกเปลี่ยน 1% ถึง 3% |
ห้า กลยุทธ์หลายสกุลเงินสำหรับเว็บ B2B แบบรับ inquiry
กลยุทธ์หลายสกุลเงินของเว็บ B2B และเว็บอีคอมเมิร์ซ B2C ต่างกันโดยสิ้นเชิง คำสั่งซื้อ B2B มีมูลค่าสูง (ปกติหลายพันถึงหลายแสนดอลลาร์สหรัฐ) ต้องมีใบเสนอราคา ต้องมีเครดิตเทอม ต้องตั้งราคาตามขั้นบันไดปริมาณ payment gateway ออนไลน์จัดการสถานการณ์แบบนี้ไม่ได้ ดังนั้นเว็บ B2B จึงทำเรื่องเดียวในเรื่องหลายสกุลเงิน: ให้ผู้ซื้อเห็นราคาในสกุลเงินที่คุ้นเคย ลดต้นทุนการสื่อสาร แล้วชักชวนให้ส่ง inquiry
วิธีทำ: หน้าร้านสลับสกุลเงินที่แสดงอัตโนมัติตาม IP ด้านล่างเพิ่มตัวเลือกสกุลเงินแบบ manual (USD/EUR/GBP/JPY/AUD) แปลงราคาด้วยอัตราแลกเปลี่ยนที่แคชรายวัน ข้างราคาที่แสดงกำกับว่า “Reference price, final quote in USD” ในฟอร์ม inquiry เพิ่ม dropdown “Preferred currency” ให้ผู้ซื้อเลือกสกุลเงินที่ต้องการให้เสนอราคา ดูคำมั่นเรื่องกำหนดส่งและหลักการเสนอราคาได้ที่คำมั่นกำหนดส่งมอบ。
| ประเภทเว็บไซต์ | วิธีทำหลายสกุลเงิน | วิธีชำระเงิน | การอัปเดตอัตราแลกเปลี่ยน |
|---|---|---|---|
| เว็บอีคอมเมิร์ซ B2C | แสดงและชำระเงินครบขั้นตอน | ชำระออนไลน์ผ่าน Stripe/PayPal | ทุกชั่วโมงหรือรายวัน |
| เว็บ B2B แบบรับ inquiry | แสดงอย่างเดียว ไม่ settle | ชักชวนให้ส่ง inquiry ใช้ T/T | วันละครั้ง |
| เว็บแบบผสม | SKU ขายปลีกจ่ายออนไลน์ รายการใหญ่ส่ง inquiry | แยกตามจำนวนเงินอัตโนมัติ | วันละครั้ง |
FAQ คำถามที่พบบ่อย
ราคาที่แสดงหน้าร้านกับราคาตอนชำระต่างกันแค่ไหนถือว่าปกติ?
ควรอัปเดตอัตราแลกเปลี่ยนบ่อยแค่ไหน?
จะแสดง VAT ของ EU บนเว็บไซต์อย่างไร?
เว็บไซต์ B2B แบบแบรนด์ตัวเองควรรับชำระเงินออนไลน์ไหม?
การชำระเงินหลายสกุลของ Stripe กับ PayPal ต่างกันอย่างไร
แคชอัตราแลกเปลี่ยนควรบวกบัฟเฟอร์ร้านค้าไหม บวกเท่าไร
ทิ้งท้าย
แก่นแท้ทางเทคนิคของราคาหลายสกุลเงินไม่ใช่การแลกเปลี่ยนเงิน แต่คือความสม่ำเสมอ ราคาที่เห็นหน้าร้าน ราคาในตะกร้า และราคาตอนชำระเงิน ต้องใช้ชุดอัตราแลกเปลี่ยนเดียวกัน การแปลงแบบเรียลไทม์ดูทันสมัย แต่จริง ๆ แล้วยกภาระราคาเคลื่อนให้ผู้ซื้อ สุดท้ายกลายเป็นอัตราการคืนสินค้าและอัตราการทิ้งตะกร้า
ลงมือสามขั้น ขั้นแรก ดึงอัตราแลกเปลี่ยนจากธนาคารกลางวันละครั้งตามเวลาที่กำหนด แล้วแคชลงฐานข้อมูล ขั้นที่สอง แสดงราคาแบบรวมภาษีหรือก่อนภาษีตามประเทศปลายทาง EU รวมภาษี สหรัฐก่อนภาษี ขั้นที่สาม เว็บ B2B ให้หลายสกุลเงินเพียงแสดงผลไม่ชำระบัญชี ชักชวนให้ส่ง inquiry ส่วนเว็บ B2C ใช้ Stripe ชำระตามสกุลเงินของบัตร อย่าเขียนตรรกะแลกเปลี่ยนเงินเอง
ประโยคเดียวที่จำได้ ราคาหลายสกุลเงินไม่ใช่ให้เว็บไซต์แลกเงินให้คุณ แต่ให้ผู้ซื้อเห็นราคาที่ไม่เปลี่ยนในสกุลเงินที่เขาคุ้นเคย