ตรวจสอบการฝากและการจ่ายเงิน USDT / USDC
ตรวจสอบการโอน USDT และ USDC ที่รองรับสำหรับการฝาก การแจ้งเตือนร้านค้า และการจ่ายเงิน การแจ้งเตือนเพียงอย่างเดียวไม่ได้ถือเป็นการชำระบัญชีขั้นสุดท้าย
สำหรับนักพัฒนาและ AI Agent เริ่มต้นด้วย API key ของคุณและตัวรับ HTTPS กรอง contract โทเค็นและจำนวนเงินในแอปพลิเคชันของคุณ
การตรวจสอบการโอนขั้นพื้นฐานพร้อมใช้งานแล้วการกรองจำนวนเงินและโทเค็นจะทำงานที่ฝั่งตัวรับ (receiver) ของคุณ เงื่อนไขฝั่งเซิร์ฟเวอร์ การยืนยันหลายขั้นตอน และการแจ้งเตือนผ่าน IM จะพร้อมใช้งานเร็ว ๆ นี้
ก่อนเริ่มต้นใช้งาน
นักพัฒนาและ AI Agent ใช้ขั้นตอนการตั้งค่าเดียวกัน ตั้งค่า BLOCKVECTRA_API_KEY อย่างปลอดภัย และติดตั้ง curl กับ jq เลือก CHAIN จากความครอบคลุมของงานด้านล่าง ตรวจสอบ contract โทเค็นบนเชนนั้น ผู้รับ และจำนวนเต็มในหน่วยที่เล็กที่สุด สำหรับ Push ให้ deploy ตัวรับ HTTPS ของคุณเองบนพอร์ต 443 และตรวจสอบรายการเชนที่ผ่านการรับรองความถูกต้อง ช่วงการยืนยัน และสถานะ halted ก่อนสร้าง subscription
ดูคู่มือการลงทะเบียนแบบเป็นโปรแกรม (programmatic) →ตรวจสอบการฝากเงินของศูนย์ซื้อขาย
Poll ข้อมูลล็อก ERC-20 Transfer สำหรับ address การฝากของคุณ กำหนดค่า TOKEN_CONTRACT และ RECIPIENT จากการกำหนดค่าการชำระเงินที่เชื่อถือได้ กำหนดค่า FROM_BLOCK และ TO_BLOCK เป็นความสูงบล็อกในรูปแบบเลขฐานสิบหก (hex) ภายในขอบเขตของโหนดและขีดจำกัดช่วงบล็อกที่เผยแพร่ เลื่อนเคอร์เซอร์ที่คงทน (durable cursor) หลังจากประมวลผลแต่ละช่วงแล้วเท่านั้น
เชนที่รองรับ
set -euo pipefail
: "${BLOCKVECTRA_API_KEY:?}" "${CHAIN:?}" "${TOKEN_CONTRACT:?}" "${RECIPIENT:?}"
: "${FROM_BLOCK:?}" "${TO_BLOCK:?}"
TOPIC_TO="0x000000000000000000000000${RECIPIENT#0x}"
jq -n --arg token "$TOKEN_CONTRACT" --arg to "$TOPIC_TO" \
--arg from "$FROM_BLOCK" --arg end "$TO_BLOCK" \
'{jsonrpc:"2.0",id:1,method:"eth_getLogs",params:[{address:$token,
fromBlock:$from,toBlock:$end,topics:[
"0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",null,$to]}]}' |
curl --fail-with-body -sS "https://api.blockvectra.com/v1/$CHAIN" \
-H "x-api-key: $BLOCKVECTRA_API_KEY" -H 'Content-Type: application/json' --data-binary @-ผลลัพธ์ที่ต้องตรวจสอบ
จับคู่ contract, ผู้รับ และจำนวนเต็ม ตรวจสอบใบเสร็จ (receipt) และนโยบายการยืนยันของคุณก่อนบันทึกยอด ตัดรายการซ้ำตามเชน, transactionHash และ logIndex โดยคงค่า blockHash ไว้เพื่อจัดการกับการจัดระเบียบใหม่ (reorgs)
อ่านคู่มือฉบับเต็มรับการแจ้งเตือนการชำระเงินของร้านค้า
กำหนดค่า RECIPIENT และ RECEIVER_URL จากนั้นสร้าง address subscription ขั้นพื้นฐานด้วยจำนวนการยืนยันเริ่มต้นของเชน จัดเก็บ secret ที่ส่งคืนมาอย่างปลอดภัย รอให้ applied_version >= change_version และบันทึก applied_from_block ก่อนคาดหวังกิจกรรมที่ตรงกัน
เชนที่รองรับ
- Arbitrum One — ดำเนินการได้ในขณะนี้
- Base — ดำเนินการได้ในขณะนี้
- BNB Smart Chain — ดำเนินการได้ในขณะนี้
- Ethereum — ดำเนินการได้ในขณะนี้
- Ethereum Sepolia — ดำเนินการได้ในขณะนี้
- HyperEVM — ดำเนินการได้ในขณะนี้
- Polygon — ดำเนินการได้ในขณะนี้
- Robinhood Chain — ดำเนินการได้ในขณะนี้
- Robinhood Chain Testnet — ดำเนินการได้ในขณะนี้
เลือก CHAIN สำหรับตัวอย่างนี้จากเชนที่สามารถดำเนินการได้ด้านล่าง
set -euo pipefail
umask 077
: "${BLOCKVECTRA_API_KEY:?}" "${CHAIN:?}" "${RECIPIENT:?}" "${RECEIVER_URL:?}"
PUSH_URL='https://api.blockvectra.com/v1/push'
curl --fail-with-body -sS "$PUSH_URL/chains" \
-H "x-api-key: $BLOCKVECTRA_API_KEY" > push-chains.json
jq -e --arg chain "$CHAIN" 'any(.chains[]; .chain == $chain and .halted == false)' push-chains.json
jq -n --arg url "$RECEIVER_URL" --arg chain "$CHAIN" \
'{url: $url, chains: {($chain): {}}}' > create.json
curl --fail-with-body -sS "$PUSH_URL/subscriptions" \
-H "x-api-key: $BLOCKVECTRA_API_KEY" \
-H 'Content-Type: application/json' -d @create.json > subscription.json
SUBSCRIPTION_ID=$(jq -er '.id' subscription.json)
jq -n --arg recipient "$RECIPIENT" '{addresses: [$recipient]}' > addresses.json
curl --fail-with-body -sS "$PUSH_URL/subscriptions/$SUBSCRIPTION_ID/addresses/add" \
-H "x-api-key: $BLOCKVECTRA_API_KEY" \
-H 'Content-Type: application/json' -d @addresses.json > address-change.json
curl --fail-with-body -sS "$PUSH_URL/subscriptions/$SUBSCRIPTION_ID" \
-H "x-api-key: $BLOCKVECTRA_API_KEY"ผลลัพธ์ที่ต้องตรวจสอบ
อีเวนต์ที่ตรงกันรายการแรกจะนับเฉพาะหลังจากตรวจสอบลายเซ็น raw-body การตรวจสอบโทเค็น/ผู้รับ/จำนวนเต็ม การตัดรายการซ้ำที่คงทนตาม event id และตัวรับตอบกลับ 2xx การได้รับ HTTP 201 ของ subscription ไม่ใช่การแจ้งเตือนการชำระเงินที่ส่งถึงแล้ว
อ่านคู่มือฉบับเต็มติดตามการจ่ายเงิน
กำหนดค่า TX_HASH เป็นธุรกรรมที่ส่งโดยระบบการชำระเงินของคุณแล้ว อ่านใบเสร็จ (receipt) ด้วย JSON-RPC เปรียบเทียบ receipt.blockNumber กับบล็อกล่าสุด (head) และกระทบยอดล็อกการโอนโทเค็นที่คาดหวัง
เชนที่รองรับ
set -euo pipefail
: "${BLOCKVECTRA_API_KEY:?}" "${CHAIN:?}" "${TX_HASH:?}"
jq -n --arg hash "$TX_HASH" \
'{jsonrpc:"2.0",id:1,method:"eth_getTransactionReceipt",params:[$hash]}' |
curl --fail-with-body -sS "https://api.blockvectra.com/v1/$CHAIN" \
-H "x-api-key: $BLOCKVECTRA_API_KEY" -H 'Content-Type: application/json' --data-binary @-ผลลัพธ์ที่ต้องตรวจสอบ
receipt ที่เป็น null หรือธุรกรรมที่รอดำเนินการ (pending) ไม่ถือเป็นการชำระเงินที่ได้รับแล้ว ตรวจสอบ receipt.status, contract โทเค็น, ผู้รับ, จำนวนเต็ม และนโยบายการยืนยันของคุณ การที่ receipt สำเร็จเพียงอย่างเดียวไม่ได้พิสูจน์ว่ามีการโอนเงินตามที่คาดหวัง
อ่านคู่มือฉบับเต็มขอบเขตการยืนยันและความครอบคลุม
การยืนยัน N บล็อกไม่ใช่ข้อยุติขั้นสุดท้าย (finality) ของเชน Push ขั้นพื้นฐานไม่มีการกรองจำนวนเงินหรือโทเค็นที่ฝั่งเซิร์ฟเวอร์ ให้กรองในตัวรับของคุณเอง การโอนเหรียญเนทีฟภายใน contract ไม่อยู่ในความครอบคลุม สถานะ Pending ไม่ใช่การชำระเงินที่ได้รับแล้ว กระทบยอดบล็อกที่ถูกแทนที่เมื่อเกิด chain.reorg และประมวลผลบล็อกที่เข้ามาแทนที่อย่างมีคุณสมบัติไม่เปลี่ยนค่าเมื่อทำซ้ำ (idempotently) บางเชนไม่รวมธุรกรรมระบบไว้ในความครอบคลุม โปรดดูหน้ารายละเอียดของเชนนั้น ๆ
กู้คืนช่องว่างและกระทบยอดประวัติ
Replay จะส่งซ้ำเฉพาะรายการที่ตรงกันที่ยังเก็บรักษาไว้เท่านั้น โดยจะไม่กู้คืนประวัติก่อนการเปิดใช้งาน subscription หรือ address ใช้การ poll RPC แบบมีขอบเขตสำหรับช่วงเวลาก่อนหน้าหรือช่องว่าง รักษาเคอร์เซอร์แยกตามเชนและกระทบยอดการจัดระเบียบใหม่ (reorgs) ตามคู่มือฉบับเต็ม
เชนที่รองรับ
สามารถสืบค้นการโอน ERC-20 ที่ทำดัชนีไว้บนเชนด้านล่างได้ กำหนดค่า FROM_BLOCK และ TO_BLOCK เป็นความสูงบล็อกในรูปแบบเลขฐานสิบภายในขอบเขตที่มีการทำดัชนี ตรวจสอบความสดใหม่และความครอบคลุม และติดตาม next_cursor จนกระทั่งไม่มีค่า ตรวจสอบแต่ละ contract โทเค็น, ผู้รับ และจำนวนเต็ม ข้อมูลที่มีการทำดัชนีไม่ใช่หลักฐานของข้อยุติขั้นสุดท้าย (finality)
: "${BLOCKVECTRA_API_KEY:?}" "${CHAIN:?}" "${RECIPIENT:?}" "${FROM_BLOCK:?}" "${TO_BLOCK:?}"
curl --fail-with-body -sS --get \
"https://api.blockvectra.com/v1/data/$CHAIN/addresses/$RECIPIENT/transfers" \
-H "x-api-key: $BLOCKVECTRA_API_KEY" \
--data-urlencode 'standard=erc20' --data-urlencode 'direction=in' \
--data-urlencode "from_block=$FROM_BLOCK" --data-urlencode "to_block=$TO_BLOCK"กฎเกณฑ์ราคาและการเรียกเก็บเงิน
น้ำหนักเมธอด eth_getLogs: 30 CU ($3.00 ต่อ 1,000,000 คำขอ)
คำขอที่ถูกปฏิเสธโดยบริการ (เช่น เกินช่วงบล็อกที่กำหนด หรือถูกจำกัดอัตรา) จะไม่ถูกเรียกเก็บเงิน ดูที่ คู่มือกฎการเรียกเก็บเงิน หรือดู ตารางราคาฉบับเต็ม
Webhook push
น้ำหนัก CU จาก GET /v1/plans การลองส่งใหม่โดยอัตโนมัติฟรี
addresses ฟรีต่อบัญชีต่อวัน UTC: 1000
โควตา address ฟรีต่อบัญชีต่อวัน UTC ซึ่งแชร์ร่วมกันโดยกลุ่ม subscription ทั้งหมดไม่ว่าจะใช้แพ็กเกจใด สำหรับแต่ละกลุ่ม จะนับจำนวน address สูงสุดขณะออนไลน์ในระหว่างวันนั้น จัดสรรโควตาตามลำดับ ID กลุ่มจากน้อยไปมาก address เดียวกันในสองกลุ่มจะถูกนับสองครั้ง จำนวนเชนในกลุ่มไม่ทำให้จำนวน address คูณเพิ่มขึ้น กลุ่มที่ออฟไลน์หรือถูกลบตลอดทั้งวันจะไม่ถูกนำมานับ สำหรับแต่ละกลุ่ม จำนวนที่เหลือหลังจากหักส่วนแบ่งโควตาแล้วจะคูณด้วยน้ำหนัก CU ของ `push.address_day` ใน `method_weights` โควตาที่กำหนดไว้ในปัจจุบันมาจากนโยบายการคิดราคาเดียวกับที่ใช้สำหรับค่าบริการ address-day ไม่ใช่ขีดจำกัดความจุของบัญชีหรือโควตาแยกต่างหากต่อกลุ่ม
| เมธอด | หน่วยการเรียกเก็บเงิน | CU |
|---|---|---|
| push.address_day | address-day ที่คิดค่าบริการ | 33 |
| push.history | คำขอดึงข้อมูลย้อนหลังที่สำเร็จ | 25 |
| push.log | อีเวนต์ข้อมูลที่ส่งสำเร็จ | 150 |
| push.native_transfer | อีเวนต์ข้อมูลที่ส่งสำเร็จ | 150 |
| push.token_transfer | อีเวนต์ข้อมูลที่ส่งสำเร็จ | 150 |