پیاده سازی فنی سیستم کش بک: معماری Ledger و چالش درگاه پرداخت (راهنمای ایرانی)

تصور کنید می‌خواهید یک سیستم کش بک راه‌اندازی کنید. اولین راه‌حلی که به ذهن اکثر ما می‌رسد چیست؟ احتمالاً اضافه کردن یک فیلد credit به جدول users در دیتابیس. ساده به نظر می‌رسد، نه؟

اما این ساده‌ترین راه، در واقع یک تله فنی بزرگ است. در بازاری که هزینه جذب مشتری (CAC) سر به فلک کشیده، تمرکز بر بازگشت مشتری (Retention) دیگر یک انتخاب نیست، یک ضرورت است و پیاده سازی فنی سیستم کش بک یکی از قوی‌ترین ابزارهای شما برای این کار است.

اما اگر این پیاده‌سازی اشتباه باشد، چه اتفاقی می‌افتد؟ چه می‌شود اگر مشتری کالا را مرجوع کند؟ چطور می‌خواهید تراکنش‌ها را حسابرسی کنید؟ اگر بخواهید برای کش بک تاریخ انقضا بگذارید چه؟

پیاده سازی فنی سیستم کش بک واقعی، بسیار فراتر از یک فیلد اعتبار شناور است. این یک سیستم مالی دقیق برای مدیریت «بدهی» شما به مشتری است. در این مقاله، ما از مباحث بازاریابی عبور می‌کنیم و مستقیماً به قلب موتور فنی کش بک می‌رویم: معماری دیتابیس و چالش‌های بومی‌سازی آن در ایران.

 چرا معماری «اعتبار ساده» (Simple Credit) شکست می‌خورد؟

اگر فقط موجودی کاربر را در یک فیلد credit آپدیت کنید، خود را درگیر یک کابوس فنی کرده‌اید که به سرعت رشد کسب‌وکار شما را متوقف می‌کند:

• عدم شفافیت (No Audit Trail): کاربر می‌پرسد “اعتبار ۱۵ هزار تومانی من از کجا آمده؟” شما هیچ تاریخی جز یک عدد نهایی ندارید. این یعنی عدم اعتماد مشتری و مشکل در پشتیبانی.
• مشکل در مرجوعی (Refund Hell): مدیریت بازگشت کالا و کسر اعتبار کش بک (که شاید قبلاً خرج شده) تقریباً غیرممکن می‌شود.
• Race Conditions: در تراکنش‌های همزمان (مثلاً کاربر همزمان خرید می‌کند و اعتبار خرج می‌کند)، محاسبه موجودی نهایی دچار خطا می‌شود.
• مدیریت انقضا (Expiration): نمی‌توانید بخشی از موجودی را منقضی کنید. اگر کاربر ۱۰۰ هزار تومان اعتبار داشته باشد که ۵۰ هزار تومان آن این ماه منقضی می‌شود، چطور می‌خواهید این را مدیریت کنید؟
• عدم مقیاس‌پذیری (Scalability): با رشد کسب‌وکار، شما کمپین‌های مختلف می‌خواهید. مدیریت کمپین‌های همزمان، کش‌بک‌های با انقضای متفاوت و… با یک فیلد ساده، غیرممکن است.

پیاده سازی فنی سیستم کش بک به روش اصولی، نیازمند یک «منبع واحد حقیقت» (Single Source of Truth) است.

 معماری صحیح: سیستم دفتر کل (Cashback Ledger)

راه‌حل صحیح، استفاده از معماری دفتر کل (Ledger) است. این دقیقاً همان سیستمی است که بانک‌ها برای مدیریت حساب شما استفاده می‌کنند.

قانون اصلی Ledger: شما هرگز دیتای مالی را «آپدیت» یا «حذف» نمی‌کنید؛ شما فقط رکوردهای جدید «اضافه» می‌کنید (Immutable Log).

موجودی کش بک کاربر، یک فیلد در دیتابیس نیست؛ بلکه SUM() تمام تراکنش‌های او در جدول Ledger است.

“دفتر کل وفاداری، رکوردی غیرقابل تغییر و دارای مهر زمانی از تمام تراکنش‌ها است. به آن مانند صورتحساب بانکی برای امتیازات وفاداری فکر کنید که یک منبع واحد حقیقت و قابلیت ردیابی کامل را فراهم می‌کند.” – منبع: Antavo (پلتفرم وفاداری)

