Payment Gateway for Forex Brokers: Fees, Approval and Integration
A payment gateway for forex brokers connects your checkout or trader’s room to payment services and returns transaction status to your operational systems. Choosing one requires three separate decisions: whether the provider accepts your exact business, how money settles to your entity, and how deposits and withdrawals are reconciled with client accounts. A working API integration answers only the technical part.
For a broker, payment acceptance can fund a trading account. For a prop firm, a checkout may collect a challenge fee and a separate process may pay a contractual reward. Describe those activities accurately when seeking approval; do not assume that permission for one covers the other. This guide explains the procurement and integration questions to resolve before launch.
Start with merchant eligibility, not a plugin list
Send prospective providers the legal entity, website, operating locations, customer countries, instruments or evaluation product, transaction types and expected volumes. Identify who contracts with the customer and what the payment buys. Include refund, withdrawal and complaints policies in the information pack requested by the provider.
Policies differ. As a concrete current example, Stripe’s restricted-business policy, reviewed on 26 September 2026 and last updated 13 May 2026, lists funded prop trading as prohibited. It lists investment and brokerage services among restricted financial services requiring review. These are materially different categories. A Stripe connector, test account or successful sandbox payment does not override that policy.
Ask for written approval of the named entity, website, business activity, countries and required payment products. Confirm whether collection, refunds and outbound payouts are each covered. If a provider declines the model, select another approved arrangement; changing the checkout description to obscure the activity is not a solution.
FxTrusts provides payment integration services. That does not itself establish an acquiring relationship or grant merchant eligibility. The actual financial-service provider must approve the scope where required, and its agreement determines settlement, reserves and available methods.
Identify the gateway, processor and settlement counterparty
Several organisations may sit behind one payment screen. A gateway can route transaction messages. A processor or payment service provider handles the relevant payment service. An acquirer may support card acceptance, while a bank or another approved provider holds the settlement account. A software integrator connects these services to your systems.
Ask for the legal name and role of every contracting party. Where one provider performs several roles, obtain the applicable service terms for each. The important question is who owes your entity the settlement proceeds, who may hold or reserve funds, and who can investigate a payment when an API status and bank receipt disagree.
MetaQuotes’ brokerage setup guidance also treats payment-provider relationships as a separate task. Access to a trading platform does not complete payment onboarding. Plan the approval work alongside the technical integration.
Compare payment rails around the actual money journey
| Rail or function | Questions for the provider | Operational test |
|---|---|---|
| Cards | Which merchant activity, card countries, currencies and transaction types are approved? What are the refund, dispute and reserve terms? | Authorised payment, failed authentication, refund, dispute notification and delayed settlement. |
| Bank transfers | Whose account receives funds? Which references identify clients, and how are unmatched or returned transfers handled? | Correct reference, missing reference, wrong currency and returned payment. |
| Local payment methods | Which countries and customer types are supported? Does a method support refunds and withdrawals as well as collection? | Pending payment, expiry, asynchronous confirmation and unavailable payout route. |
| Cryptoasset payments | Which asset and network, confirmation policy, custody arrangement, conversion provider and settlement currency apply? | Wrong network, underpayment, duplicate notification, conversion failure and a rejected payout. |
| Outbound payouts | What beneficiary checks, limits, approvals, fees and status evidence apply? | Approved request, timeout, status enquiry, beneficiary change and duplicate prevention. |
A wide list of methods is useful only if the required methods are available to your approved entity and customers. A collection method may have no equivalent outbound payout route. Confirm whether a refund must return through the original method and which policy applies when that method is unavailable.
Understand settlement, reserves and effective cost
Request a term sheet covering settlement currency, timing, cut-off times, holidays, minimum payout, bank fees, conversion basis and the circumstances in which settlement can be held. Ask whether funds are paid automatically or require a withdrawal request. Record who receives settlement reports and how finance accesses historical data.
Where a reserve applies, record its calculation base, release schedule and treatment on termination. A rolling reserve reduces cash immediately available even when it is not an ordinary processing expense. Do not mix it with fees when comparing providers. Finance should model both the cost of processing and the cash tied up.
| Quote item | What must be explicit |
|---|---|
| Processing | Percentage and fixed amounts, charged currency, successful or attempted transaction basis and minimum fees. |
| Settlement and conversion | Payout charge, bank charge, conversion spread or reference rate, currency and timing. |
| Refunds and disputes | Processing-fee treatment, separate case fees and evidence deadlines. |
| Reserve or security | Amount or formula, holding period, release conditions and termination treatment. |
| Integration and operations | Initial work, monthly software, support, reporting access and change requests. |
Illustrative settlement example: assume a $1,000 payment, a $30 processing fee and a $100 reserve withheld from that settlement. The immediate bank receipt is $870. Under a policy where the broker absorbs the fee and credits the full payment, the client credit remains $1,000. Finance must explain the $30 expense and $100 withheld amount separately. These invented amounts demonstrate reconciliation; they are not provider rates or a recommended crediting policy.
Repeat the calculation using a refund, a chargeback and a different settlement currency. A headline processing percentage cannot reveal all those outcomes. Ask the provider for an example report based on its actual proposed terms before completing the commercial comparison.
Design the deposit state machine before coding
Define what “pending,” “confirmed,” “credited,” “failed” and “reversed” mean in your own system. Each provider uses different status names, so document the mapping. The payment record and the trading-platform credit should be linked, with their separate states visible to authorised staff.
A browser redirect is not authoritative payment evidence. Validate provider messages, associate them with the correct merchant and transaction, and apply the agreed policy before posting a money movement. If a connector is temporarily unavailable, retain a recoverable exception instead of losing the request or reporting false success.
Stripe’s webhook documentation provides a useful technical example: notifications can arrive more than once or out of order, and origin verification matters. It is cited here for engineering behaviour, not as a recommendation to use Stripe for a prohibited or unapproved business.
Require safe replay: processing the same confirmed event again must not create another client credit. Preserve provider IDs, ledger references and platform operation IDs. If an operation times out after submission, check its state before retrying a money movement. A transport error does not necessarily mean that the provider or platform did nothing.
Reconcile three records, not two screenshots
At minimum, compare the provider transaction and settlement report, the operational ledger, and the bank or wallet receipt. Where a trading account is credited separately, reconcile that operation too. A payment marked successful in a dashboard can still differ from the amount that reaches the settlement account after fees or reserves.
Adyen’s settlement report documentation is a concrete example of transaction-level reporting that includes fee, adjustment and payout information. Use it as a reference for the evidence to request from your selected provider. Its presence in this guide does not imply Adyen has approved your business.
Build an exception queue with an owner, amount, currency, age, reason and next action. Useful categories include unmatched transfer, confirmed payment awaiting credit, credited transaction missing from settlement, and returned payout. Reconcile by stable identifiers and currency, not only by totals. Two equal but unrelated amounts can cancel out in a total while both records remain wrong.
Control withdrawals and prop payouts independently
A withdrawal request is not payment execution. First determine the amount eligible under the applicable client or challenge terms. Then complete required beneficiary and approval checks, submit the payout and obtain provider evidence. Display progress accurately while the transaction is pending.
Separate preparation from approval where your control design requires it. Recheck a request when beneficiary details change, and prevent duplicate submission by concurrent staff or automated jobs. Log overrides and provide a review path for disputed eligibility decisions. An automated rule should leave enough evidence for a human to explain the result.
For prop programmes, document whether the payout represents a reward calculated from simulated results or another agreed arrangement. Do not reuse brokerage-deposit terminology without checking its meaning. The prop software checklist connects challenge evidence to payout review.
Separate the integration budget from payment-provider fees and working cash. FxTrusts’ published software pricing is not a merchant-processing quote; ask for the proposed integration work, external fees and settlement assumptions to be identified independently.
A payment-provider quote brief you can reuse
Give each shortlisted provider the same operating assumptions so the resulting quotes describe a comparable service. Separate live brokerage deposits from prop challenge purchases and reward payouts; a provider's acceptance of one activity does not settle the others. The following is a request template, not a list of supported FxTrusts payment routes.
| Complete before requesting a quote | Ask the provider to return |
|---|---|
| Legal entity, operating model and relevant permissions | Written eligibility decision for that entity and activity, plus onboarding conditions |
| Customer countries, payment currencies and settlement currency | Approved country-and-method matrix, currency conversion terms and unavailable routes |
| Expected monthly value, number of transactions and typical transaction size | Percentage fees, fixed fees, minimums, volume bands and pricing assumptions |
| Refund, withdrawal and dispute workflows | Supported operations, deadlines, evidence requirements and separate charges |
| Required settlement timing and reserve assumptions | Schedule, cutoffs, reserve formula, release conditions and holding rights |
| CRM, trading platform and operational owners | Integration responsibilities, reporting formats, test access and support escalation |
Compare processing expense and cash availability separately. For a proposed monthly transaction value V, percentage fee p, successful transaction count N and fixed fee f, the basic processing estimate is V × p + N × f. Then add the provider's actual minimums, conversion, payout, refund and dispute charges where applicable. Keep reserves in a separate cash-availability calculation because withheld money is not automatically an expense. Replace every input with a written quote; this worksheet does not establish market rates.
Demonstrate one deposit and one withdrawal end to end
Before accepting the integration, ask the provider and integrator to follow a permitted test transaction from payment confirmation to the broker CRM and trader's room, ledger record and trading-account update. Then reconcile the provider statement with the settlement receipt. Review a second case where the payment is confirmed but the platform update fails: the customer and support team should see an accurate pending state and a documented recovery path.
For withdrawals, demonstrate request creation, permission checks, beneficiary review, approval, provider submission and final status. Replay the confirmation and test a timeout without sending a duplicate payout. These are proposed acceptance scenarios, not a claim that a named provider or connector has passed them.
Request a payment integration review with your legal entity, target markets, chosen providers and platform. FxTrusts can scope the software connections and operational handover; the quote must name approved providers and responsibilities. Read the forex back-office workflow guide to assign ledger, approval and reconciliation ownership, and consult published integration status before treating any connection as ready.
The final acceptance checklist
- Written provider acceptance matches your legal entity, business model, countries and payment services.
- Finance can explain a sample settlement, reserve, refund and dispute using the proposed terms.
- Tests cover duplicate and delayed notifications, failed platform credits, timeouts and recovery.
- Staff permissions distinguish client support, financial review, payment approval and technical administration.
- Statements, transaction exports and historical records are accessible under the contract.
- Incident contacts, settlement holds, termination and outstanding-funds handling are documented.
Bring this checklist to both the financial-service provider and the integration team. The CRM comparison helps assess the operational interface, while the architecture guide identifies system owners. To scope an FxTrusts implementation, request a payment workflow review with your proposed provider and account model.
Sources
Official pages reviewed on 26 September 2026. Product descriptions establish public claims, not independently measured performance or private contract entitlements. The tests and illustrative examples in this article are proposed evaluation tools.
