תיקונים חלקיים ומוחלטים

TL; DR

Refand הוא הפעולה ההפוכה על הכמות שנתפסה. מלא סוגר את כל העסקה, חלקי מחזיר חלק (יכול להיות סדרה חלקית עד מלאה). קריטי: החזר למקור, אידמפוטנציה קפדנית, כריתת היגיון, ותזמור עם חוברות אינטרנט/רטראס. שיעור החזר מדידה, TTR p95, שגיאת החזר ושלילת כפילויות/חוסר עקביות באמצעות פיוס אוטומטי.

1) מונחים והבדלים מהותיים

החזר מלא - מחזיר את כל הסכום המחויב ("החזר כספי = capture_amount').
החזר חלקי - מחזיר חלק ("0 <refund_amount <capture_amount'), מאפשר את השאר חלקי לסך 'לכידה _ כמות'.
החזר למקור - החזר לשיטת התשלום/מסילות המקוריות (רגולציה מועדפת/חובה).
ביטול הריק כדי ללכוד (אם נתמך על ידי מסילות), אינו נחשב לשדרוג.
היפוך/Chargback - בנק/מכניקת רכבות מחוץ ליוזמה שלך (סכסוכים, צ 'רג' בקס) - אין להתבלבל עם refand.

2) מתי להוציא מלא נגד חלקי

• בטל הזמנה/שירות שלם, שכפול מחיקה, שגיאת מערכת.
• חובה אם השירות אינו מסופק (לפי כללי הצרכן/רגולטור).

• ביטול חלקי של השירות, שינויים פרופורציונליים (הנחות, פיצוי על עיכובים).
• טכני מגביל מסילות (כמות מקסימלית לכל פעולה) - סדרה חלקית.
• עמלה פוסט-factum מונעת (היכן שמותר פיקוח) - פחות פעמים ב-iGaming.

3) מדיניות ומגבלות

החזר למקור = נכון כברירת מחדל; חריגים - באמצעות MLRO/cases (רשום).
חיתוך: ריפודים מותרים N ימים מלכידה (על ידי שיטה/תחום שיפוט).
Max Partical Count: לא יותר מאשר K חלקי לכל תשלום (בדרך כלל K Lother 5).
סכום חלקי מין: לא נמוך ממסילה מינימלית טכנית/PSP.

• סוכן תמיכה: איקס חלקי, יומן מלא.
• מנהל/פיננסים: מעבר לגבולות, חריגים בשיטה צולבת.
• התקררות על ניסיונות חוזרים ונשנים (אנטי-להקפיץ).

4) ארכיטקטורה וזרימת אירועים

• תזמורת התשלומים היא המקור לאמת הסטטוס.
• שירות החזר כספי - API, אידמפוטנטיות, תזמור של מגשים מחדש, כריתת עצים.
• מתאם PSP - שילוב שיטות.
• פיוס - פיוס אוטומטי, DLQ, תיקונים.
• פנקס חשבונות - פרסומים, עריקים, ניקוי עם בירור.
• סיכונים/ציות - סנקציות/SOF בודק בתרחישים שנויים במחלוקת.

1. החזר כספי. Create '(API) avidation = (גבולות, שיווי משקל, מדיניות, KYC/SOF במידת הצורך).

2. idempotency_key (”hash (payment_id + refund_amount + סיבה + nonce)”).

3. שיחת PSP = ”ממתינה”.

4. Webhook/clock = ”הצלחה ”/” נכשל”; כאשר פסק זמן - מגשים מחדש עם אותו מפתח.

5. פרסום האירוע בקפקא = לדג 'ר, BI, התראות.

6. פיוס אוטומטי: מיפוי "ספק _ החזר _ id' לרישום.

5) אידמפוטנטיות ואנטי-טייקים

לא ניתן לזקוף זאת לזכותו פעמיים: כל הלוגיקה באמצעות אחסון אידמפוטנטיות (KV/Redis + TTL).
מפתחות על payment_id × כמות x סיבה (ובמידת הצורך, ”partical _ index”).
מגשים חוזרים משתמשים באותו מפתח.
חלקיות מקבילות מוגנות על ידי מנעולים/גרסה אופטימית על כמויות מצטברות.

