B2BINPAY 26.3.1: Sender Addresses on Incoming Transfers, Support Inside the Account, Staff 2FA

Versions 26.2.17, 26.3.0 and 26.3.1 are live. Together they close the 26.2 line and open 26.3, and most of what changed answers a question the platform used to send you elsewhere to answer.

Who sent this payment? A deposit callback gave you the receiving address and the transaction hash. If your AML process needed the sender, you went to a block explorer and looked it up by hand. Now every incoming transfer carries its sender addresses, in the API and in the callback, and your integration needs no changes to start receiving them.

Where do I ask about this? Support lived in email and in a separate knowledge base you had to go find. Now there is a support messenger on every page of the platform, and a conversation opened there already knows which company and which user it belongs to.

And for the people who run a platform rather than use one: staff accounts in the admin panel can carry their own second factor.

The sender address of every incoming payment

Transfer objects have a new sender_addresses attribute, an array of strings. On Ethereum-like networks that is one address. On Bitcoin-like networks it is every unique input address of the transaction. For token transfers the address comes from the token transfer event rather than the transaction sender, which matters: a token moved by a contract has a transaction sender that is not the payer.

The field appears everywhere a transfer is serialised — GET /transfer/, deposit callbacks with their nested transfer, and transfer callbacks. Adding a field is backward compatible, so nothing on your side breaks and nothing has to be updated to receive it; risk_status arrived the same way. A Sender Address column has been added to the transfer tables in both the Client UI and the admin panel.

Two limits worth knowing before you build on it. Only new incoming transactions are populated, and historical transfers are not backfilled, so a reconciliation process that reaches into the past still needs its old path for old records. And on a Bitcoin-like transaction with many inputs the array is correspondingly long; treat it as a set to check against your lists, not as a single counterparty.

Support, inside the account

A support messenger appears on all authorised pages of the account. Conversations and tickets are attributed to your user and your company, so the first three messages are no longer spent establishing who is asking about which account. Switching legal entity or signing out ends the session and clears the widget’s cookies, and the widget follows your light or dark theme.

It also fails open. If the messenger service is unreachable, the page loads as before, with no error banners and no retry loops. Support notification emails changed to match: they show the support email address directly rather than pointing at the knowledge base.

Commissions, second pass

The Commissions tab from 26.2.10 reflects personal Enterprise rates rather than only the standard ladder, so an account with negotiated pricing sees its own numbers. The bank fees block is hidden when bank details are switched off for the account, instead of displaying a section that does not apply.

Address whitelist: two gaps closed

POST to the address whitelist accepted any string as an address, with no format validation at all. It validates now. And searching the whitelist by address failed to match anything shorter than 26 characters, which quietly excluded the short addresses on several networks from search results. Both are fixed.

For white-label operators

Staff users get operational 2FA in the admin panel, enrolling and managing their own TOTP device, and a staff user without the right to view staff accounts can still reach their own profile to set it up. Staff auto-deactivation is now configurable through Live Settings, and the audit log stopped returning a server error for staff users, which happened because older role codes in existing records had no display mapping.

The Status page answers a question it could not answer before: has this service actually restarted, and when? Every process in the code base — web, Celery worker and beat, the blockchain consumer, the integration events consumer and the rates consumer — now reports its start time and a heartbeat, and each card shows start time, uptime, time since last update, and version. Figures appear only after a process restarts on the new version, so a freshly deployed card fills in as the processes cycle.

Two recurring manual interventions are now actions in the panel. A transportation parked by the collected-amount check, where the node swept more than the deposits registered at that moment, can be re-checked from the transfer’s node info page: the server recalculates the expected amount, including address-matched deposits, and compares it with the node using the same normalisation and tolerance as the original check. The review flag clears only when the amounts agree, so the button cannot be used to wave a real mismatch through. Previously this was cleared with SQL on production.

An AML withdrawal to an address belonging to the system is rejected with a clear message. One such return went to the same deposit address it was returning from: the funds never reached the sender, the node created a new deposit, that deposit failed as already swept, and a phantom side withdrawal sat unconfirmed until someone settled it by hand.

Also fixed: the Send funds page of a global wallet holding airdrop spam timed out behind Cloudflare, because every unknown asset triggered a synchronous node lookup whose negative result was never cached — negative verdicts are cached now, retries are out of the render path, and node calls share a five-second budget, with anything slower shown at default precision. The Global wallets staking page survives a single unresponsive node. An Action Request card for transfer creation always shows the Wallet ID and warns, by currency, when the receiving address has no wallet for the token that arrived, so the problem is visible before approval rather than after it. A side-collecting Solana transfer stopped hanging unconfirmed with an empty node ID, and merchant deposits on Solana without a collection window are picked up by the sweep collector. An incoming transfer confirms on the correct block rather than one later. And currency forms reject a connection on virtual and fiat currency types.

Version 26.3.1 are available now. Log in, or read the full release notes in the documentation.

‍