TrustPay Is Now finby: Broker Payment Acceptance, Local Methods and Integration Checks
TrustPay is the name many payment buyers still encounter in vendor directories; the provider now presents itself as finby. That distinction matters to a forex or CFD broker researching a potential payments partner. A legacy profile can help locate the business, but the current product, contract and legal-entity information must be checked against the provider's live materials. Fazzaco's TrustPay directory entry places the business among forex payment providers. Finby's official rebrand announcement says TrustPay has become finby. This B2B profile reviews the published merchant proposition and the evidence a broker should seek before deciding whether to integrate it. Sources were reviewed on 10 October 2026.
Source: finby official website. Screenshot captured on 10 October 2026.
From TrustPay to finby: establish the contracting identity
A name change does not, by itself, answer which company signs a merchant agreement, holds funds, provides acquiring or supplies a particular local payment method. Finby's legal-document page refers to both Finby Finance Limited and TrustPay, a.s., and directs customers to documents relevant to their agreement. A broker should map each proposed service to its actual contracting and operating entities. That map belongs in procurement records alongside the governing terms, jurisdictions, complaints route and service-level commitments. The provider's published rebrand can be stated as fact; assumptions about universal licence coverage cannot.
The name also affects operational migration. An existing TrustPay integration may use older endpoint names, reports or statement descriptors while sales documents use finby branding. Before changing payment-page text or customer instructions, the broker should reconcile the old and new names across contracts, bank credits, transaction notifications and support contacts. A brand transition should not create a payment-reconciliation blind spot.
What the current merchant offer covers
Finby's official site describes card acceptance, local payment methods and a merchant portal. Its card-payments page states support for Visa and Mastercard, 170 processing currencies and 14 settlement currencies, as well as tokenisation and recurring billing. These are the vendor's published product claims, not evidence that a specific broker entity can use each currency or feature. The buyer should ask for a current country-by-country schedule, supported transaction types and the settlement currencies actually available under its contract.
The merchant portal is described as a place to manage transactions by project, country and payment method, customise user access and download statements. That can be useful for a brokerage group operating multiple brands or licensed entities. The design question is whether those portal dimensions map cleanly to the broker's own legal entities, client accounts and general ledger. A single view is valuable only when individual payment and settlement lines remain traceable.
Local payment methods: relevant, but conditional
Finby's local-method catalogue lists bank-based options, wallets and regional methods alongside international cards. Examples on the official page include iDEAL/Wero, BLIK, Bancontact, MB WAY and PIX. For a broker serving clients in more than one market, that catalogue offers a concrete starting list for cashier design. It does not establish that every method accepts forex or CFD activity, supports withdrawals, is live in each client jurisdiction or can be enabled under one agreement.
The broker should request a method matrix with client residence, merchant entity, payment direction, currency, transaction limit, refund route and settlement terms. Local bank methods often have different dispute and return mechanics from cards. A checkout that shows a familiar logo may increase customer confidence, but operational suitability depends on an approved merchant use case and the ability to reconcile and, where required, return funds correctly.
Integration choices and payment-state design
Finby's developer overview distinguishes card pop-up checkout, embedded fields, wallet buttons and method-specific local-payment integrations. That is a meaningful architectural distinction. A pop-up or hosted experience can reduce the broker's exposure to sensitive card-entry components; embedded fields can give more control over the user journey but demand more implementation work. Local methods may involve redirects and different completion signals. The documentation's table also varies test-environment availability by integration type, so the implementation plan should be agreed with the provider rather than inferred from a generic sandbox promise.
For a trading-account deposit, the central control is the event that authorises ledger credit. The engineering team should obtain current API specifications, callback authentication rules, idempotency behaviour, retry timing and a full transaction-state diagram. It should test what happens when the customer closes a payment window, returns before a final provider event, resubmits a request, or pays after the browser session expires. A visible success page alone should never be the sole evidence for crediting funds.
Reconciliation, settlement and treasury
Payment acceptance and settlement are related but distinct. Processing in one currency does not promise settlement in that currency, at the desired frequency or to every bank account. Ask the provider for sample settlement files showing gross payment, fee, currency conversion, reserves, adjustments, refunds and net remittance. Each line should carry a stable identifier that links the provider transaction to the broker's CRM, trading ledger and finance ledger. The team should test daily reconciliation across time zones and settlement cut-offs, not just a successful single transaction.
The same review should cover failed and disputed transactions. Who can initiate a refund, and how is that action approved? How do chargebacks and bank returns reach the broker? Is the original client account reopened, reversed or flagged for manual review? For a group with several entities, determine whether statements and reserves are separated by legal entity. These questions are part of the product's real operating cost even when the sales presentation concentrates on checkout conversion.
Risk, customer eligibility and control ownership
Finby publishes fraud and chargeback features on its card page. A broker should ask what is included in the quoted service, which controls are configured by the provider and which remain the broker's responsibility. Merchant due diligence, customer verification, sanctions screening, monitoring, chargeback evidence and suspicious-activity escalation must be allocated in writing. The answer may vary by card acquiring, bank method and legal entity. Public product copy is not a substitute for an agreed risk schedule or independent performance testing.
Eligibility is equally important. Finby's public catalogue is broad, but this article found no provider statement that all listed methods are available to every forex or CFD broker. The procurement team should identify the licensed broker entities, target client countries, acceptable funding sources and any restrictions on cross-border payments. Do not display a method to clients until the provider confirms that combination is approved and the broker has tested its funding and return flows.
Broker procurement checklist
| Question | Evidence to obtain |
|---|---|
| Who delivers each service? | Current contract, legal entity, governing terms and product-specific responsibilities. |
| Which clients can use it? | Approved broker entity, client countries, funding currencies and method-level eligibility. |
| How will it connect? | Integration choice, test access, event states, signed callbacks, idempotency and version policy. |
| How does money reconcile? | Sample transaction and settlement files with fees, FX, reserves, refunds and stable references. |
| Who handles exceptions? | Refund and chargeback process, incident escalation, support hours and control ownership. |
A useful pilot should include successful deposits, rejected payments, duplicate attempts, abandoned sessions, refunds and the payout or return route actually contemplated by the broker. Compare completion, reconciliation effort and exception volume using the broker's own data. Vendor-wide marketing figures cannot replace results for the broker's approved markets and customer base.
Editorial assessment
The TrustPay-to-finby transition makes this a particularly important directory record to read with a current-source check. Finby's published card, local-method and merchant-portal materials give a broker a clear set of capabilities to investigate. The commercial decision turns on present-day contracting identity, approved forex/CFD use cases, method availability, settlement and integration behaviour. None of those should be assumed from a legacy brand listing. The Fazzaco TrustPay profile remains a discovery point; the provider's current documents and a controlled pilot should determine whether the offering fits a particular broker.
Subscribe Now
