ECOMMPAY: acquiring, payments and payout infrastructure

ECOMMPAY provides a payment gateway, card acquiring and payment-processing services, alongside alternative payment methods, open banking and payouts. For a brokerage, the relevant use case is moving and reconciling customer funding and withdrawals around the trading account. Payment acceptance is a separate service from executing a currency trade, supplying market liquidity or operating the broker’s trading platform.[1]

Its FinTech service addresses account funding, prepaid-card top-ups, bank transfers and payments to cards. The page describes merchants with a UK or EEA legal entity, standard settlement in USD, EUR and GBP, and prefunded global payout arrangements. These are useful funding capabilities for financial businesses, but the merchant still needs acceptance for its actual legal entity and activity; the FinTech page does not promise universal approval of FX and CFD brokers.[2]

Gate uses project credentials and an asynchronous payment workflow. An initial response accepting a request is different from a completed payment: further customer actions or intermediate callbacks may follow before the final result. This distinction matters when a broker credits a trading balance, because the integration needs to interpret the payment outcome rather than simply the receipt of an API request.[8]

The platform documentation requires protected transport and message signatures. Secrets belong on the merchant’s server, and callback signatures need verification as well as request signing. The documented transport baseline is TLS 1.2 or later. Hosted collection reduces the card-data exposure of that route; it does not justify passing signing secrets to the browser.[9]

Ecommpay publishes a specific small-business offer, alongside sales-led FinTech arrangements. The public offer requires a UK-registered business with an active website, at least six months of trading, turnover below EUR 2 million and fewer than ten employees, within eligible activities. Its cards, Apple Pay and Google Pay scope is narrower than the wider platform catalogue. Those eligibility conditions and prices should not be presented as a default brokerage merchant quote.[11]

This rate card uses a 21:00 UK-time daily cutoff and T+5 business-day settlement. Transactions after Friday’s cutoff or during weekends/UK bank holidays count from the following business day. Fees are deducted before remittance to the merchant’s nominated UK business bank account. These timings belong to this published offer, rather than every enterprise settlement agreement.[12]

There is a currency-label inconsistency on the small-business marketing page: its international-card tile shows a EUR 0.20 fixed component, while the linked UK contractual rate card uses GBP 0.20. The table above follows that rate card; the agreed merchant documents need to establish the applicable currency.[11]

These are the public merchant terms linked from the small-business rate card; negotiated enterprise arrangements may differ. Approval is conditional on the merchant’s business, checks and technical readiness. The payment-conversion service described in the agreement is part of payments, not an authorisation to offer retail FX trading.[13]

The documented onboarding path begins with the merchant application and approval, then connects the account manager and technical team to agree requirements and testing. Production follows joint integration checks, with monitoring and ongoing support. The documents describe an implementation process, rather than a guaranteed universal time to approval for a financial-services merchant.[14]

Existing stored-card and recurring-payment arrangements require a separate migration. Ecommpay documents a direct acquirer-to-acquirer transfer for live projects, including encrypted file exchange and a verification step. Incoming migration is not charged by Ecommpay, although the previous acquirer may charge. Both sides must support the transfer. The process generates new project-bound card tokens and recurring-payment identifiers, so a broker cannot assume its old identifiers continue unchanged.[15]

The migration instructions call for an agreed cutover and stopping the old recurring-payment flow to avoid double charging. Migration in the other direction is arranged through the account manager. This is an assisted transfer process, not a promise that exporting ordinary transaction reports will also export portable payment credentials.[15]

The separation between preliminary and reconciled data is consequential for a broker’s cash ledger. A dashboard view useful for checking whether a payment was processed is not automatically the final statement of net merchant funds after fees. The documented financial-reporting route supplies a different evidence base for matching settlements.[24]

The wider service describes an account manager, implementation assistance, a chargeback team and 24/7 technical support. Those are different routes from the small-business helpdesk, whose published telephone hours are Monday to Friday, 09:00–18:00. The availability of a technical team should not be read as a public promise that every merchant enquiry has the same response or resolution deadline.[16][18]

