החזר Stablecoin אינו ביטול עסקה: כך מתכננים מסלול תשלום שני

1. Refund הוא התחייבות חדשה, לא מחיקה של העבר

העסקה המקורית נשארת בבלוקצ׳יין גם לאחר שהלקוח זוכה. היא ממשיכה להוכיח שנכס מסוים הועבר מכתובת אחת לאחרת בזמן ובבלוק מסוימים. ההחזר מוסיף עסקה שנייה בכיוון אחר. מבחינה חשבונאית, הראשונה יכולה לסגור יתרת לקוח וליצור הכנסה או התחייבות לבית עסק; השנייה יוצרת התחייבות לזיכוי ומסלקת אותה רק לאחר שהעברה חדשה הופכת לסופית לפי מדיניות המוצר.

ההפרדה הזאת צריכה להופיע במודל הנתונים. Refund object מקבל מזהה משלו, קישור ל־payment intent ולהזמנה, סיבת החזר, סכום, מטבע חשבונאי, asset ו־network, כתובת יעד, בעל הרשאה ומצב. אפשר להחזיר חלק מעסקה, לבצע כמה החזרים עד לתקרה, או לסרב לבקשה. אסור לשנות בדיעבד את סכום התשלום המקורי כדי לגרום לדוח להיראות כאילו העסקה מעולם לא קרתה.

גם הממשק צריך לדבר בשפה מדויקת. ״בקשת ההחזר התקבלה״, ״ההחזר אושר״, ״העסקה שודרה״ ו־״ההחזר הושלם״ הם מצבים שונים. אם מציגים ללקוח ״הוחזר״ ברגע שהעובד לחץ על הכפתור, התמיכה תתקשה להסביר עיכוב, כשל גז או כתובת שנדחתה. שקיפות במצב אינה רעש טכני; היא הבטחה מוצרית שניתן לקיים.

2. כתובת המקור אינה בהכרח כתובת ההחזר

זהו כלל הבטיחות החשוב ביותר. תשלום יכול להגיע מכתובת הפקדה של בורסה, חשבון משמורן, smart account, relayer, חוזה routing או כתובת זמנית. Coinbase מזהירה במפורש שלא להחזיר אוטומטית נכס לכתובת השולחת, משום שכאשר ההעברה יצאה מחשבון Coinbase, הכסף עלול להגיע ל־Coinbase ולא לאדם שהתכוונתם לזכות. בזרימת Commerce של Coinbase מוגדרת כתובת החזר שהמשלם מוסר בנפרד — הבחנה ארכיטקטונית, לא רק פרט בממשק.

כתובת ההחזר צריכה להגיע מהלקוח בתוך session מאומת ולהיקשר לבקשה מסוימת. המערכת שומרת מי מסר אותה, מתי, באיזה ערוץ, לאיזו רשת ובאיזה פורמט. כאשר סכום ההחזר גבוה, כתובת חדשה או חשבון עסקי משותף מצדיקים אימות נוסף. חתימה מהארנק יכולה להוכיח שליטה בכתובת יעד, אך היא אינה בהכרח מוכיחה שהחותם הוא הלקוח החוקי או בעל הזכות הכלכלית.

אסור גם לתת לעובד תמיכה להדביק כתובת בחופשיות ולהמשיך. כתובת שהוקלדה ידנית צריכה checksum כאשר הרשת תומכת בכך, בדיקת network, סימולציה או screening לפי מדיניות, אישור שני מעל סף ורשומת audit. כתובת שמופיעה ב־QR או בפרופיל קודם אינה פטורה מאימות מחדש; ייתכן שהלקוח שינה משמורן או שהחשבון הישן אינו מקבל עוד הפקדות.

3. רשת, חוזה ו־asset הם חלק מהוראת ההחזר

השם USDC אינו מספיק כדי לזהות את מה שמחזירים. Circle מפרסמת רשתות וכתובות חוזה נתמכות, ומזהירה שהפקדה של נכס או מסלול שאינם נתמכים עלולה לגרום לאובדן כספים. הוראת החזר צריכה לציין chain namespace, chain ID, כתובת חוזה token, decimals וכתובת יעד. ב־Solana, Stellar או רשת שאינה EVM, מבנה הכתובת, memo או דרישות חשבון עשויים להיות שונים.

