מערכת אישור תשלומי קריפטו עם הגנה מפני ארגון מחדש

פיתוח מערכת אישור תשלומי קריפטו

תארו לעצמכם שלקוח משלם עבור הזמנה ב-USDT על Polygon, אבל כעבור דקה הרשת מבצעת ריאורגניזציה — העסקה נעלמת. כבר שלחתם את ההזמנה, אבל הכסף מעולם לא הגיע. מערכת אישור תשלומים אמינה היא לא רק בדיקת hash; היא מכונת מצבים סופית עם מעברי מצב מפורשים והגנה מפני כל מקרי הקצה. היישום שלנו משתמש במוניטורים נפרדים לכל רשת, בחלון סובלנות לטיפול בתנודות סכומים, וב-idempotency ברמת txHash. לדוגמה, על Ethereum PoS אנו דורשים 12 אישורים (זמן בלוק ממוצע של 12 שניות), מה שמספק אמינות דומה לסליקה בנקאית אבל מהירה פי 10.

אנו בונים מערכות כאלה מאפס או משתלבות בתשתית קיימת. אנו מסתמכים על המפרטים EIP-1559 ו-Ethereum JSON-RPC API לעיבוד עסקאות נכון. חיסכון בעלויות תפעול על עיבוד תשלומים יכול להגיע ל-$2,000 בחודש. המערכת בדרך כלל מחזירה את ההשקעה תוך 3–4 חודשים. אספקת מפתח ב-2–4 שבועות. צרו קשר כדי לדון בתרחיש שלכם.

באיזו בעיה אנו פותרים?

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

• ריאורגניזציה: בלוק ננטש, עסקה נעלמת. ללא החזרת סטטוס, אתם מזכים כספים שלא קיימים.
• נקודה צפה: המרה דרך wei מציגה שגיאות עיגול; המשתמש משלם 47.50 USDT, אבל המערכת רואה 47.499999.
• עמלות החלפה: הסכום המועבר נמוך ב-1–2% מהצפוי.
• פסקי זמן של סשן: התשלום מגיע אחרי מגבלת הזמן, והכתובת כבר לא תקפה.

כל אחת מהבעיות הללו נפתרת במסגרת מודל מצבים סופי אחיד.

כיצד המערכת מגנה מפני ריאורגניזציה?

ריאורגניזציה היא ארגון מחדש של שרשרת שבו בלוק שהתקבל בעבר מוחלף באחר. על Ethereum PoS זה לא סביר (עומק 1–2 בלוקים), על Polygon זה נפוץ יותר. הגישה שלנו: בכל בדיקת אישור, אנו מביאים קבלה עסקה טרייה. אם הקבלה נעלמת, הסטטוס חוזר ל-DETECTED, המונה מתאפס, והמוניטור מתחיל לחפש מחדש.

async function processConfirmations(paymentId: string) { const payment = await db.findPayment(paymentId); const currentBlock = await provider.getBlockNumber(); const receipt = await provider.getTransactionReceipt(payment.txHash); if (!receipt) { await db.updatePayment(paymentId, { status: 'DETECTED', confirmations: 0, reorgDetected: true, }); return; } const confirmations = currentBlock - receipt.blockNumber + 1; const isConfirmed = confirmations >= payment.requiredConfirmations; await db.updatePayment(paymentId, { confirmations, status: isConfirmed ? 'CONFIRMED' : 'CONFIRMING', confirmedAt: isConfirmed ? new Date() : null, }); } 

תשלומים בסטטוס CONFIRMING נבדקים מחדש כל N בלוקים — אנחנו אף פעם לא סומכים על נתונים מיושנים.

מה אם המשתמש שולח פחות או יותר?

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

function isAmountSufficient( received: bigint, expected: bigint, toleranceBps: number = 50 ): 'exact' | 'underpaid' | 'overpaid' { const tolerance = expected * BigInt(toleranceBps) / 10000n; const min = expected - tolerance; const max = expected + expected / 10n; if (received >= min && received <= max) return 'exact'; if (received < min) return 'underpaid'; return 'overpaid'; } 

בתשלום חסר, המערכת מודיעה למפעיל; בתשלום יתר (עד 10%), היא מקבלת את התשלום וזוכה את העודף ליתרת המשתמש או מייצרת החזר.

