Bcon
PaymentsBcon is a non-custodial crypto payment gateway that settles directly into your own wallet. Agents create tracked payment addresses, check balances and transaction history, list stores and supported tokens, and convert token prices into fiat.
What This Integration Enables
Bcon is a non-custodial gateway, and that single fact rewrites the risk model. The money never touches the vendor. It goes straight to the merchant's own wallet, and Bcon's role is to watch an address and say when something arrived. There is no processor holding a balance, which means faster settlement and no counterparty sitting on your revenue. It also means there is nobody to call. No refund desk, no reversal, no reissue: a payment sent to the wrong place is simply gone, and the connector cannot see it at all, because it only watches the chains the connected store watches.
FlowRunner agents work with that grain rather than against it. An agent creates a tracked payment address with the exact amount and your own order reference attached. It converts a fiat price through the same rate feed the customer is charged at, so the two figures agree. It reads settled balances and transaction history, and holds release until the confirmation threshold is genuinely met. The one decision the connector cannot make safely for itself, which chain a token is accepted on, is exactly where human-in-the-loop belongs.
Without FlowRunner
With FlowRunner
Use Case Scenarios
-
An invoice that reconciles itself
An order in WooCommerce reaches checkout and the customer picks a token. The agent calls Get Exchange Rate first so the price it displays comes from the same feed the payment will be measured against, then Create Payment Address with the order id as the external reference and the fiat total as the origin amount, letting Bcon convert. The customer gets a fresh address and an exact figure, because Bcon matches on address and amount together and an approximate transfer is not matched at all. When the store's callback fires, the agent calls Get Transaction, waits for the confirmed state, releases the order, and writes the settled row to QuickBooks Online.
-
Two balances, read as two balances
Get Balance returns settled funds and funds still waiting on their second confirmation as separate numbers, which is the whole point of returning two. A nightly agent reads both and reports them separately in Google Sheets, so the treasury view shows what can be spent today and what is expected to clear. Because that operation covers Bitcoin only, the same run uses Get History for the other chains rather than summing balances that would silently contribute nothing. A total that quietly under-reports is worse than one that admits it is partial.
-
The blocked release
A transaction lands in the partially confirmed state and the order is high value. The agent does not release it. It posts the transaction, the current state, and the confirmation depth to the fulfilment channel in Slack, and holds the order until the confirmed state arrives or a person decides the risk is acceptable for that customer. Shipping on a transaction that can still be reversed is a decision, not a default, and this workflow makes somebody actually make it.
Human-in-Loop Highlight
The same ticker exists on four different chains with four different identifiers, and a Bcon API key belongs to one store and one chain. So the failure mode here is quiet and total: invoice a customer for a token on a chain the connected store does not watch, and the customer pays correctly, on time, to an address nobody is monitoring. Nothing errors. No callback fires. Get Transaction has nothing to return, because the payment happened somewhere the connector cannot see, and because the gateway is non-custodial there is no processor holding those funds to recover them from. The agent therefore never adds a token to checkout on its own. It reads List Currencies, which names the chain and network per entry, reads Get Store to confirm which chain the connected key is bound to, and posts: "Adding USDT to checkout. The store on this connection is watching TRC-20 on Tron. Three USDT entries exist for ERC-20, BEP-20, and SPL, and a customer paying on any of those pays into an address this store does not watch. Confirm TRC-20 as the accepted chain, or connect a second store key?" A person answers once, when the token is added, and every invoice afterward is safe. The agent does the watching. The pairing that decides where a customer's money goes gets a human name against it.
Agent Capabilities
9 actionsPayments
2- Create Payment Address Returns a fresh wallet address and the exact amount to send. Bcon matches a payment on address and amount together, so an approximate transfer is not matched to the invoice. Set the external reference on every call, because it is the only field carried through to the callback and it is what ties a notification back to the order.
- Create Test Payment Runs the vendor's payment simulation. The vendor publishes this route and the operation is useful, but unlike every other route here its existence could not be confirmed against the live host, so treat a failure as expected rather than as a fault and run the simulation from the Bcon dashboard instead.
Transactions
3- Get Balance Returns settled funds and funds still awaiting their second confirmation as two separate figures, which is the distinction between money you have and money you expect. The vendor documents this operation as Bitcoin only, so a cross-chain total built from it under-reports rather than errors.
- Get History Reads the transaction history for the connected store, which is the route to use for chains the balance operation does not cover.
- Get Transaction Reads one transaction and its confirmation state. Only the confirmed state means the vendor's two-confirmation threshold has been met, and the two states before it are not payment.
Stores
2- List Stores Lists the account's stores with their per-chain keys and callback URLs. The response carries live credentials in plain text, so treat it as a secret and keep it out of any step that persists its input.
- Get Store Reads the store the connected key belongs to. It needs no identifier, because the key itself decides which store every call acts on.
Reference
2- List Currencies Lists the supported tokens with their chain and network. The read that keeps a ticker from being invoiced on a chain the store does not watch.
- Get Exchange Rate Converts a token price into ordinary currency from the same feed Bcon charges against, so the figure a customer sees and the figure they pay agree. The fiat currency is required rather than defaulted, and a missing one is refused in a way that reads as a bad token.
Frequently Asked Questions
What can FlowRunner do with Bcon?
FlowRunner agents can run Create Payment Address, Create Test Payment, and Get Balance in Bcon, plus 6 more actions.
Does connecting Bcon to FlowRunner require OAuth?
No. Bcon connects to FlowRunner with an API key, no OAuth flow required.
Can Bcon trigger a FlowRunner workflow automatically?
Bcon doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with Bcon
Free plan, no card required. Connect in minutes.