nick/nick-doc
3
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

docs: sync from backend 3e9a2f2 — BSC Testnet tUSDT rail

Browse Source
This commit is contained in:
Siavash Sameni
2026-06-06 08:20:55 +04:00
parent cafef04a75
commit 641334a2e5
3 changed files with 23 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
04 - Flows/Payment Flow - Scanner.md
View File

@@ -6,7 +6,7 @@ created: 2026-05-30
# Payment Flow — AMN Pay Scanner (In-House)
> **Last updated:** 2026-06-06 — documented backend/frontend `2.8.115` and scanner `0.1.10` BSC Testnet rail alignment.
> **Last updated:** 2026-06-06 — documented backend/frontend `2.8.116` and scanner BSC Testnet tUSDT rail correction.
End-to-end payment flow using the in-house AMN Pay Scanner, replacing the Request Network integration. The scanner is a separate microservice; the backend talks to it over an internal HTTP API.
@@ -76,12 +76,14 @@ For dev end-to-end testing, backend and scanner must keep the chain 97 registry
| Chain id | `97` |
| Network aliases | `bsc-testnet`, `bnb-testnet`, `bsctest`, `bsc_testnet`, `binance-testnet`, `bnbt`, numeric string `97` |
| RPC fallback | `https://bsc-testnet-rpc.publicnode.com` |
| USDT test token | `0x337610d27c682E347C9cD60BD4b3b107C9d34dDd` |
| USDT test token | `0x109F54Dab34426D5477986b0460aE5dFBA65f022` |
| USDC test token | `0x64544969ed7EBf5f083679233325356EbE738930` |
| Token decimals | `18` for USDT and USDC |
| Default confirmation floor | `5` |
Backend `2.8.115+` uses this same token address in both the Request Network/scanner intent registry and the legacy `BSCTransactionVerifier` path. This matters because `/api/payment/request-network/intents` resolves the buyer's selected chain/token before asking scanner to watch, while older wallet-direct verification endpoints call `BSCTransactionVerifier.verifyTransfer()` directly. A mismatch between these two registries will either create scanner intents for a token that the buyer does not pay, or verify the wrong ERC-20 contract after payment.
Backend `2.8.116+` uses this same token address in both the Request Network/scanner intent registry and the legacy `BSCTransactionVerifier` path. This matters because `/api/payment/request-network/intents` resolves the buyer's selected chain/token before asking scanner to watch, while older wallet-direct verification endpoints call `BSCTransactionVerifier.verifyTransfer()` directly. A mismatch between these two registries will either create scanner intents for a token that the buyer does not pay, or verify the wrong ERC-20 contract after payment.
Backend `2.8.116+` also passes an explicit `scannerContext` (`paymentId`, `chainId`, `tokenSymbol`, `tokenAddress`, `destination`) into AMN scanner intent registration. This prevents PG-only or partially hydrated payment reads from falling back to the global merchant reference and creating mainnet/default-style scanner intents such as `undefined-c56-USDC`.
If a live dev stack still waits for `200` confirmations on chain 97, check the admin runtime setting `confirmation_threshold:97`. Built-in default is now `5`, but a previously persisted admin value above the floor still wins until updated.