End-User Hosted Checkout (Merchant-Integrated)การชำระเงินผ่านหน้าเช็คเอาต์ของร้านค้า (สำหรับลูกค้า)
The end customer of a partner business, paying through a hosted checkout. This is what a partner business's customer sees — never the P2P app itself. A merchant like Siam Digital Wallet embeds P2P behind a single link: it mints a short-lived, signed checkout URL for one of its own users and hands it to them (in an app screen, a chat message, an email — anywhere). Opening that link drops the customer straight into a small, branded checkout flow that verifies the link, checks their standing consent to let this merchant route money on their behalf, and walks them through a deposit or a withdrawal in a handful of taps. The platform still never holds their money — P2P only matches, verifies, and records the ledger entry; every transfer is bank-to-bank, and the merchant is who the customer is dealing with, not P2P. A deposit can reach the platform by three different routes - paid into a merchant bank account, matched directly against another customer who is withdrawing the same amount, or paid through a payment gateway by QR - and all three are shown below. The customer never chooses between them and is never asked to: the route is decided after they confirm, and the only one that changes what they have to DO is the gateway, which needs no payment slip at all.ลูกค้าปลายทางของร้านค้าพันธมิตร ที่ชำระเงินผ่านหน้าเช็คเอาต์ นี่คือสิ่งที่ลูกค้าของธุรกิจพาร์ตเนอร์เห็น — ไม่ใช่แอป P2P โดยตรง ร้านค้าอย่าง Siam Digital Wallet ฝัง P2P ไว้หลังลิงก์เดียว โดยสร้าง URL สำหรับชำระเงินที่ลงลายเซ็นและมีอายุสั้น ให้กับผู้ใช้รายหนึ่งของตนเอง แล้วส่งลิงก์นั้นให้ลูกค้า (ในหน้าจอแอป ข้อความแชท อีเมล หรือช่องทางใดก็ได้) เมื่อเปิดลิงก์ ลูกค้าจะเข้าสู่ขั้นตอนชำระเงินสั้น ๆ ที่มีแบรนด์ของร้านค้า ระบบจะตรวจสอบลิงก์ ตรวจความยินยอมที่ลูกค้าให้ไว้กับร้านค้านี้ในการจัดการเงินแทน แล้วพาทำรายการฝากหรือถอนให้จบภายในไม่กี่ครั้งที่กด แพลตฟอร์มยังคงไม่ถือเงินของลูกค้า — P2P ทำหน้าที่จับคู่ ตรวจสอบ และบันทึกรายการบัญชีเท่านั้น ทุกการโอนเป็นแบบธนาคารถึงธนาคาร และคู่สัญญาของลูกค้าคือร้านค้า ไม่ใช่ P2P การฝากเงินเข้าสู่แพลตฟอร์มทำได้สามเส้นทาง คือ โอนเข้าบัญชีธนาคารของร้านค้า จับคู่โดยตรงกับลูกค้าอีกคนที่กำลังถอนเงินจำนวนเท่ากัน หรือชำระผ่านเพย์เมนต์เกตเวย์ด้วย QR ซึ่งแสดงไว้ทั้งสามเส้นทางด้านล่าง ลูกค้าไม่ได้เลือกเส้นทางเอง และไม่เคยถูกถามให้เลือก เพราะเส้นทางถูกกำหนดหลังจากลูกค้ากดยืนยันแล้ว และเส้นทางเดียวที่เปลี่ยนสิ่งที่ลูกค้าต้องทำคือเกตเวย์ ซึ่งไม่ต้องใช้สลิปการโอนเลย
This Thai text is an unreviewed draft. A native reviewer should read it before it is published outside the team.
Paying in — by bank transferฝากเงิน — โอนเข้าบัญชีธนาคาร
The baseline. Transfer to the account shown, quote the reference, upload the slip. Read this one first — the other two routes differ from it in only one respect each.เส้นทางพื้นฐาน โอนไปยังบัญชีที่แสดง ใส่รหัสอ้างอิง แล้วอัปโหลดสลิป อ่านหัวข้อนี้ก่อน — อีกสองเส้นทางต่างจากนี้เพียงอย่างละหนึ่งเท่านั้น
Step 1ขั้นตอนที่ 1
Deposit (bank transfer) - arrival & confirmฝากเงิน (โอนผ่านธนาคาร) - เข้าสู่หน้าจอและยืนยัน
The merchant hands the customer a one-time checkout link. Opening it verifies the signed token, confirms the customer's standing consent for this merchant to route deposits on their behalf, authenticates them, and consumes the link's single-use nonce - all before this screen renders. What the customer sees is this confirm card: the amount and the merchant's name shown non-collapsibly (PDPA S27) before they can tap anything, plus the disclaimer that confirming authorises the merchant to credit this amount into its own system once the transfer is verified. Nothing here tells the customer which of the three payment routes they are about to get, and deliberately so - the route is decided after they confirm, and it is the platform's problem, not theirs.ร้านค้าส่งลิงก์ชำระเงินแบบใช้ครั้งเดียวให้ลูกค้า เมื่อเปิดลิงก์ ระบบจะตรวจสอบโทเคนที่ลงลายเซ็นไว้ ยืนยันความยินยอมที่ลูกค้าให้ไว้กับร้านค้านี้ในการจัดการรายการฝากแทน ตรวจสอบตัวตนผู้ใช้ และตัดค่า nonce ที่ใช้ได้ครั้งเดียวของลิงก์ — ทั้งหมดนี้เกิดขึ้นก่อนหน้าจอนี้จะแสดงผล สิ่งที่ลูกค้าเห็นคือการ์ดยืนยันนี้ ซึ่งแสดงจำนวนเงินและชื่อร้านค้าแบบย่อเก็บไม่ได้ (PDPA มาตรา 27) ก่อนที่ลูกค้าจะกดอะไรได้ พร้อมข้อความชี้แจงว่าการกดยืนยันคือการอนุญาตให้ร้านค้าเพิ่มยอดนี้เข้าระบบของตนเมื่อการโอนได้รับการตรวจสอบแล้ว ไม่มีสิ่งใดบนหน้านี้บอกลูกค้าว่ากำลังจะได้เส้นทางการชำระเงินแบบใดในสามแบบ และเป็นเช่นนั้นโดยตั้งใจ เพราะเส้นทางถูกกำหนดหลังจากลูกค้ากดยืนยัน และเป็นเรื่องของแพลตฟอร์ม ไม่ใช่ของลูกค้า
Step 2ขั้นตอนที่ 2
Deposit (bank transfer) - transfer and upload the slipฝากเงิน (โอนผ่านธนาคาร) - โอนเงินและอัปโหลดสลิป
After Confirm, the amount is locked and the customer sees the whole of what is left to do on one screen, in two numbered parts. Part 1 is where to send the money: the destination bank account, the account holder name, and a short reference code for the transfer memo, alongside a countdown to the reservation's hold window. On this route the account belongs to the merchant's own pool. The account shown is decrypted server-side just for this view - the customer never sees raw bank credentials anywhere else in the flow. Part 2 is the slip upload, with the button pinned to the bottom of the screen so it stays in reach on a phone while the details scroll. These were two separate pages until customers - most of them on phones - began treating the first as a splash screen to tap past. The page attempts an instant client-side QR read for feedback when a slip is chosen, but the upload proceeds either way: the server runs the same verification cascade regardless (ADR-0074), so a slow or failed client-side read never blocks the customer.หลังกดยืนยัน จำนวนเงินจะถูกล็อก และลูกค้าจะเห็นสิ่งที่เหลือต้องทำทั้งหมดในหน้าจอเดียว แบ่งเป็นสองส่วนที่มีหมายเลขกำกับ ส่วนที่ 1 คือจะโอนเงินไปที่ไหน ได้แก่ บัญชีธนาคารปลายทาง ชื่อเจ้าของบัญชี และรหัสอ้างอิงสั้น ๆ สำหรับใส่ในหมายเหตุการโอน พร้อมเวลานับถอยหลังของช่วงเวลาที่ระบบกันยอดไว้ให้ ในเส้นทางนี้บัญชีปลายทางเป็นบัญชีในกลุ่มบัญชีของร้านค้าเอง ข้อมูลบัญชีที่แสดงถูกถอดรหัสฝั่งเซิร์ฟเวอร์เพื่อการแสดงผลครั้งนี้เท่านั้น ลูกค้าจะไม่เห็นข้อมูลบัญชีธนาคารดิบที่จุดอื่นใดในขั้นตอนนี้ ส่วนที่ 2 คือการอัปโหลดสลิป โดยปุ่มถูกตรึงไว้ที่ขอบล่างของหน้าจอ เพื่อให้อยู่ในระยะนิ้วโป้งขณะที่รายละเอียดด้านบนเลื่อนผ่าน เดิมทีสองส่วนนี้เป็นคนละหน้า จนกระทั่งลูกค้า — ซึ่งส่วนใหญ่ใช้มือถือ — เริ่มกดผ่านหน้าแรกไปเหมือนเป็นหน้าโหลด หน้านี้จะพยายามอ่าน QR ฝั่งเครื่องลูกค้าทันทีที่เลือกไฟล์สลิปเพื่อให้ผลตอบกลับเร็ว แต่การอัปโหลดดำเนินต่อไม่ว่าจะอ่านได้หรือไม่ เพราะเซิร์ฟเวอร์จะรันขั้นตอนตรวจสอบชุดเดียวกันอยู่ดี (ADR-0074) การอ่านฝั่งเครื่องที่ช้าหรือล้มเหลวจึงไม่เคยขวางลูกค้า
Step 3ขั้นตอนที่ 3
Deposit (bank transfer) - doneฝากเงิน (โอนผ่านธนาคาร) - เสร็จสิ้น
The closing screen. Verification runs asynchronously once the slip lands, so this screen may show "payment received, verifying" for a few seconds before settling to "deposit submitted" - either way the customer can safely close the page and will be auto-returned to the merchant after a short countdown.หน้าจอปิดท้าย การตรวจสอบทำงานแบบไม่ประสานเวลาทันทีที่สลิปเข้าระบบ หน้าจอนี้จึงอาจแสดงข้อความว่า “ได้รับการชำระเงินแล้ว กำลังตรวจสอบ” อยู่สองสามวินาที ก่อนเปลี่ยนเป็น “ส่งรายการฝากแล้ว” ไม่ว่าจะเป็นสถานะใด ลูกค้าปิดหน้านี้ได้อย่างปลอดภัย และระบบจะพากลับไปยังร้านค้าเองหลังนับถอยหลังสั้น ๆ
Paying in — matched with another customerฝากเงิน — จับคู่กับลูกค้าอีกคน
The same three screens, and the same task. The only difference is that the account you pay belongs to a person rather than a business — someone withdrawing the same amount at the same moment.สามหน้าจอเดิม และงานเดิม ต่างกันอย่างเดียวคือ บัญชีปลายทางเป็นของบุคคล ไม่ใช่ของร้านค้า — คนที่กำลังถอนเงินจำนวนเท่ากันในจังหวะเดียวกัน
Step 4ขั้นตอนที่ 4
Deposit (matched with another customer) - arrival & confirmฝากเงิน (จับคู่กับลูกค้าอีกคน) - เข้าสู่หน้าจอและยืนยัน
The same link, the same confirm card, a different amount. This is worth showing twice precisely because it looks identical: the customer does not pick a payment route and is not told which one they will get. What changes behind this screen is that a matching withdrawal is already waiting at this amount, so the platform will pair the two directly.ลิงก์เดิม การ์ดยืนยันเดิม ต่างกันแค่จำนวนเงิน ที่ต้องแสดงซ้ำอีกครั้งก็เพราะหน้าจอนี้เหมือนกันทุกประการ ลูกค้าไม่ได้เลือกเส้นทางการชำระเงิน และไม่ได้รับแจ้งว่าจะได้เส้นทางใด สิ่งที่ต่างออกไปอยู่เบื้องหลังหน้าจอนี้ คือมีคำขอถอนที่รอจับคู่อยู่แล้วที่จำนวนเงินเท่านี้ แพลตฟอร์มจึงจะจับคู่ทั้งสองฝั่งเข้าด้วยกันโดยตรง
Step 5ขั้นตอนที่ 5
Deposit (matched with another customer) - transfer and upload the slipฝากเงิน (จับคู่กับลูกค้าอีกคน) - โอนเงินและอัปโหลดสลิป
The same two-part screen as a bank-route deposit, and to the customer it is the same task: transfer the amount to the account shown, quote the reference, upload the slip. The difference is whose account it is. Here the platform has matched this deposit against another customer who is withdrawing the same amount, so the money goes straight to that person's bank account - the platform never holds it. That is the whole design: P2P matches, verifies and records, and every transfer is bank-to-bank. Because that account is another individual's personal data, it is disclosed through an audited reveal rather than stored on the page, and the counterparty's name is shown so the customer can check it matches what their banking app confirms before they send.หน้าจอสองส่วนแบบเดียวกับการฝากเส้นทางบัญชีธนาคาร และสำหรับลูกค้าก็เป็นงานเดียวกัน คือโอนเงินไปยังบัญชีที่แสดง ใส่รหัสอ้างอิง แล้วอัปโหลดสลิป ความต่างอยู่ที่ว่าบัญชีนั้นเป็นของใคร ในกรณีนี้แพลตฟอร์มได้จับคู่รายการฝากนี้กับลูกค้าอีกคนที่กำลังถอนเงินจำนวนเท่ากัน เงินจึงวิ่งตรงเข้าบัญชีธนาคารของบุคคลนั้น โดยแพลตฟอร์มไม่ได้ถือเงินไว้เลย นี่คือแก่นของการออกแบบทั้งหมด P2P ทำหน้าที่จับคู่ ตรวจสอบ และบันทึก ส่วนทุกการโอนเป็นแบบธนาคารถึงธนาคาร เนื่องจากบัญชีนั้นเป็นข้อมูลส่วนบุคคลของบุคคลอื่น ระบบจึงเปิดเผยผ่านช่องทางที่มีการบันทึกการเข้าถึง แทนการเก็บไว้บนหน้าเว็บ และแสดงชื่อคู่รายการไว้ให้ลูกค้าเทียบกับที่แอปธนาคารขึ้นก่อนกดโอน
Step 6ขั้นตอนที่ 6
Deposit (matched with another customer) - doneฝากเงิน (จับคู่กับลูกค้าอีกคน) - เสร็จสิ้น
The same closing screen. Once the slip verifies, both sides settle at once: this customer's deposit is credited and the matched customer's withdrawal is filled by the transfer that was just made.หน้าจอปิดท้ายหน้าเดียวกัน เมื่อสลิปผ่านการตรวจสอบ ทั้งสองฝั่งจะจบพร้อมกัน คือรายการฝากของลูกค้ารายนี้ได้รับเครดิต และคำขอถอนของลูกค้าที่จับคู่กันได้รับการเติมเต็มด้วยการโอนที่เพิ่งเกิดขึ้น
Paying in — by QR, with no slipฝากเงิน — ผ่าน QR โดยไม่ต้องใช้สลิป
The one route where what you do changes — and it changes by doing less. There is no slip to upload and no upload button on the screen; the payment confirms itself.เส้นทางเดียวที่สิ่งที่คุณต้องทำเปลี่ยนไป — และเปลี่ยนไปในทางที่ทำน้อยลง ไม่มีสลิปให้อัปโหลด และไม่มีปุ่มอัปโหลดบนหน้าจอ การชำระเงินยืนยันตัวเอง
Step 7ขั้นตอนที่ 7
Deposit (payment gateway) - arrival & confirmฝากเงิน (เพย์เมนต์เกตเวย์) - เข้าสู่หน้าจอและยืนยัน
A checkout from a merchant that routes its deposits through a payment gateway rather than its own bank account. The entry gateway, the consent check and the confirm card are the same; note that this is a different merchant, so the name on the card differs.รายการชำระเงินจากร้านค้าที่รับเงินฝากผ่านเพย์เมนต์เกตเวย์ แทนบัญชีธนาคารของตนเอง ขั้นตอนเข้าสู่ระบบ การตรวจความยินยอม และการ์ดยืนยัน เหมือนกันทุกอย่าง ข้อสังเกตคือนี่เป็นคนละร้านค้า ชื่อบนการ์ดจึงต่างออกไป
Step 8ขั้นตอนที่ 8
Deposit (payment gateway) - scan the QR and waitฝากเงิน (เพย์เมนต์เกตเวย์) - สแกน QR แล้วรอ
This is the one deposit route that looks materially different, and the difference is worth spelling out for support staff: there is no slip to upload and no upload button on the screen. The gateway issues a QR code and a single-use account for this one payment, and the customer pays it from their banking app. The amount shown may end in an odd few satang - the gateway adds a small unique fraction so it can recognise the incoming transfer without a slip. From there the page simply waits: the gateway confirms the payment directly to the platform (ADR-0096) and the screen advances by itself. Manual account details are still shown underneath for customers who prefer to type them. If a gateway payment gets stuck past its window, an "I already paid - upload my slip" fallback appears; that is an exception path, not the normal one.นี่คือเส้นทางการฝากเงินเส้นทางเดียวที่หน้าตาต่างออกไปอย่างชัดเจน และเป็นความต่างที่ควรอธิบายให้ทีมซัพพอร์ตเข้าใจ คือไม่มีสลิปให้อัปโหลด และไม่มีปุ่มอัปโหลดบนหน้าจอ เกตเวย์จะออกรหัส QR และบัญชีที่ใช้ได้ครั้งเดียวสำหรับการชำระเงินครั้งนี้ แล้วลูกค้าจ่ายจากแอปธนาคารของตนเอง จำนวนเงินที่แสดงอาจลงท้ายด้วยเศษสตางค์แปลก ๆ เพราะเกตเวย์เติมเศษเล็ก ๆ ที่ไม่ซ้ำกันเข้าไป เพื่อให้จับคู่การโอนขาเข้าได้โดยไม่ต้องใช้สลิป จากนั้นหน้าจอก็เพียงรอ เกตเวย์จะยืนยันการชำระเงินมาที่แพลตฟอร์มโดยตรง (ADR-0096) แล้วหน้าจอจะเดินต่อเอง ข้อมูลบัญชีสำหรับกรอกเองยังแสดงไว้ด้านล่างสำหรับลูกค้าที่ถนัดพิมพ์เอง หากการชำระเงินผ่านเกตเวย์ค้างจนเลยกรอบเวลา จะมีทางเลือกสำรอง “ฉันจ่ายแล้ว — อัปโหลดสลิปของฉัน” ปรากฏขึ้น ซึ่งเป็นเส้นทางกรณียกเว้น ไม่ใช่เส้นทางปกติ
Step 9ขั้นตอนที่ 9
Deposit (payment gateway) - doneฝากเงิน (เพย์เมนต์เกตเวย์) - เสร็จสิ้น
When the gateway confirms the payment, the waiting screen advances on its own - the customer does not have to do anything or refresh. The closing screen is the same one all three routes end on.เมื่อเกตเวย์ยืนยันการชำระเงิน หน้าจอที่รออยู่จะเดินต่อเอง ลูกค้าไม่ต้องทำอะไรและไม่ต้องรีเฟรช หน้าจอปิดท้ายเป็นหน้าเดียวกับที่ทั้งสามเส้นทางมาจบ
Taking money outถอนเงิน
A withdrawal joins a queue rather than a wallet. The next customer paying in the same amount pays you directly — which is the matched route above, seen from the other side.การถอนเงินเข้าคิว ไม่ได้เข้ากระเป๋าเงิน ลูกค้าคนถัดไปที่ฝากเงินจำนวนเท่ากันจะเป็นคนจ่ายให้โดยตรง — ก็คือเส้นทางจับคู่ข้างต้น มองจากอีกฝั่งหนึ่ง
Step 10ขั้นตอนที่ 10
Hosted withdraw — arrival & confirmถอนเงินผ่านลิงก์ร้านค้า — เข้าสู่หน้าจอและยืนยัน
The withdraw counterpart of the deposit entry above — same token-verify, consent-check, and auth-gate, now for a payout. This particular link was left "open" by the merchant (no amount fixed), so the customer picks one of the merchant's enabled denominations here before tapping Confirm. There is no PIN step on this screen: the merchant-minted, customer-presented link is itself the authorization artifact (ADR-0071).ฝั่งถอนเงินของขั้นตอนเข้าสู่ระบบแบบเดียวกับการฝากด้านบน — ตรวจโทเคน ตรวจความยินยอม และตรวจสอบตัวตนเหมือนกัน เพียงแต่คราวนี้เป็นการจ่ายเงินออก ลิงก์นี้ร้านค้าเปิดไว้แบบไม่กำหนดจำนวนเงิน ลูกค้าจึงเลือกจำนวนเงินจากชุดที่ร้านค้าเปิดใช้งานไว้ที่หน้านี้ก่อนกดยืนยัน หน้าจอนี้ไม่มีขั้นตอนใส่ PIN เพราะลิงก์ที่ร้านค้าสร้างและส่งให้ลูกค้าถือเป็นหลักฐานการอนุญาตในตัวเองอยู่แล้ว (ADR-0071)
Step 11ขั้นตอนที่ 11
Hosted withdraw — transaction statusถอนเงินผ่านลิงก์ร้านค้า — สถานะรายการ
Confirming places the withdraw request straight onto the matching queue against the customer's verified default bank account — the platform still never transfers the money itself (ADR-0014); a matched seller pays the customer bank-to-bank. Rather than a one-off "done" screen, the customer lands on a revisitable, link-signed status page showing the amount and the request's current state, and is auto-returned to the merchant shortly after.การกดยืนยันจะส่งคำขอถอนเข้าคิวจับคู่ทันที โดยผูกกับบัญชีธนาคารหลักที่ลูกค้ายืนยันไว้แล้ว แพลตฟอร์มยังคงไม่ได้เป็นผู้โอนเงินเอง (ADR-0014) ผู้ขายที่จับคู่ได้จะเป็นคนจ่ายให้ลูกค้าแบบธนาคารถึงธนาคาร แทนที่จะเป็นหน้าจอ “เสร็จสิ้น” แบบดูได้ครั้งเดียว ลูกค้าจะมาอยู่ที่หน้าสถานะที่กลับมาดูซ้ำได้และมีลายเซ็นกำกับลิงก์ ซึ่งแสดงจำนวนเงินและสถานะปัจจุบันของคำขอ แล้วระบบจะพากลับไปยังร้านค้าในเวลาไม่นาน
Checking on thingsตรวจสอบรายการ
Your own activity with this business, and any single transaction in full — including the slip you uploaded and every check made against it.กิจกรรมของคุณกับร้านค้านี้ และรายละเอียดทั้งหมดของแต่ละรายการ — รวมถึงสลิปที่คุณอัปโหลด และทุกครั้งที่ระบบตรวจสอบสลิปใบนั้น
Step 12ขั้นตอนที่ 12
Hosted history — inboxประวัติผ่านลิงก์ร้านค้า — กล่องรายการ
A merchant can also hand the customer a read-only history link so they can check on past activity without leaving the merchant's app. It lists every hosted deposit and withdrawal for this customer through this merchant (and any sibling-linked merchants), split into "Ongoing" items still needing action and a paginated "Past" list — with activity that belongs to a different merchant masked, so no merchant can fingerprint a customer's cross-merchant behaviour.ร้านค้ายังส่งลิงก์ประวัติแบบอ่านอย่างเดียวให้ลูกค้าได้ด้วย เพื่อให้ตรวจดูรายการที่ผ่านมาโดยไม่ต้องออกจากแอปของร้านค้า หน้านี้แสดงรายการฝากและถอนผ่านลิงก์ทั้งหมดของลูกค้ารายนี้กับร้านค้านี้ (รวมถึงร้านค้าที่ผูกกันในเครือเดียวกัน) แบ่งเป็นรายการ “กำลังดำเนินการ” ที่ยังต้องทำอะไรต่อ และรายการ “ที่ผ่านมา” แบบแบ่งหน้า โดยกิจกรรมที่เป็นของร้านค้าอื่นจะถูกปิดบังไว้ ร้านค้าจึงไม่สามารถไล่ดูพฤติกรรมของลูกค้าข้ามร้านได้
Step 13ขั้นตอนที่ 13
Hosted history — transaction detailประวัติผ่านลิงก์ร้านค้า — รายละเอียดรายการ
Opening a row shows that transaction's full detail: its status timeline, the settled amount, and — for a deposit — the verification-attempt history and the uploaded slip image. This is the same detail a customer would reach from the completion screens above, revisitable any time through the merchant's history link.การเปิดรายการหนึ่งจะแสดงรายละเอียดทั้งหมดของรายการนั้น ได้แก่ ไทม์ไลน์สถานะ จำนวนเงินที่ชำระจริง และ — สำหรับรายการฝาก — ประวัติการพยายามตรวจสอบสลิป พร้อมภาพสลิปที่อัปโหลดไว้ นี่คือรายละเอียดชุดเดียวกับที่ลูกค้าเข้าถึงได้จากหน้าจอปิดท้ายด้านบน และกลับมาดูได้ทุกเมื่อผ่านลิงก์ประวัติของร้านค้า