מכונת מצבי תשלום

כל תשלום עובר דרך מצבים מוגדרים בהחלט: PENDING → DETECTED → CONFIRMING → CONFIRMED → SETTLED ↓ ↓ EXPIRED UNDERPAID / OVERPAID ↓ REFUNDED

ארכיטקטורת מוניטור בלוקצ'יין

ניטור מונוליטי של כל הרשתות בתהליך אחד הוא רעיון רע. אנו משתמשים ב-worker נפרד לכל רשת עם מנגנון ניסיון חוזר עצמאי. יישום לרשתות EVM:

interface ChainMonitor { network: string; start(): Promise<void>; stop(): void; onTransaction(handler: (tx: IncomingTransaction) => Promise<void>): void; } class EvmChainMonitor implements ChainMonitor { private provider: ethers.JsonRpcProvider; private watchedAddresses = new Set<string>(); async start() { const activePayments = await db.query( "SELECT address FROM payments WHERE status IN ('PENDING', 'DETECTING', 'CONFIRMING')" ); activePayments.rows.forEach(p => this.watchedAddresses.add(p.address)); this.provider.on('block', async (blockNumber) => { await this.processBlock(blockNumber); }); } private async processBlock(blockNumber: number) { const block = await this.provider.getBlock(blockNumber, true); for (const tx of block.transactions) { if (tx.to && this.watchedAddresses.has(tx.to.toLowerCase())) { await this.handleNativeTransfer(tx, blockNumber); } } await this.scanErc20Transfers(blockNumber); } } 

דרישות אישור לרשתות שונות

Idempotency והגנה מפני כפילויות

txHash אחד חייב להיות מזוכה בדיוק פעם אחת. אנו משתמשים ב-INSERT עם ON CONFLICT DO NOTHING: אם אותו hash כבר עובד, זה מחזיר תוצאה ריקה.

INSERT INTO payment_transactions (payment_id, tx_hash, amount, block_number) VALUES ($1, $2, $3, $4) ON CONFLICT (tx_hash) DO NOTHING RETURNING id; 

התראות ו-Webhooks

לאחר מעבר ל-CONFIRMED — התראה מיידית למערכות חיצוניות דרך תור (Bull/BullMQ) עם backoff אקספוננציאלי. קריאת HTTP ישירה ב-handler של הבלוק תאבד אירועים בכשלים.

async function dispatchPaymentConfirmed(payment: Payment) { await eventBus.emit('payment.confirmed', { paymentId: payment.id, orderId: payment.orderId, amount: payment.receivedAmount, txHash: payment.txHash, }); if (payment.webhookUrl) { await webhookQueue.add('payment-webhook', { url: payment.webhookUrl, payload: { event: 'payment.confirmed', data: payment }, }, { attempts: 5, backoff: { type: 'exponential', delay: 2000 }, }); } } 

תהליך ותוצרים

1. ניתוח — אנו מפרקים את הדרישות העסקיות שלכם, מספר הרשתות, הטוקנים, תרחישי ההחזר.
2. עיצוב מכונת מצבים — חידוד מעברים, סובלנות, ספי אישורים.
3. יישום — כתיבת מוניטורים, handlers, webhooks, בדיקות אינטגרציה.
4. בדיקות — כיסוי מקרי קצה: ריאורגניזציה, תשלום חסר, פסק זמן, הוצאה כפולה.
5. פריסה וניטור — פריסה בתשתית שלכם, הגדרת התראות.

מה כלול בתוצאה:

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

הזמינו פיתוח מערכת לפרויקט שלכם — נכין הערכה מפורטת תוך יום אחד.

לוח זמנים ואחריות

זמן אספקה טיפוסי הוא 2 עד 4 שבועות, תלוי במספר הרשתות ובמורכבות הלוגיקה העסקית. התמחור מחושב באופן אישי, אבל אנחנו מבטיחים פירוט עלויות שקוף. אנו עובדים עם פרויקטי בלוקצ'יין למעלה מ-5 שנים ויישמנו עשרות מערכות כאלה. אנו מבטיחים פעולה יציבה בעומס של עד 10,000 עסקאות בשעה.

קבלו ייעוץ: כתבו לנו, ונעריך את הפרויקט שלכם בחינם.