The complaints policy gives an acknowledgement deadline of three business days after receipt. Payment-service complaints normally receive a final response within 15 business days; exceptional cases can extend to 35 business days from receipt. Other complaints have an eight-week final-response period. These are complaint-handling clocks, not payment settlement or routine ticket-resolution promises.[17]

Ecommpay’s regulatory notice identifies Ecommpay Limited, UK company 08580802, as an FCA-authorised payment institution under reference 607597. This is the payment-services scope of the operator covered here. The same notice describes a Latvian branch providing technical and back-office functions; that branch description is not evidence of a separate EU financial-services authorisation.[18]

The May 2026 safeguarding disclosure distinguishes Ecommpay from a bank and states that funds are not covered by the Financial Services Compensation Scheme. It describes safeguarding through segregated funds at approved banks, eligible secure liquid assets held with a custodian and insurance/bond arrangements, including a Howden route. Safeguarding is therefore a specific protection framework for payment funds, rather than an ordinary insured bank deposit.[19]

The public merchant terms describe the parties as independent controllers for the covered data-sharing activities. The privacy policy permits retention after the commercial relationship ends where needed for matters such as refunds, chargebacks, fraud prevention and legal duties. It does not publish one fixed retention period for every transaction and customer dataset.[13][20]

The privacy disclosure also provides for international processing and transfer safeguards. It should not be read as a commitment that every merchant or cardholder record stays in one country. A merchant’s request to delete personal data is subject to the stated legal and operational retention grounds, so closing the payment account and erasing all historical processing records are different events.[20]

Companies House records Ecommpay Limited as an active private company, incorporated on 24 June 2013 under number 08580802. Its registered address is the fifth floor, Churchill House, 142–146 Old Street, London EC1V 9BW. This corporate registration identifies the UK operator; it is distinct from the permission to provide particular payment services.[25]

The group’s company history begins in 2012, before the UK entity’s incorporation. Its current About page names founder Aleksejs Sjarki, also styled Aleex Sjarki, as chief executive and describes the development of its own gateway, acquiring and processing platform. That history explains the integrated service model without treating every group office as a separately licensed payment institution.[26]

Operator

Ecommpay Limited

Service scope

Payment gateway, acquiring, alternative payments, open banking, merchant reporting and payouts.

Customer types

Approved FinTech merchants; Online businesses; Eligible UK small businesses

Delivery

API; Hosted; Managed service

Pricing publication

Public and quoted pricing

Platforms

Payment Page; Gate; Dashboard; Data API

Pricing scope

Public UK microenterprise/small-charity tariff; separate commercial terms for approved financial-services arrangements.

Implementation

Merchant approval, integration testing and production activation; assisted card-token and recurring-payment migration.

Support

Account-management and technical support, with separate small-business and formal complaint routes.

Permissions and regulatory scope

UK payment-institution scope disclosed under FCA 607597. Payment funds are safeguarded, not FSCS-covered bank deposits; merchant approval remains activity-specific.

Provider metadata checked 20 Oct 2026Source 1Source 18Source 2Source 11Source 14Source 15Source 16Source 19Source 6Source 7Source 22

Data API tokens inherit a specific Dashboard user’s project permissions. Only the newest token for that user remains valid; a replacement rotates the accompanying secret, which is shown only at creation. Changing the user’s access rights changes what the existing token may retrieve without requiring token regeneration.[23]

Removing permission to manage tokens does not itself revoke an already valid token. Deleting the user removes its inherited data-access rights, but the documentation says it does not automatically deactivate the token string. For a staff departure or supplier handover, those distinctions make explicit token deactivation and access removal separate controls. The API guidance recommends no more than 60 requests per minute per user and waiting at least three seconds after a rate-limit response.[23]

Small-business plug-in availability should also be kept separate from wider enterprise integration. The current small-business FAQ identifies WooCommerce and Magento routes and says that native Shopify integration is unavailable. A familiar shopping-cart plug-in therefore does not establish compatibility with a broker’s cashier or CRM; the platform’s hosted and direct integration paths define that separate implementation.[11]