ברירת המחדל ההגיונית היא להחזיר באותו asset ובאותה רשת שבהם התשלום נסלק, כל עוד הלקוח אישר כתובת מתאימה והמסלול עדיין נתמך. מעבר לרשת אחרת הוא cross-chain payout, לא refund פשוט. הוא מוסיף bridge או burn-and-mint, זמני finality שונים, עלות, מסלול failure ונקודת שירות נוספת. אם העסק מאפשר זאת, הלקוח צריך לראות ולקבל את תנאי ההמרה והמסלול.

קטלוג הנכסים חייב להיות מנוהל בשרת. הוא כולל כתובות חוזה מאומתות, decimals, סטטוס קבלה והחזר, ספי finality, מגבלות סכום, נדרש memo, וספק RPC או indexer. שינוי תמיכה אינו מוחק היסטוריה. בקשת החזר ישנה נשארת קשורה לגרסת הקטלוג ששימשה בהחלטה, ואילו ביצוע חדש צריך לעבור גם את כללי ההווה.

4. מה בדיוק מחזירים: יחידות token או ערך מסחרי?

כאשר מחיר המוצר נקוב בדולר והלקוח שילם ב־stablecoin, נדמה שהשאלה פשוטה. בפועל ייתכנו spread, עמלת רשת, עמלת שירות, הנחה, מס, tip, תשלום חלקי או סטייה מהצמדה. המדיניות צריכה לומר אם ההחזר מחושב לפי סכום ההזמנה, סכום ה־token שהתקבל, הסכום נטו שנזקף לבית העסק או שער בזמן האישור. בלי כלל מפורש, שני צוותים יכולים להגיע לשני מספרים נכונים לכאורה.

יש לשמור את החישוב ולא רק את התוצאה. Refund quote כולל סכום חשבונאי, rate, מקור שער, זמן תוקף, token amount ביחידות base, טיפול בעיגול, עמלות ומי נושא בגז. אם הצעה פגה לפני החתימה, יוצרים גרסה חדשה. אסור לעדכן שדה קיים בשקט, משום שאז אי אפשר להסביר מדוע הלקוח קיבל סכום אחר מזה שאושר.

המערכת צריכה לשמור cap מצטבר לפי רכיבי ההזמנה. אם שולם 100 והוחזרו 30, בקשה חדשה יכולה לכל היותר להגיע ליתרה המותרת, לאחר התאמות. מנגנון concurrency מונע משתי בקשות במקביל לעבור את אותה יתרה. זהו מקום שבו row lock, unique key או state transition אטומי חשובים יותר מעיצוב הכפתור.

• Gross paid — מה שהלקוח העביר בפועל.
• Refundable value — החלק הזכאי לפי ההזמנה והמדיניות.
• Refund quoted — כמות ה־token שאושרה להצעה הנוכחית.
• Refund settled — הכמות שנשלחה והפכה לסופית לפי סף הרשת.

5. מכונת מצבים מונעת זיכוי כפול

מסלול אמין יכול לעבור requested, eligibility_review, destination_required, quoted, approved, signing, broadcast, confirming, completed, failed, cancelled או expired. לכל מעבר יש תנאי ובעל הרשאה. לדוגמה, מערכת שירות יכולה ליצור requested, אבל רק risk או finance מאשרים סכום גבוה; treasury משדרת רק approved; ו־observer מעביר ל־completed אחרי receipt תקין וסף finality.

כל פקודה צריכה idempotency key. אם עובד לחץ פעמיים, API client ניסה שוב אחרי timeout או webhook הגיע מחדש, המערכת מחזירה את אותה בקשה ולא יוצרת התחייבות נוספת. גם בצד השרשרת יש לשמור attempts: טרנזקציה שהוחלפה בגז גבוה יותר, כזו שנכשלה וכזו שהצליחה קשורות לאותו refund, אבל רק אחת מהן רשאית לסגור את ההתחייבות.