این رویکرد که به عنوان “Event Sourcing” نیز شناخته می‌شود، به شما اجازه می‌دهد تا وضعیت سیستم (موجودی کاربر) را در هر نقطه از زمان بازسازی کنید.

طراحی جدول Cashback_Ledger (نمونه ساختار SQL)

یک پیاده سازی فنی سیستم کش بک قوی با این جدول شروع می‌شود. این یک نمونه ساختار پیشنهادی برای MySQL یا PostgreSQL است:

CREATE TABLE Cashback_Ledger (

id BIGINT PRIMARY KEY AUTO_INCREMENT,

user_id INT NOT NULL,

order_id INT NULL, — برای ردیابی سفارش (اگر NULL باشد یعنی دستی است)

amount DECIMAL(10, 2) NOT NULL, — می‌تواند مثبت (واریز) یا منفی (خرج/انقضا) باشد

type ENUM(‘earn’, ‘spend’, ‘refund’, ‘expire’, ‘adjustment’) NOT NULL,

status ENUM(‘pending’, ‘cleared’, ‘cancelled’) NOT NULL DEFAULT ‘pending’,

expires_at TIMESTAMP NULL, — تاریخ انقضا

created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,

notes VARCHAR(255) NULL, — توضیحات (مثلا: بابت کمپین یلدا)

FOREIGN KEY (user_id) REFERENCES users(id)

);

نکات فنی این جدول:

• چرا DECIMAL(10, 2)؟ هرگز برای داده‌های مالی از Float یا Double به دلیل خطاهای محاسباتی ممیز شناور استفاده نکنید. DECIMAL دقت را تضمین می‌کند.
• چرا order_id می‌تواند NULL باشد؟ تا بتوانید تراکنش‌های دستی (مانند هدیه تولد یا adjustment توسط ادمین) را نیز بدون وابستگی به سفارش ثبت کنید.

 مزایای کلیدی معماری Ledger

1. حسابرسی کامل: شما تاریخچه تمام تراکنش‌ها را دارید.
2. مدیریت آسان مرجوعی: کافی است یک تراکنش منفی از نوع refund با amount منفی و مرتبط با همان order_id ثبت کنید.
3. شفافیت برای کاربر: کاربر تاریخچه کامل اعتبار خود را می‌بیند (“دریافت بابت سفارش X”، “خرج بابت سفارش Y”).
4. جلوگیری از تقلب: دستکاری موجودی غیرممکن می‌شود؛ همه‌چیز ردیابی‌پذیر است.

چالش‌های بومی: پیاده سازی کش بک در وب‌سایت‌های ایرانی

این معماری عالی است، اما چطور آن را در اکوسیستم ایران (با درگاه‌های پرداخت، قوانین مرجوعی و چالش‌های امنیتی) پیاده کنیم؟

 ۱. چالش اصلی: اتصال به درگاه پرداخت و «زمان تسویه»

بزرگترین چالش اتصال کش بک به درگاه پرداخت است. شما نباید به محض بازگشت کاربر از درگاه، کش بک را واریز (Cleared) کنید.

چرا؟ چون کاربر ۷ تا ۱۴ روز (بسته به کسب‌وکار شما) فرصت مرجوعی کالا را دارد.

راهکار فنی (وضعیت Pending):

1. پرداخت موفق (Callback): کاربر از درگاه برمی‌گردد. تراکنش موفق است.
2. ایجاد ردیف Pending: شما یک ردیف در جدول Cashback_Ledger با مبلغ محاسبه‌شده و وضعیت status = ‘pending’ ایجاد می‌کنید.
3. نمایش به کاربر: به کاربر اطلاع می‌دهید: “۱۵,۰۰۰ تومان کش بک در انتظار تایید برای شما ثبت شد.” (این اعتبار قابل خرج کردن نیست).
4. Cron Job (پردازش دسته‌ای): یک اسکریپت زمان‌بندی شده (Cron Job یا Task Scheduler) هر شب اجرا می‌شود.
5. بررسی سفارش‌ها: این Job تمام سفارش‌هایی که مثلاً ۱۴ روز از تاریخ تحویل آن‌ها گذشته و مرجوع نشده‌اند را پیدا می‌کند.
6. تغییر وضعیت: status رکوردهای Ledger مرتبط با آن سفارش‌ها را از pending به cleared تغییر می‌دهد.
7. تکمیل فرآیند: اکنون اعتبار برای کاربر قابل استفاده است. موجودی قابل خرج کاربر برابر است با: SUM(amount) WHERE user_id = X AND status = ‘cleared’

 ۲. چالش امنیتی: جلوگیری از تقلب (Fraud Prevention)

