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

לעתים קרובות אנו שומעים מלקוחות: "אנחנו רוצים לקבל קריפטו באתר שלנו כמו Stripe רגיל, אבל בלי מתווכים." זה נשמע פשוט — רק לחבר מאזין בלוקצ'יין וליצור כתובות. אבל בייצור, צצות בעיות: זיהוי תשלומים בלי פולינג מתמיד, תנודתיות במהלך המרה, תשלומים חלקיים, ספי אישור ברשתות שונות, ו-idempotency בזמן כשלים. אנו מתמודדים עם תנודתיות על ידי קיבוע שער החליפין באמצעות Chainlink Price Feed. פירקנו כל אחת מהבעיות הללו בייצור ומציעים ארכיטקטורת turnkey. לצוות שלנו יש מעל 5 שנות ניסיון בפיתוח בלוקצ'יין ויישמנו מעל 20 אינטגרציות של שערי תשלום, תוך עיבוד של מעל 10 מיליון דולר בעסקאות קריפטו. חיסכון מביטול מתווכים יכול להגיע ל-2% מהמחזור (בממוצע 20,000 דולר בשנה עבור מחזור שנתי של מיליון דולר). צרו קשר לייעוץ להערכת הפרויקט שלכם.

איך שער תשלום קריפטו עובד

שער תשלום מינימלי בר-קיימא מורכב מארבעה רכיבים:

[Клиент] → [API Gateway] → [Payment Service]
↓
[Blockchain Listener]
↓
[Event Queue (Redis/Kafka)]
↓
[Settlement Service] → [ERP/CRM]

שירות תשלום — יוצר הזמנה, מייצר כתובת ייחודית (או מזהה תשלום), ומחזיר נתוני תשלום ללקוח. Stateful — מאחסן מיפוי [Клиент] → [API Gateway] → [Payment Service] ↓ [Blockchain Listener] ↓ [Event Queue (Redis/Kafka)] ↓ [Settlement Service] → [ERP/CRM] . מאזין בלוקצ'יין — עוקב אחר עסקאות נכנסות. זהו הרכיב הקריטי ביותר לאמינות. שתי גישות:

1. מנוי WebSocket (address → order או eth_subscribe("logs", filter)) — זמן השהיה נמוך (פי 10 מהר יותר מפולינג), אבל חיבורים נשברים; צריך reconnect עם backoff והפעלה חוזרת של בלוקים שהוחמצו.
2. פולינג + cursor — פחות אלגנטי אבל צפוי. אחסן את הבלוק האחרון שעובד, בצע פולינג ל-eth_subscribe("newHeads") עם פילטר לפי כתובות. עמיד יותר לכשלי רשת.

לייצור: גישה היברידית — WebSocket לזמן השהיה נמוך, פולינג כגיבוי עם שחזור מבוסס cursor.

תור אירועים — חיץ בין המאזין לסילוק. Kafka לעומסים גבוהים, Redis Streams לעומסים בינוניים. נקודה מרכזית: המאזין מפרסם אירוע eth_getLogs, שירות הסילוק נרשם. זה מפריד בין רכיבים ומבטיח עיבוד גם אם שירות הסילוק נופל זמנית.

שירות סילוק — בודק אישורים, ממיר סכומים, מעדכן סטטוס הזמנה, ומודיע למערכת העליונה (webhook).

למה זיהוי שער תשלום קריפטו מותאם אישית הוא הרכיב הקשה ביותר

רשתות EVM (ETH, BNB, Polygon, Arbitrum, ...) וזיהוי עסקאות EVM

העברות ETH מקוריות: ניטור דרך TransactionDetected + eth_subscribe("newHeads") וסינון עסקאות לפי כתובת eth_getBlockByNumber.

ERC-20 טוקנים (USDT, USDC, DAI): ניטור אירוע to דרך Transfer(address indexed from, address indexed to, uint256 value) עם פילטר:

const filter = {
  fromBlock: 'latest',
  topics: [
    ethers.id('Transfer(address,address,uint256)'),
    null, // from: любой
    ethers.zeroPadValue(paymentAddress, 32), // to: наш адрес
  ],
};

חשוב עבור USDT (Tether): יש לו ERC-20 לא סטנדרטי — הפונקציה eth_getLogs לא מחזירה const filter = { fromBlock: 'latest', topics: [ ethers.id('Transfer(address,address,uint256)'), null, // from: любой ethers.zeroPadValue(paymentAddress, 32), // to: наш адрес ], }; . קריאה דרך הממשק הסטנדרטי תגרום ל-revert. השתמשו ב-transfer או בקריאה ברמה נמוכה עם בדיקת נתוני החזרה.

שער תשלום ביטקוין ומודל UTXO

עבור BTC אין מושג "כתובת → עסקה" ברמת הצומת. השתמשו באחת מהאפשרויות:

• Electrum Server (Electrs) — מאנדקס UTXO לפי כתובות, מאפשר מנוי לכתובת
• BlockCypher / Blockcypher WebHook API — פתרון hosted אבל תלות בצד שלישי
• Bitcoin Core עם bool — הוסיפו את הכתובת לצומת הארנק, קבלו התראות דרך ZMQ

אישורים מינימליים עבור BTC: 1 לסכומים קטנים (<100 דולר), 3 לבינוניים, 6 לגדולים. עבור Ethereum, 12–20 בלוקים מספיקים.

תשלום TON

עסקאות TON הן אסינכרוניות: העברה נכנסת היא הודעה עם אפשרות bounce, ויש לוודא שזו העברה ולא bounce. השתמשו ב-TonAPI או ב-TON Center API עם webhook על הכתובת.

איך להבטיח Idempotency של Webhook (ערבות 100% ל-Idempotency)

התראות למערכת העליונה דרך webhook חייבות להיות idempotent — משלוחים כפולים בניסיונות חוזרים אפשריים. כללו safeTransfer (ייחודי) + importaddress + payment_id ב-payload. המערכת העליונה חייבת לבדוק אם כבר עיבדה את tx_hash הזה. מדיניות ניסיונות חוזרים: exponential backoff, 5–10 ניסיונות, ואז תור dead letter לבדיקה ידנית.

סף אישור והגנה מפני Double-Spend

לעולם אל תחשבו שתשלום הושלם אחרי זיהוי ראשון של עסקה ב-mempool — זה מצב status, לא מאושר. ספים מינימליים:

תשלומים חלקיים ותשלומי יתר

משתמשים אמיתיים לפעמים משלמים סכום שגוי — בורסות מנכות עמלות, אנשים עושים טעויות. יש צורך במדיניות:

• תשלום חסר: אם התקבל 99–100% מהסכום — התייחסו כאל שולם (סובלנות של 1%). אם פחות — payment_id, חכו 30 דקות להשלמה, ואז pending.
• תשלום יתר: קבלו אוטומטית, החזירו את ההפרש (דורש תהליך החזר) או זיכו כהערת זיכוי.

השוואת גישות זיהוי

---
# config.yml
listener:
  networks:
    - name: ethereum
      rpc: wss://eth-mainnet.g.alchemy.com/v2/YOUR_API_KEY
      polling_interval: 12s
      confirmations: 12
      addresses:
        - 0xYourPaymentAddress
    - name: bitcoin
      rpc: http://user:pass@localhost:18332
      confirmations: 3
      addresses:
        - bc1q...
    - name: polygon
      rpc: wss://polygon-mainnet.infura.io/ws/v3/YOUR_KEY
      confirmations: 128
      addresses:
        - 0x...