אירוע completed אינו נקבע לפי transaction hash שנוצר. יש לאמת chain, token contract, from, to, amount, receipt וה־Transfer event של ERC‑20. תקן ERC‑20 דורש אירוע Transfer על העברה מוצלחת, אך אינטגרציה עדיין צריכה להתמודד עם tokens ו־providers שמתנהגים באופן שונה. שירות הצפייה הוא מקור האמת לתוצאה, לא תגובת הארנק או ה־relayer.

6. הרשאות והונאה שונות מתהליך התשלום המקורי

תשלום נכנס מצמצם בדרך כלל את החשיפה של העסק; החזר יוצא מגדיל אותה. תוקף יכול להשתלט על חשבון לקוח ולבקש שינוי כתובת, לשכנע תמיכה שהרשת המקורית אינה זמינה, או לנצל הזמנה שכבר הוחזרה בערוץ אחר. לכן אימות הזכאות, אימות היעד והרשאת הביצוע הם שלושה שערים נפרדים.

מודל סיכון טוב בודק גיל חשבון, שינוי פרטי קשר, כתובת חדשה, סכום, תדירות החזרים, התאמה להזמנה, היסטוריית dispute וחריגה מהדפוס. הוא אינו הופך ציון אוטומטי לפסק דין. סכום קטן לכתובת מוכרת יכול לעבור אוטומטית; סכום גבוה או שינוי רשת דורשים review. החלטה שלילית נשמרת עם סיבה ודרך ערעור.

ב־treasury יש להפריד proposer, approver ו־executor. העובד שמאשר החזרה ללקוח לא צריך להחזיק לבדו במפתח שמזיז כסף. allowlist קבועה מדי אינה מתאימה משום שכתובות לקוחות חדשות לגיטימיות, אבל אפשר להשתמש ב־temporary allowlist הקשורה ל־refund ID, לסכום, לנכס ולחלון זמן. לאחר הביצוע ההרשאה פגה אוטומטית.

7. גז הוא חלק מחוויית ההחזר

כדי להחזיר ERC‑20, חשבון התפעול צריך גם token וגם נכס native לתשלום gas. החזר יכול להיות מאושר מבחינה עסקית אך להיתקע משום שארנק ההחזרים מחזיק USDC בלי ETH, POL או הנכס הנדרש ברשת. לכן זמינות refund נמדדת גם ב־gas runway: כמה פעולות ניתן לבצע תחת עלות רגילה ובתרחיש עומס.

העסק צריך לקבוע מי נושא בעלות. אפשר לספוג gas, לנכות אותו רק אם תנאי העסקה מאפשרים זאת, או לאגד החזרים באמצעות תשתית שנבדקה. אין לשנות סכום לאחר אישור בלי הסכמה ורשומה. כאשר gas גבוה מהחזר זעיר, אפשר להציע credit פנימי או להמתין לחלון זול יותר—אך לא לכפות חלופה שמצמצמת את זכות הלקוח בניגוד למדיניות או לדין.

Paymaster או relayer יכולים להסתיר מורכבות, אך אינם מבטלים אותה. יש להגדיר budget, rate limit, idempotency ודרך fallback. אם השירות החיצוני אינו זמין, המערכת צריכה להציג queued ולהפסיק התחייבויות חדשות שאינה יכולה למלא, במקום להמשיך להבטיח completion מיידי.

8. החזרים חלקיים, קבוצתיים ורב־ערוציים

מסחר אמיתי כולל ביטול פריט אחד, משלוח חלקי, החזרת מוצר, פיצוי שירות והחזר מס. לכן refund צריך להיקשר ל־line items ולסיבות, לא רק להזמנה כולה. סכום מצטבר נבדק מול היתרה הזכאית, ומערכת המס או החשבונאות מקבלת אירוע מתאים. אם לקוח קיבל קודם credit בחנות ואז ביקש החזר on-chain, המדיניות חייבת למנוע כפל.