یک پیاده سازی فنی سیستم کش بک باید از روز اول امن باشد. هکرها عاشق سیستم‌های مالی هستند.

“وقتی با پول سروکار دارید، هرگز به ورودی کاربر اعتماد نکنید. هر محاسبه‌ای باید در سمت سرور و پس از چندین لایه اعتبارسنجی انجام شود.” – اصل اساسی امنیت وب

• اعتبارسنجی سمت سرور: هرگز به کلاینت (اپلیکیشن یا مرورگر) برای محاسبه مبلغ کش بک اعتماد نکنید. تمام محاسبات باید ۱۰۰٪ در بک‌اند و پس از تایید نهایی تراکنش از طریق وب‌سرویس درگاه پرداخت (Verify) انجام شود.
• جلوگیری از درخواست‌های تکراری (Duplicate Earn): مطمئن شوید که برای یک order_id واحد، فقط یک بار کش بک از نوع earn ثبت می‌شود. (ایجاد یک Unique Index در دیتابیس روی (order_id, type) برای رکوردهایی که type=’earn’ است، راهکار خوبی است).
• Rate Limiting: جلوی حملات Brute Force برای خرج کردن اعتبار یا تست کردن سیستم را با محدود کردن تعداد درخواست‌های کاربر در یک بازه زمانی بگیرید.

 ۳. ساخت موتور قوانین (Rule Engine)

شما نمی‌خواهید کش بک ثابت بدهید. معماری سیستم کش بک شما باید یک موتور قوانین ساده داشته باشد. به جای کدنویسی سخت (Hardcode)، از یک جدول در دیتابیس برای مدیریت قوانین استفاده کنید:

جدول نمونه Cashback_Rules

فیلد اولویت (Priority) در اینجا حیاتی است. این فیلد مشخص می‌کند که اگر دو قانون همزمان برای یک محصول اعمال شدند (مثلاً هم کمپین یلدا و هم کاربر VIP)، کدام قانون اجرا شود یا چگونه با هم ترکیب شوند (مثلاً اولویت 0 بالاترین است).

 ۴. مدیریت انقضا (Expiration)

کش بک برای شما یک «بدهی مالی» (Liability) است. باید منقضی شود.

• راهکار: همان Cron Job که وضعیت‌ها را cleared می‌کند، می‌تواند رکوردهایی که expires_at آن‌ها فرا رسیده و هنوز status = ‘cleared’ هستند را پیدا کند.
• سپس به ازای هر کدام، یک ردیف منفی جدید از نوع type = ‘expire’ ثبت می‌کند تا موجودی کاربر به صورت شفاف کسر شود.

 جمع‌بندی: کش بک فنی، یک سرمایه‌گذاری است نه هزینه

پیاده سازی فنی سیستم کش بک اگر با عجله و با مدل «اعتبار ساده» انجام شود، تبدیل به یک بدهی فنی (Technical Debt) بزرگ خواهد شد. اما اگر از ابتدا بر پایه معماری Ledger ساخته شود، سیستمی مقیاس‌پذیر، شفاف و قابل اعتماد خواهید داشت که هم تیم مالی شما را راضی نگه می‌دارد و هم اعتمادسازی واقعی برای مشتری ایجاد می‌کند.

برای مطالعه بیشتر در مورد جنبه‌های مختلف پیاده‌سازی اپلیکیشن‌های وفاداری، می‌توانید این راهنمای جامع از RaftLabs را بررسی کنید.

 قدم بعدی شما چیست؟ 

پیاده‌سازی یک سیستم کش بک قوی، اولین قدم برای ساخت یک باشگاه مشتریان وفادار است.

• مطالعه بیشتر: برای درک عمیق‌تر از جنبه‌های استراتژیک این سیستم، راهنمای کامل ما در مورد برنامه‌های کش بک (Cashback Program) را از دست ندهید.
• اقدام عملی: آیا آماده‌اید باشگاه مشتریان خود را به سطح بعدی ببرید؟ سری به مقالات تخصصی ما در بخش باشگاه مشتریان بزنید.
• کاوش بیشتر: برای مشاهده تمام مقالات و تحلیل‌های ما، به صفحه اصلی بلاگ مراجعه کنی