Broker payments: every movement on the record.
Payments is TradeCore's money layer for FX/CFD brokers, built into the BrokerIQ CRM core: deposits and withdrawals across 100+ PSPs and 300+ payment methods, on two linked ledgers that keep every gateway charge and internal movement traceable.
100+ brokerages run on TradeCore, including MultiBank Group, AvaTrade, IC Markets, FP Markets and Trade Nation.
Payments
Gateway ledger — today
Card ·
Awaiting settlement
Bank transfer ·
Under review
Held — Provider is holding the charge
Crypto ·
Succeeded
E-wallet ·
Succeeded
Withdrawal · pending approval
Decided in priority order. Each step needs the permission it names, and one rejection rejects the request.
100+
Providers
300+
Methods
50+
Currencies
Why do payments live in the CRM core?
A payment is a fact about a client. BrokerIQ is TradeCore's modular CRM and back-office product line for FX/CFD brokers. Payments sits in its CRM core, not in a module, so a deposit and its client, bonus and partner share one set of records. The modules run natively or standalone on your existing CRM.
The BrokerIQ CRM core
Clients, trades, transactions, KYC data and payments — one record set, bought as one thing.
- PaymentsYou are here
the gateway ledger, the internal ledger and the wallets they move between
the accounts a deposit lands on, across 8 trading platforms
200+ integrations, an open API and outbound webhooks
The six modules read from it
- Compliance
identity verified before money moves
- Automations & AI
what fires when a deposit lands, fails or is held
- Marketing
bonuses awarded on deposit, cashback credited on volume
- IB Suite
partner commission settles into an IB wallet on the same rails
- SupportIQ
“where is my withdrawal” answered from the record, not a guess
- Prop Trading
the challenge fee is a deposit, and the profit split is a payout
What happens when a client deposits?
The client sees the methods their brand offers in their country and currency, the provider’s page opens the way that gateway is configured, and the provider’s notification is verified and de-duplicated before anything is credited.
One deposit
From the method a client is allowed to see, to the balance it lands on
Portal
The client sees only what their brand offers them
Payment methods are resolved against the client's brand, country and currency. A bank rail listing countries is offered to residents of those countries only, and the answer is computed when the page is opened rather than stored on the client — so a client who moves is answered from their current address.
Route
The method resolves to a gateway configured for it
Each gateway carries its own enabled methods, its own currency and country lists, its own minimum and maximum for deposits and for withdrawals separately, and its own position in the client's list of options — all of it per brand.
Provider
The provider's page opens the way that gateway is set to open
As a modal, an inline frame, a new tab, a direct post, or — on a manual bank rail — a static instructions block with no redirect at all. The amount is either locked at initiation or entered on the provider's own page, optionally pre-filled.
Window
Every deposit session carries an expiry
Stamped once at dispatch: that moment plus the window configured for the gateway and method, 24 hours by default, and never shorter than the provider's own floor. One moment that the operator, the client's portal and the reconciliation sweep all read.
Settle
The provider's notification is verified before it is believed
Signature-checked per provider, locked on the transaction reference so two copies cannot process at once, de-duplicated, and refused outright if it asks for a transition the lifecycle does not allow. A refused notification is recorded with one of six named reasons rather than dropped on a log line.
Credit
The money lands, and the record says where it landed
Into a multi-currency wallet or straight onto a trading account. Where the client entered the amount on the provider's page, settlement credits what the provider reported — not what was stored when the session opened.
Five ways to open a provider
Modal, inline frame, new tab, direct post, or static bank instructions — set per gateway, not hard-coded per provider.
24-hour default session
The expiry window is configurable per gateway and method, and can never be set shorter than the provider's own floor.
Six named refusal reasons
An unknown reference, an unparseable body, a short settlement, a failed signature, a misconfigured gateway, an unmapped status.
The same cashier in your own app. In TradeCore’s Mobile App, clients deposit through the broker’s configured methods and withdraw to approved bank accounts, and each payment lands in the same client record and payment routing as the web portal.
Two ledgers, so every figure has a source
Money that touched a payment provider is recorded on one ledger, money that moved inside the brokerage on the other. They are linked, never merged — which is what lets a figure be traced back to the thing that caused it.
The gateway ledger
Money that touched a payment provider.
- Deposits
- Withdrawals
- Refunds routed back through the provider
- Refunds settled by hand
- Profit payouts
- Chargebacks
The internal ledger
Money that moved inside the brokerage.
- Adjustments
- Transfers between a client's own balances
- Currency conversions
- Credits, charges and corrections
- Swap and dividend
- Trading commission
One deposit, opened up
Eight things the record answers without anyone opening a provider dashboard
Asked for
the amount and currency the client requested
Charged
what the provider took, as the provider reported it
Landed
what was actually credited to the wallet or trading account
Fee
the provider's fee, in its own currency
Rate
the exchange rate applied, and where that rate came from
Processor
who settled behind the gateway — the acquirer, or the bank a wire landed in
Reference
the provider's reference, and whether we minted it or echoed theirs
Outcome
the state, and on a failure the provider's own code and message
A settled payment is append-only, forever
Once a payment has succeeded or been cancelled, nothing rewrites it. The rule is enforced in the model's write guard, not left to callers.
A contradiction reopens the record, it doesn't overwrite it
A failed or expired deposit is only provisional. If the provider later reports success, the record reopens for review instead of quietly flipping to succeeded.
A reversal writes a new entry
Internal ledger entries are never edited. Reversing one writes an adjustment beside it, and a manual adjustment has to name the operator who made it.
Every entry knows what caused it
Each carries the balance it produced, its position in sequence, a reason code from the catalogue, and a pointer back to the deposit, commission or transfer that caused it.
Imported money is marked as imported
A transaction migrated from an old system is flagged as migrated and carries the date it happened there — TradeCore never claims to have processed money it did not.
Four wallet kinds, per currency
Cash, IB, bonus and loyalty wallets, one per currency. A frozen wallet still accepts credits and refuses debits, a closed one accepts neither, and a wallet balance can never go negative — the constraint sits in the database.
- Cash
- IB
- Bonus
- Loyalty
- Never negative
Transfers that finish or unwind
Clients move money between their wallet and their trading accounts, and between their own trading accounts. A failed leg is compensated rather than left half-done, and the client sees it as pending until the reverse leg has actually settled.
- Wallet ↔ account
- Account ↔ account
- Failed leg compensated
Conversion you price
Brokers set their own FX markup per currency pair, and an operator can override the rate at approval. Rates come hourly from a global feed, cross-rated through the dollar and rounded to each currency's minor unit, and the rate and its source are stored on every transaction.
- 50+ currencies
- Per-pair FX markup
- Operator override
- Rate + source stored
What happens when a deposit doesn’t settle?
It is held, not guessed at — with one of six named reasons on the record. TradeCore polls the provider before expiring anything, and a poll that teaches us nothing never expires a deposit, because expiring on our own outage would be inventing abandonment.
Held for review
Six reasons a deposit stops, and the reason travels on the record
It broke the configured bounds
The amount reported fell outside the minimum or maximum set for that gateway and method, or the currency differed from the one the session was opened in.
It settled after its session expired
The client paid after the provider's page had already been reaped.
The provider contradicted itself
A success arrived against a deposit the same provider had earlier reported as failed. Previously this class of event was dropped on a log line.
The provider is holding the charge
Its own terminal hold — a risk review, or a crypto client who paid the order amount instead of the fee-inclusive quote. Neither the cause nor the amount received is in the callback, so only a person reading the provider's dashboard can settle it.
A rule of yours held it
A broker's own pending-deposit rule matched at settlement and held the money for a look. Nothing is wrong with the deposit — and the record names which rule did it.
A client says they wired money
A client-declared bank transfer nobody has confirmed yet. The record is born under review carrying the client's claim, and nothing is credited until an operator confirms what the bank actually paid.
Release
Credits it down exactly the same path a clean settlement takes — so bonuses and automations fire once, and identically. The operator's note is stored encrypted.
Refuse
Nothing is credited, the reason stays on the record as history, and returning a client's money is its own separate transaction rather than an edit to this one.
The sweep
What happens to money that never settled
Poll the provider before expiring anything
A deposit whose notification never arrived is asked about directly. Three answers are possible: resolved, still pending, or nothing learned — and nothing learned never expires the deposit, because expiring on our own outage would be inventing abandonment.
The sweep is silent
Expiry publishes nothing. “Payment failed” is a live automation trigger — a manager alert and a “trouble depositing?” email — so a loud sweep would chase every client who simply walked away from a cashier page.
An hour of nothing learned raises a person
Polls that keep teaching us nothing raise a fault grouped by gateway, because the cause is almost always the gateway — an unreachable provider, a rotated credential — and not the deposit.
A payout stuck past 24 hours is flagged
So is a success arriving on a payout already recorded as failed. Neither changes the payout's state: the money may still be moving, and a state change would be a guess.
A failure, with its class on the record
- Declined
- the issuer or provider refused the charge
- Provider error
- the provider's own system failed
- Timeout
- the initiation never reached a payable session
- Abandoned
- the client opened a cashier page and never paid
One screen per payment
TradeCore assembles the payment record, the ledger entry it created, the trading-platform sync row with the platform's own error text, and the audit timeline on one screen. Every round trip with the provider is logged, and a 200 response carrying a provider-level rejection is never stored as a success.
- Payment record
- Ledger entry
- Platform sync row
- Audit timeline
Two states, never forced to agree
Gateway state and trading-platform state are recorded separately and never overwritten to agree, so a divergence between the provider and the trading account is surfaced instead of smoothed over.
- Gateway state
- Platform state
- Divergence surfaced
Fixes that leave a trail
An operator retries a failed sync with a required, permission-gated reason, and the retry lands on the client's activity stream. Compensation always writes a new transaction — a state is never quietly reverted.
- Required reason
- Permission-gated
- New transaction, never an edit
A held deposit becomes work, not a surprise. Held deposits, pending approvals and unverified bank accounts arrive in the BrokerIQ CRM’s unified work queue. Deposit completed and deposit failed are automation triggers, with 12 ready-made payment rules in the TradeCore library.
Who has to approve a withdrawal?
Somebody, always. A withdrawal that matches no rule at all still carries one baseline step a person has to decide — there is no path where money leaves unreviewed because nobody wrote a rule.
The withdrawal lifecycle
Eight states, four of them terminal
- Source locking
- Pending approval
- Approved
- Executing
- Completed
- Rejected
- Cancelled
- Failed
Only the declared transitions are legal — the lifecycle refuses a move it does not describe, rather than trusting the caller that asked for it.
Source locking
Withdrawal · trading account
- Pending
- Pending
- Pending
Higher-priority steps are decided first. The request is approved only when every step is decided and none was rejected — and a withdrawal that matched no rule at all still carries one baseline step a person has to decide.
Approval is required by default
A withdrawal that matches no rule at all still carries one baseline step that a person has to decide. There is no path where money leaves unreviewed because nobody wrote a rule.
Steps are decided in priority order
Rules are ordered, and a higher-priority step must be decided before a lower one can be. The request is approved only when every step is decided and none was rejected — one rejection rejects the whole request.
Each step names the permission it demands
An operator who does not hold that permission cannot decide that step. Every decision records who made it, when, and the note they left.
An amount threshold means the same thing in every currency
A rule's threshold is restated into one currency before it is compared — so “senior approval at 10,000” does not fire on a 10,000 JPY withdrawal worth about 65 dollars, and does not miss a large one in a small-unit currency.
Turning a rule off releases what was waiting on it
Disabling a rule skips its undecided steps rather than stranding withdrawals behind a rule nobody uses any more.
Funds are locked before approval
And per brand, a trading-account withdrawal locks its funds either when the client submits or when the payout executes.
What the client is told before they can submit
A one-time password can be required
Set per brand, checked before the request is created.
Consequences are named, not buried
Before a trading-account withdrawal submits, the client acknowledges what it will cost: a promotion's withdrawal restriction and its early-withdrawal fee, a bonus that will be cancelled, a bonus that will be reduced.
The fee is recorded, not folded in
An early-withdrawal fee is stored on the request beside the amount, so a disputed payout shows exactly where the difference went.
A client can cancel, and say why
From a closed list of five reasons — changed my mind, wrong amount, wrong destination, taking too long, other — which gives the brokerage a real “why are withdrawals abandoned” dimension instead of free text.
Promotions and withdrawals never disagree. The warnings a client acknowledges are read live off the campaign that set them, so a promotion configured in Marketing cannot drift out of step with what the withdrawal form says it will cost.
Where does the money go back to?
On a regulated brand, back where it came from first. The payout is allocated against the client’s own deposits, oldest first, and only what is left over leaves as profit. On a brand that doesn’t need it, one payout goes out and nothing is allocated.
- Return to source (Regulated brands): The payout is allocated back against the client's own deposits first, and only what is left over leaves as profit. Allocation runs oldest deposit first, and an operator can override it. Refunding more than a deposit received is hard-blocked, not warned about. A refund leg must name the deposit it reverses. A refund routed back through the provider and one settled by hand are recorded as different things. The allocation is stored on the request as an audit record.
- Simple payout (Brands that do not need it): One payout, no allocation — the whole amount leaves as a single movement. Set per brand, not per request. A brand that switches mode keeps in-flight requests on the mode they started under. The same approval chain applies either way. The same ledger entries are written either way.
Payout allocation
Withdrawal
Deposit · cardoldest
· received
refunded to source
Deposit · bank
· received
refunded to source
Deposit · e-wallet
· received
refunded to source
Profit payout
what is left after the deposits are covered
Refunding more than a deposit received
Hard-blocked, not warned about. A refund leg has to name the deposit it reverses, and the total against one deposit can never exceed what that deposit brought in.
Single payout
no allocation, one movement
The same approval chain applies, and the same ledger entries are written. A brand that switches mode keeps its in-flight requests on the mode they started under.
Return to source
Regulated brandsThe payout is allocated back against the client's own deposits first, and only what is left over leaves as profit.
- Allocation runs oldest deposit first, and an operator can override it
- Refunding more than a deposit received is hard-blocked, not warned about
- A refund leg must name the deposit it reverses
- A refund routed back through the provider and one settled by hand are recorded as different things
- The allocation is stored on the request as an audit record
Simple payout
Brands that do not need itOne payout, no allocation — the whole amount leaves as a single movement.
- Set per brand, not per request
- A brand that switches mode keeps in-flight requests on the mode they started under
- The same approval chain applies either way
- The same ledger entries are written either way
A card payout goes back to the same card through the provider's own reusable token, and that token is scoped to that one gateway in the database rather than by convention.
Card records hold the first six digits, the last four, the brand, the funding type and the expiry. The full number, the security code and the PIN are never stored.
An expiry renewal comes either from the provider's account updater or from an operator, and the record says which.
Run each brand to its regulator's rules. TradeCore Compliance ships a seeded rulebook for 19 regulatory regimes, including FCA, CySEC and ASIC, and every licence a brand holds runs on its own regime.
What can your team change without us?
The gateway, the methods, the bounds in each direction, the countries, the order clients see them in — all of it in the interface, per brand, by the people who run payments rather than the people who write code.
Gateway
Praxis
Credentials
Provider not asked yet
What it may do
Activation is refused without credentials and at least one of deposits, payouts or refunds.
Methods on this gateway
Each direction carries its own floor and ceiling
Cards
Deposit
Withdrawal
Bank transfer
Deposit
Withdrawal
E-wallet
Deposit
Withdrawal
Where it is offered
An empty list means all. Bank rails additionally check the client's country of residence when the page is opened.
Add a gateway with its credentials
Entered in the interface and stored encrypted. The platform refuses to activate a gateway with no credentials, or one that does no deposits, no payouts and no refunds.
Ask the provider whether the credentials work
The platform can put the question to the provider and record the answer per credential set — keeping “never asked” distinct from “asked and got nothing back”.
Park a half-finished gateway as a draft
A draft can never be client-visible and can never be active. It goes live only when the credentials it needs are present.
Set what each method can do, per gateway
On or off, deposits and withdrawals allowed separately, a separate minimum and maximum for each direction, the currencies and countries it serves, and how long its session lives.
Order what clients see
Portal ordering decides which methods appear first, and a gateway can be visible to clients, to the back office, or to both.
Gate bank rails by where the client lives
A rail listing countries is offered to residents of those countries; one listing exclusions is hidden from them; one listing neither is offered to everyone. Computed on read, so nothing goes stale.
Shape the form a client fills
Reorder, relabel or hide the fields on a saved payment account per brand, and add your own — except a required field, or one a live rail reads, which cannot be hidden.
Name your own reasons money moved
The reason catalogue is two-tier: the platform's own reasons plus the brokerage's, grouped as deposit, withdrawal, bonus, adjustment, transfer, fee, IB and other.
Rotate credentials in place
Without downtime, and the rotation is its own recorded event.
Run it per brand
Each brand carries its own gateways, its own credentials, its own methods and its own ordering.
Providers are one part of the connection layer. TradeCore’s 100+ PSPs sit among 200+ integrations, beside an open API, outbound webhooks and 8 trading platforms whose accounts a deposit can credit directly.
Payment providers on every plan
TradeCore's free plan connects one payment provider for deposits and runs the whole withdrawal flow, with your own team sending each approved payout; its shop adds providers at €100 a month each, up to 3 payment providers. TradeCore's Core plan connects two payment providers, sends payouts automatically, and adds further providers at €100 a month each, with no ceiling.
TradeCore's free plan
€0Your team sends every payout
- One payment provider for depositsChosen from 100+ PSPs and 300+ payment methods, with its methods, bounds and countries set in the interface.
- Up to 3 payment providers through the free plan's shopEach further provider is €100 a month, bought one at a time.
- Your approval chain and return-to-source rulesEvery withdrawal goes through the priority-ordered approval chain and, on a regulated brand, return-to-source allocation — then your team sends the payment.
- Manual bank transfer, multi-currency wallets, both ledgersClient-declared transfers are reviewed before anything is credited, and every movement lands on the gateway or internal ledger.
Core
€2,500 a month, flatPayouts go out on their own
- Two payment providers includedChosen from the same 100+ PSPs and 300+ payment methods.
- Further providers at €100 a month eachStackable, with no ceiling.
- Automated payoutsOnce the final approval step is decided, TradeCore sends the payout through the connected payment provider.
- The whole payments flowThe approval chain, return-to-source allocation, manual bank transfer, multi-currency wallets and both ledgers.
Every price on one page. Further payment providers, seats, brands and trading platforms are priced side by side on TradeCore’s pricing page. No per-trader fees, no per-trade fees, no setup fees.
What a payments audit would find
Every part of TradeCore Payments, by area — the ledgers, deposits, reconciliation, withdrawals, return to source, balances, payment accounts, configuration and governance.
The ledger
Two linked ledgers, append-only settled records, and a cause, a balance and a reason on every entry.
- Two linked ledgers — gateway-touched money on one, internal movement on the other
- Six gateway record types: deposit, withdrawal, provider refund, hand-settled refund, profit payout, chargeback
- Nine internal movement types: adjustment, transfer, conversion, credit, charge, correction, swap, dividend, trading commission
- Settled payment records are append-only forever, enforced at the model's write guard
- A failed or expired deposit is provisional — a contradicting settlement reopens it for review
- Internal entries are never edited; a reversal writes an adjustment beside the original
- Every internal entry carries the balance it produced, its sequence position, a reason code and a pointer to its cause
- A manual adjustment must name the operator who made it
- Two-tier reason catalogue — platform reasons plus your own, in 8 categories
- Imported transactions flagged as migrated, carrying the date they happened in the old system
TradeCore Payments — The ledger
Two linked ledgers, append-only settled records, and a cause, a balance and a reason on every entry.
- Two linked ledgers — gateway-touched money on one, internal movement on the other
- Six gateway record types: deposit, withdrawal, provider refund, hand-settled refund, profit payout, chargeback
- Nine internal movement types: adjustment, transfer, conversion, credit, charge, correction, swap, dividend, trading commission
- Settled payment records are append-only forever, enforced at the model's write guard
- A failed or expired deposit is provisional — a contradicting settlement reopens it for review
- Internal entries are never edited; a reversal writes an adjustment beside the original
- Every internal entry carries the balance it produced, its sequence position, a reason code and a pointer to its cause
- A manual adjustment must name the operator who made it
- Two-tier reason catalogue — platform reasons plus your own, in 8 categories
- Imported transactions flagged as migrated, carrying the date they happened in the old system
TradeCore Payments — Deposits
How a deposit opens, how the provider's notification is verified, and what is credited.
- 100+ payment providers, 300+ payment methods
- Seven-state deposit lifecycle with only declared transitions legal
- Five ways to open a provider: modal, inline frame, new tab, direct post, static bank instructions
- Three amount modes: locked at initiation, entered on the provider's page, or pre-filled and editable
- Settlement credits what the provider reported where the client entered the amount there
- Per-session expiry — 24 hours by default, never below the provider's own floor
- Per-provider signature verification on every inbound notification
- A lock on the transaction reference, so two copies of a notification cannot process at once
- De-duplication, and state guards that refuse an illegal transition
- Six named reasons an inbound notification is refused
- Four failure classes recorded on a failure: declined, provider error, timeout, abandoned
- Manual bank transfer as a first-class rail, with proof of payment requirable per brand
- Client-declared bank deposits born under review, credited only on an operator's confirmed amount
TradeCore Payments — Reconciliation
What the platform does about money that never settled, and what an operator sees about one payment.
- Deposits whose notification never arrived are polled at the provider
- Three poll outcomes — resolved, still pending, nothing learned — and nothing learned never expires a deposit
- The expiry sweep publishes nothing, so abandonment never fires the payment-failed automation
- Unresolvable polls raise a fault after an hour, grouped by gateway rather than by transaction
- Payouts unsettled past 24 hours raise an operator alert
- A success arriving on an already-failed payout raises an alert without changing the payout's state
- Every round trip with the provider logged against the payment, request and answer together
- A 200 response carrying a provider-level rejection is never stored as a success
- One investigation screen: the payment, its ledger entry, its trading-platform sync row and the audit timeline
- Gateway state and trading-platform state recorded separately, never overwritten to agree
- Operator retry of a failed sync with a required reason, projected onto the client's activity stream
- Compensation always writes a new transaction — no state is quietly reverted
TradeCore Payments — Withdrawals
The eight-state lifecycle, the approval chain, and what the client is told before submitting.
- Eight-state withdrawal lifecycle from source locking to completed, rejected, cancelled or failed
- Funds locked before approval; per brand, at submit or at execute
- Approval required by default — an unmatched withdrawal still carries one baseline step
- Priority-ordered approval rules, each naming the permission needed to decide it
- Higher-priority steps decided first; one rejection rejects the request
- Rule conditions on amount, withdrawal mode and source — wallet or trading account
- Amount thresholds restated into one currency before comparison
- Disabling a rule skips its undecided steps instead of stranding them
- Optional one-time password before submission
- Named consequences acknowledged before a trading-account withdrawal submits
- Early-withdrawal fee recorded on the request, not folded into the amount
- Client self-cancellation from a closed list of five reasons
- Automatic dispatch on final approval, or a recorded manual execution in the back office
TradeCore Payments — Return to source
Return-to-source allocation or a simple payout, set per brand, and card payouts back to the same card.
- Two withdrawal modes set per brand: return-to-source enforced, or a simple single payout
- Allocation back against the client's own deposits, oldest first, with operator override
- Over-refunding a deposit hard-blocked
- Refund legs must name the deposit they reverse
- Provider-routed and hand-settled refunds recorded as different types
- The allocation stored on the request as an audit record
- Card payouts returned to the same card through a token scoped to that one gateway
TradeCore Payments — Balances and transfers
Multi-currency wallets, transfers between a client's own balances, and conversion priced by the broker.
- Multi-currency wallets in four kinds: cash, IB, bonus, loyalty
- Frozen wallets accept credits and refuse debits; closed wallets accept neither
- Wallet balances can never go negative — enforced in the database
- Transfers between a client's wallet and their trading accounts
- Transfers between a client's own trading accounts, with a failed leg compensated
- A client-facing transfer status never regresses while an unwind is still in flight
- Currency conversion on hourly rates from a global feed, cross-rated through the dollar
- Amounts rounded to each currency's own minor unit; the rate and its source stored on the transaction
- Your own FX markup per currency pair, with an operator override at approval
- 50+ currencies
TradeCore Payments — Payment accounts and cards
Saved bank accounts, e-wallets and crypto addresses, their verification, and what a card record holds.
- Clients save bank accounts, e-wallets and crypto addresses
- Four-state verification: pending, under review, verified, rejected
- Undecided accounts land in an operator's work queue, assigned or unclaimed
- Accounts whose holder name does not match the client are flagged as third-party
- Account identifiers fingerprinted with a keyed hash, so the same IBAN or address on two clients is detected without decrypting anything
- Card records hold first six, last four, brand, funding type and expiry — never the full number, security code or PIN
- Card expiry renewed by the provider's account updater or by an operator, and the record says which
- Holder names and account details encrypted at field level at rest
TradeCore Payments — Configuration
Gateways, credentials, methods, bounds and ordering, set per brand in the interface.
- Gateways added by entering credentials in the interface, no developer needed
- Activation refused without credentials and at least one of deposit, payout or refund
- Draft gateways parked half-configured, never client-visible, never active
- Credential probe that asks the provider whether it accepts what was just saved
- Credential rotation in place, recorded as its own event
- Per gateway and method: enabled, deposit and withdrawal separately, per-direction minimum and maximum
- Currency and country lists per method, where empty means all
- Portal ordering, client visibility and back-office visibility per gateway
- Bank rails gated by the client's country of residence, computed on read
- Saved-account form fields reordered, relabelled, hidden or added per brand
- Custom payment methods mapped to any gateway
- Everything scoped per brand — own gateways, own credentials, own methods, own ordering
TradeCore Payments — Governance and work
Permissions, the work queue, automation events, search, export and a record that is never deleted.
- Held deposits, pending approvals and unverified accounts arrive in the operator's work queue
- Approval steps, transaction actions, exports and configuration each gated by a named permission
- Every decision records who made it and when
- Operator review notes encrypted at rest
- Payment events feed the automation engine — deposit completed, deposit failed, withdrawal approved, withdrawal completed, third-party account flagged, an account shared across clients
- 12 ready-made payment rules in the automation library
- Transaction search by client, reference or amount, with filters on state, type, client, date and amount
- CSV export, permission-gated and audited
- Data is never deleted
How do broker payments differ from a payments module bolted on?
Unlike legacy broker CRMs, which connect 10–20 payment providers on a shared configuration, TradeCore connects 100+ PSPs per brand and records what happened to the money on two linked ledgers — from the provider's charge to the approval that released a payout.
| Capability | BrokerIQTradeCore | Legacy broker CRMs | Generic CRMs |
|---|---|---|---|
Provider coverage | 100+ payment providers and 300+ payment methods, configured per brand with their own credentials, currencies, countries and ordering | 10–20 providers on a shared configuration | No payment model at all |
Ledger model | Two linked ledgers — gateway-touched money and internal movement kept apart — with settled records append-only forever | One transaction list | No ledger concept |
What one payment records | What the client asked for, what the provider took, what landed, the fee, the rate and its source, the processor behind the gateway, and the full exchange with the provider | An amount and a status | An amount |
A deposit that doesn't settle | Six named hold reasons, four failure classes, and a sweep that polls the provider before it expires anything | Chased by hand from the provider's dashboard | Not applicable |
Withdrawal approval | Priority-ordered rule chain, each step gated on a named permission, with a baseline step every unmatched withdrawal still has to pass | Manual approval with no structured chain | Not available |
Thresholds across currencies | An amount threshold is restated into one currency before comparison, so the same rule means the same thing in JPY and in USD | Raw amount comparison, if any | Not available |
Currency conversion | Hourly global rates, your own FX markup per currency pair with operator override, and the rate and its source stored on every transaction | The provider's rate, unrecorded | Not applicable |
AML routing on withdrawals | Return-to-source allocation against the client's own deposits, oldest first, with over-refund hard-blocked — or a simple payout, set per brand | Worked out by hand in a spreadsheet | Not available |
Card data held | First six digits, last four, brand, funding type and expiry. The full number, security code and PIN are never stored | Varies by integration | Not applicable |
Changing routing on a Tuesday | Credentials, capabilities, per-direction bounds, currencies and countries changed in the interface by your own team, per brand | A developer integration per gateway | Not applicable |
Audit trail | Every settled record append-only, every internal entry carrying its running balance, reason and actor, and every decision naming who made it | Basic transaction logs with limited retention | An activity feed |
Competitor columns describe categories of product, not named vendors. TradeCore’s provider and method counts are the published integration set, and every TradeCore cell describes the product as it runs today.
Payment questions, answered
What payments and operations teams ask before they move money through TradeCore.
A broker payment platform processes deposits and withdrawals for FX and CFD brokerages across many payment providers, and keeps the record of what happened to the money. TradeCore does it inside the BrokerIQ CRM core: 100+ providers and 300+ payment methods on two linked ledgers, with withdrawal approval and return-to-source routing built in rather than bolted on.
TradeCore connects to 100+ payment providers covering 300+ payment methods, among them Stripe, Skrill, Neteller, PayPal, Praxis, CoinsBuy, Bridger Pay and FasaPay. A gateway is added by entering its credentials in the interface, and the platform refuses to activate one that has no credentials or that does no deposits, payouts or refunds.
Yes. Brokers set their own FX markup per currency pair in TradeCore, and an operator can override the rate when approving a transaction. TradeCore converts across 50+ currencies on hourly rates from a global feed, and the rate applied and its source are stored on every transaction.
Yes. Payments are part of the BrokerIQ CRM core, so TradeCore's free plan runs them: one payment provider for deposits, the approval chain and return-to-source rules on every withdrawal, and your own team sending each approved payout. The free plan's shop adds providers at €100 a month each, up to 3 payment providers; TradeCore's Core plan connects two payment providers and sends payouts automatically.
Payments comes with the BrokerIQ CRM core, because a payment is part of the client record. A brokerage that wants to keep its existing CRM can start with any of the six BrokerIQ modules standalone, connected to its existing CRM, and move onto the CRM core later without rip-and-replace.
No. A TradeCore card record holds the first six digits, the last four, the brand, the funding type and the expiry — never the full number, the security code or the PIN. A repeat charge or a payout back to the same card uses the provider's own reusable token, which is scoped in the database to that one gateway.
No. A settled payment record in TradeCore is append-only forever, enforced in the model's write guard. A failed or expired deposit is provisional instead: if the provider later reports success, the record reopens for operator review rather than flipping to succeeded. On the internal ledger, a reversal writes a new adjustment entry beside the original.
Still have questions?
Contact our teamRun Payments for free
TradeCore’s free plan switches on the BrokerIQ CRM core and every module, with payments included. No card to sign up — a card the first time you buy an add-on. Your environment is ready as soon as you finish signup.
What TradeCore’s free plan includes · TradeCore plans and add-on prices