python def refund(payment_id, amount, reason, idem_key):
if idem_store. exists(idem_key): return idem_store. get(idem_key)
with tx():
p = db. get_payment(payment_id, for_update=True)
assert p. captured_amount - p. refunded_amount >= amount > 0 r = p. create_refund(amount, reason, status='PENDING', idem_key=idem_key)
resp = psp. refund(p. provider_txid, amount, idem_key)
return finalize(r, resp. status, resp. ext_id)

6) מודל נתונים (מספיק מינימלי)

json
{
"payment_id": "pay_123",
"captured_amount": 150. 00,
"currency": "EUR",
"refunded_amount": 40. 00,
"refunds": [
{
"refund_id": "rf_001",
"type": "partial    full",
"amount": 20. 00,
"reason_code": "PARTIAL_SERVICE",
"idempotency_key": "idem_a1",
"status": "PENDING    SUCCESS    FAILED",
"provider_refund_id": "psp_rf_9xz",
"created_at": "2025-11-03T12:00:00Z",
"credited_at": "2025-11-03T15:05:00Z",
"notes": "ticket #456"
}
],
"flags": {
"refund_to_source": true,
"jurisdiction": "EEA",
"kyc_tier_required": "tier2"
}
}

7) תכונות על מסילות תשלום

קלפים (ויזה/מאסטרקארד)

תמיכה מלאה/חלקית; לעתים קרובות באופן חלקי; TTR תלוי בבנק הלקוח (T + 1... T + 5 bp).
ספרי אינטרנט על הצלחה מגיעים במהירות, אבל ההרשמה לפריקה עלולה להיות מאוחרת. אנחנו מסבירים בתבנית התמיכה.

A2A/Open בנקאות/RTP

לעיתים קרובות החזר מיידי (היפוך/דחף אשראי); ספקים מסוימים תומכים רק באופן מלא או חלקי 1.
קשירה קפדנית לחשבון המקורי; יש צורך בהחזר כספי.

ארנקים אלקטרוניים

נורמלי מלא/חלקי; TTR דקות; מגבלות חלקיות ומינימום.

שוברים/מראש

בדרך כלל מדיניות ההחזר: חזרה לארנק הפנימי או הנפקה מחודשת של שובר (אם הספק יודע איך). דורש סעיפי ציות.

קריפטו

מסילות - הפכפכות; עדיף לא לשמש כשיטת ריבאונד. אם מותר: לחזור לאותה כתובת/בורסה עם תעריף ועמלות מתועדות; בדיקת AML.

8) חשבונאות, פיוס ופיננסים

פנקס: ”DR הכנסות/CR Cash” פרסומים בלכידה; על החזר כספי. החלקי משתקף באופן יחסי.
הכרה: ב-iGaming, refand מפחית את ה-GGR של התקופה המתאימה (מדיניות חשבונאית).
פיוס: פיוס יומי 'סוחר _ החזר _ ↔ provider_refund_id', סטטוסים, סכומים, שיעורי FX.
FX: לתקן את הלוגיקה של הקורסים (בזמן לכידה או בזמן החזר), היכן שניתן ליישם; להחזיק את רשת התפשטות.

9) KPIs, מטרות והתראות (בריאות החזר)

קצב החזר = "Refunded _ Tx/ Captured_Tx'.
יחס סכום החזר = "Refunded _ Sume/ Captured_Amount'.
TtR p95 = p95 ("קרדיט _ at - created_at') בשיטה.
שיעור שגיאות החזר = ”נכשל/ניסיון” (<0. 3%).
החזר למקור% 95% (היכן שזמין).
תקריות החזר כפול = 0.

• 'TR p95 &post גבוה יותר מ-SLO על ידי שיטת P2.
• קוצים על ידי 'קצב החזר' בספק אחד/BIN # P1 (בדיקה תופסת/כפולה).
• כל 'החזר כפול> 0' = P0 (הקפאה מיידית של החזרה אוטומטית).

10) פרוסות SQL

10. פרופיל ריפנד 1

sql
SELECT
DATE_TRUNC('day', r. created_at) AS d,
method_code, provider,
COUNT() FILTER (WHERE r. status='SUCCESS')  AS refunds_ok,
COUNT() FILTER (WHERE r. status='FAILED')  AS refunds_fail,
SUM(r. amount) AS refunded_amount,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (r. credited_at - r. created_at))) AS ttr_p95_sec
FROM refunds r
JOIN payments p ON p. payment_id = r. payment_id
GROUP BY 1,2,3;