Batching יכול לחסוך gas אך מסבך בידוד כשל. טרנזקציה אחת עשויה לכלול עשרות לקוחות; חוזה או recipient אחד עלולים לגרום ל־revert של הקבוצה, בהתאם למימוש. יש לשמור manifest של כל פריט, סכום וכתובת, לבדוק שסך ה־calldata תואם להתחייבויות, ולדעת לפצל או לנסות מחדש בלי לשלם פעמיים למי שכבר זוכה.

במוצרים רב־ערוציים, ההזמנה עשויה להתחיל בכרטיס ולהסתיים ב־stablecoin, או להפך. אין להניח שהערוץ האחרון הוא המקור. מערכת מרכזית של orders, payments, refunds ו־credits צריכה לחשב את הזכאות הכוללת. כל connector מדווח ביצוע; אף connector אינו רשאי להחליט לבדו כמה עוד מותר להחזיר.

9. Reconciliation מחבר את השרשרת לספרים

הבלוקצ׳יין מוכיח שהעברה בוצעה; ה־ledger מסביר מדוע. בעת אישור נרשמת התחייבות refund payable. בעת broadcast נוצר נכס או מצב funds in transit, ובעת settlement ההתחייבות נסגרת מול יציאת treasury ועלות gas. אם העסקה נכשלה, אין לסגור את ההתחייבות; אם היא הוחלפה, attempts נשארים קשורים לאותו אירוע עסקי.

התאמה יומית משווה בין בקשות שאושרו, טרנזקציות ממתינות, Transfer events, שינויים ביתרות, עמלות ורישומי ERP. חריגה מקבלת owner ו־SLA. דוגמאות: סכום base units שגוי, token עם decimals שונים, טרנזקציה לכתובת ישנה, webhook כפול או העברה ידנית שלא קושרה להזמנה. לא ״מתקנים״ חריגה במחיקת שורה; יוצרים adjustment מתועד.

גם יתרת refund wallet דורשת התאמה. כספים שמיועדים להתחייבויות מאושרות אינם surplus לסריקה אל reserve. מנוע treasury צריך לקרוא את ה־ledger לפני sweep. אחרת אוטומציה אחת מרוקנת את הנזילות שהאוטומציה השנייה צריכה, והמוצר נראה תקין עד לרגע שבו הלקוח מחכה.

10. תקשורת, ראיות ו־runbook

ללקוח יש להציג asset, רשת, כתובת מקוצרת אך ניתנת לבדיקה, סכום, מי נושא בעמלה, מצב וקישור ל־explorer לאחר שידור. לפני האישור כדאי להציג אזהרה שהעברה לכתובת שגויה או לרשת שאינה נתמכת אינה הפיכה. אין לשלוח seed phrase, private key או בקשה לחיבור ארנק בתוך הודעת תמיכה. ערוצי התקשורת הרשמיים צריכים להיות ברורים כדי לצמצם phishing.

תיק ההחזר שומר את הבקשה, זכאות, גרסאות quote, אימות כתובת, approvals, policy version, attempts, transaction receipt, אירועי webhook ורישומי ledger. המידע מאפשר לפתור מחלוקת, לבצע audit ולשחזר החלטה. ראיות נשמרות מחוץ למחשב של המפעיל, עם הרשאות ושמירה מוגבלות; אין צורך לשמור סוד חתימה או מידע אישי שאינו נדרש.

לפני עלייה לאוויר מריצים תרגילים: כתובת בורסה שאינה כתובת החזר, רשת שגויה, refund כפול במקביל, gas שנגמר, טרנזקציה שהוחלפה, webhook שחזר פעמיים, partial refund ומעבר ידני. מודדים זמן זיהוי, זמן עצירה, יכולת rollback ו־reconciliation. העיקרון של דור ארד כאן פשוט: מוצר תשלומים אינו נמדד רק בדרך שבה הוא מקבל כסף, אלא ביכולת שלו להחזיר ערך בשליטה, בדיוק ובהסבר מלא.