תפסיקו לבצע החזרים על תשלומים שלא הייתם אמורים לגבות
מפתחים רבים משיקים תהליך checkout שמגבה את הכרטיס באופן מיידי. לאחר מכן, הם מריצים אימות הזמנה כמו בדיקות מלאי או בדיקות הונאה.
אם האימות נכשל, הקוד מבצע החזר כספי (refund).
זה יוצר בעיות עבור הלקוחות שלכם. הם רואים חיוב ואז החזר ימים לאחר מכן. הם חושבים שהחברה שלכם אינה אמינה, והם חושבים שהכסף שלהם תקוע.
להחזרים כספיים יש עלויות אמיתיות:
- לקוחות מאבדים אמון כשהם רואים שתי עסקאות נפרדות.
- לוקח 5 עד 10 ימים להחזר להופיע בדף פירוט הבנק.
- אתם עלולים להפסיד כסף על עמלות עסקה או שערי חליפין.
- רשתות כרטיסי האשראי מסמנות דפוסים חוזרים של חיוב והחזר כגורם בסיכון גבוה.
הפתרון הוא להשתמש במודל של authorize ו-capture.
רוב המדריכים מלמדים אתכם לבצע capture לכסף באופן מיידי. במקום זאת, עליכם לבצע hold על הכספים תחילה. ה-hold נשאר על הכרטיס מבלי להעביר את הכסף בפועל. אם האימות שלכם נכשל, אתם פשוט מבטלים את ה-hold. אף חיוב לא יופיע בפירוט החשבון של הלקוח.
ב-Stripe, עושים זאת על ידי הגדרת ה-capture_method ל-manual.
התהליך החדש עובד כך:
- צרו
PaymentIntentעםmanual capture. - הכספים עוברים authorization אך לא מועברים.
- הריצו את אימות ההזמנה שלכם.
- אם ההזמנה תקינה, בצעו capture לתשלום.
- אם ההזמנה נכשלת, בטלו את ה-intent.
גישה זו מציעה מספר יתרונות:
- אתם נמנעים מהצורך לבצע החזרים.
- authorization שבוטל פשוט נעלם מפירוט החשבון של הלקוח.
- ניתן לבצע partial captures. אם לקוח קונה שלושה פריטים אך אחד מהם חסר במלאי, אתם מבצעים capture רק עבור שני הפריטים.
- אתם יוצרים audit trail נקי ביומנים (logs) שלכם.
רוב ספקי התשלומים הגדולים משתמשים באותה לוגיקה:
- Stripe משתמשת ב-
capture_method: manual. - Adyen משתמשת ב-manual capture delays.
- Braintree משתמשת ב-
submitForSettlement: false. - PayPal משתמשת ב-
intent: AUTHORIZE.
השתמשו בשיטה זו אם חלק כלשהו מהלוגיקה העסקית שלכם עלול להיכשל לאחר שהלקוח לוחץ על "שלם" (pay). העבירו את הבדיקות הסיכוניות שלכם לשלב שבין ה-authorization ל-capture. זה ישמור על תנועות כספים נקיות ועל לקוחות מרוצים.
מקור: https://dev.to/jguillaumesio/stop-refunding-payments-you-should-never-have-charged-4d7m