10. 2 בקרת שיווי משקל עבור חלקי

sql
SELECT p. payment_id,
p. captured_amount,
SUM(r. amount) AS refunded_sum,
(p. captured_amount - SUM(r. amount)) AS refundable_left
FROM payments p
LEFT JOIN refunds r ON r. payment_id = p. payment_id AND r. status IN ('SUCCESS','PENDING')
GROUP BY 1,2
HAVING (p. captured_amount - SUM(r. amount)) < 0;

11) UX ותמיכה

תבניות ההודעות לפי שיטות: אנו מסבירים את ההשהיה האפשרית בפריקה לכרטיסים, A2A - כמעט באופן מיידי.
סטטוסים במשרד: ”Process # In Process _ Return”; הצג את תאריך הגיוס הצפוי.
סיבות (reason_code) - אדם קריא: ”שכפול מחיקה”, ”ביטול שירות”, ”פיצוי חלקי”.
שירות עצמי חלקי - בטוח רק עם גבולות וכללים ברורים.

12) סיכון וציות

התנגדות להלבנה: refand לא צריך להפוך לתפוקה לערוץ אלטרנטיבי; לבצע חריגים באישור MLRO.
סנקציות/REP: עבור החזרות שיוזמו לחשבונות ”אדומים ”/פרטים - אימות חובה.
DSAR/Resurrection - עקבות אחסון של ריפודים בתוך מדיניות שימור.
כללים מקומיים: מונחים ונוהל להחזר (למשל, תקנות הצרכן) - משתקפים במדיניות.

13) טעויות תכופות וכיצד להימנע מהן

Refand כפול בשל חוסר אידמפוטנטיות וחזרה על חוברות אינטרנט = = לאחסן אידאם מפתח/סטטוס, לבדוק את האיזון.

החזר בשיטה צולבת ללא אישור ציות מפר החזר למקור.
ערבוב חלל והחזר בדו "חות * עיוות של KPI.
אין בדיקות אוטומטיות. חורים שחורים.

14) ספרי משחק

נחשול בהספק חוזר * בדיקת כשלים/לכידה כפולים, הפעלת הכשל, מגע עם PSP.
Mass Partical-Publication (קמפיין)).
שגיאת Webhooks # מתג לסקרים, הגדלת אידמפוטנטיות TTL, דחיית החזרה אוטומטית.
Recond-to-source exception (נדיר) # הסלמה MLRO, תשלום מתועד, ו- ”comp _ אושר = אמת”.

15) מקרי מבחן (UAT/Prod)

1. החזר מלא אחרי לכידה אחת.
2. Batch partical (3 ×) acht sum locket; ואז מלא לשארית.
3. Idempotency - חזור על אותה שאילתה = 1 תוצאה.
4. Webhook-להקפיץ: 3 הודעות זהות = אחד למחיקה/אשראי.
5. פיוס: התאמה לא נכונה מלאכותית = = התראה ותיקון אוטומטי.
6. הגבלת הזכויות: הסוכן אינו יכול לעבור את הגבול החלקי.
7. חיתוך: ניסיון ריפנד מאוחר = כשל נכון וכריתת עצים.

16) רשימת מימושים

[ ] מדיניות מלאה/חלקית + החזר למקור על ידי שיפוט/שיטה.

[ ] אידמפוטנטיות, נסיגות, צילומי רשת וסקרים, די-אל-קיו.

[ מודל ] דאטה עם שאריות לחזור reason_code.

[ ] לדג 'ר ופיוס אוטומטי יומי.

[ ] KPI/Dashboard: שיעור החזר, TtR, שגיאה, החזר כפול = 0.

[ זכויות ] ומטריצת יישומים, תבניות תמיכה.

[ ] מקרי מבחני UAT והתראות ברמת ייצור.

תקציר

ניהול מחדש הוא משמעת קפדנית של תהליכים: החזר למקור, אידמפוטנטיות, מודל מידע שקוף, פיוס אוטומטי ומדיניות חלקית/מלאה מובנת. עם יסודות כאלה, אתה שומר TTR נמוך, טעויות קרוב לאפס, שכפול בלתי אפשרי, וציות ופיננסים מסונכרנים עם מטרות עסקיות.