A UAE software-company operator says a $3,850 customer payment has remained unresolved for roughly a year after Stripe suspended the company’s account, with the merchant claiming the money has neither reached its bank account nor been returned to the customer.
The allegation comes from an October 5 Trustpilot review posted by Michael Ghaly, who identified his business as Code Plus FZE, a UAE software company.
According to the reviewer, Code Plus accepted a $3,850 payment through Stripe representing 50% of the value of a software project. He says the Stripe account was subsequently suspended and that, around 12 months later, the payment still had not been paid out to the company’s bank account.
The reviewer also claims the customer has not received the money back and says attempts to contact Stripe through email and chat have been unsuccessful.
The case remains unverified. Dave Finances has not seen the underlying Stripe charge, payment ID, Dashboard balance, payout record, suspension notice, customer card statement or communications with Stripe. Stripe has not posted an account-specific response to the review in the currently surfaced Trustpilot record.
That means the most important fact is still missing: where Stripe’s ledger currently says the $3,850 actually is.
A Payment Can Be Unpaid Without Simply Being “Held”
The merchant’s description leaves several technically different possibilities open.
The payment could remain in a reserve. It could be sitting in an available or pending Stripe balance while payouts are disabled. A payout could have been attempted and failed. The transaction could have been refunded, reversed or disputed without the merchant understanding the final status. Or another balance adjustment could have changed where the funds appear inside the account.
Those possibilities are not interchangeable.
Stripe’s official reserve guidance says reserves temporarily hold part of a merchant’s funds to cover possible refunds and disputes. Stripe says merchants are normally informed of the reserve percentage and duration and can see reserve balances and future release information in their Dashboard.
Stripe says reserves are commonly maintained for around 30 to 90 days, although the exact terms depend on account risk and circumstances.
A claimed delay approaching 12 months would therefore require more explanation than simply establishing that Stripe uses reserves.
The Charge ID Could Turn the Complaint Into a Traceable Payments Story
The most valuable next piece of evidence would be the Stripe payment or charge ID.
Every successful Stripe transaction creates ledger records showing what happened to the funds. The Dashboard can distinguish charges, refunds, disputes, reserve adjustments, payouts, failed payouts and other balance movements.
If the $3,850 charge remains visible, the corresponding balance history should reveal whether it ever became available for payout and what happened afterward.
A payout ID would be equally important if Stripe actually attempted to send the money to Code Plus’s bank.
Stripe’s documentation says a failed payout generally means the receiving bank could not accept it and returned the funds to Stripe. The Dashboard should display the failure and, in many cases, the underlying reason.
That distinction has mattered in other unresolved payment cases. Dave Finances recently examined a Revolut user who said $8,337.81 remained inaccessible after several outbound transfers failed. In that case, determining which institution rejected each transfer was more useful than simply describing the balance as trapped.
The same principle applies here: “Stripe did not pay me” and “Stripe attempted a payout that failed” describe materially different events.
Stripe Can Restrict Payouts After a Risk Review
Account suspension after a relatively large initial transaction would not by itself demonstrate wrongdoing by Stripe.
Payment processors continuously evaluate merchants for fraud and credit risk because the processor may remain exposed to refunds and chargebacks after merchant funds have already been paid out.
Stripe says risk indicators can include unusually sharp increases in payment volume, high dispute or refund rates, long delivery periods and business models where customers pay materially in advance of receiving a service.
The Code Plus transaction, as described by the reviewer, represented a 50% upfront payment for a project.
That fact alone does not establish that Stripe classified the business as high risk, and there is no public account-specific explanation from Stripe. But project work can create a longer period between customer payment and final delivery than an ordinary immediate retail transaction, leaving a processor exposed if a customer later seeks a refund or files a dispute.
If Stripe concluded that an account presented elevated risk, its published policies allow it to establish reserves, delay availability or, in rarer cases, end the processing relationship.
Closing or Restricting the Merchant Is Separate From Disposing of the Money
This is the central issue in the complaint.
A payment processor can decide it no longer wants to process transactions for a merchant. That does not answer what happens to a payment it has already accepted.
The same distinction appeared in a recent Skrill account-closure complaint involving newly deposited funds. The key question was not simply whether Skrill could terminate the customer relationship, but how remaining money would be returned once access had been removed.
For Code Plus, the possible outcomes should ultimately be observable.
If the money was refunded, there should be a refund object and a corresponding transaction on the customer’s payment method.
If the customer disputed the charge, there should be a dispute record.
If the funds remain reserved, the Stripe balance should show the reserve.
If a payout failed, there should be a payout entry and failure status.
If the money remains available but payouts are disabled, the Dashboard should separately show the available balance and the payout restriction.
Without that information, saying the money has been “held for a year” goes further than the current evidence supports.
A Year Would Be Very Different From an Ordinary Verification Delay
The claimed duration is what makes the report worth investigating.
Short payment delays are common when financial platforms conduct verification, risk reviews or bank reconciliation. Even a multi-week case does not automatically indicate abnormal treatment.
Dave Finances recently covered a Wise customer whose €350 transfer became stuck during verification. Wise’s published procedures showed that manual verification itself could legitimately take days, while the more interesting issue was whether the customer-facing interface provided a workable route to submit the requested information.
Twelve months would be a different category.
If Code Plus can demonstrate that the same $3,850 remains in a restricted Stripe balance after approximately a year with no unresolved chargeback, refund liability or other identifiable legal restriction, the case would raise a much stronger question about the duration and escalation of merchant fund holds.
At present, that evidence has not been published.
The Customer’s Side of the Ledger Matters Too
The merchant says the original customer was not refunded.
That statement should also be independently checked.
A customer card or bank statement could establish whether the $3,850 charge remained posted, was reversed, or was later refunded under a descriptor that the merchant did not recognize.
That creates a useful two-sided reconciliation exercise.
On the merchant side: what does Stripe’s balance history show?
On the customer side: does the original $3,850 charge still exist?
If the customer’s statement still shows a completed payment while Code Plus’s Stripe records show no payout and no refund after roughly 12 months, the complaint becomes considerably more concrete.
If the customer’s statement instead shows a reversal, the story changes.
Payment Status Is Often More Important Than the Support Complaint
The temptation with cases like this is to focus on customer service.
The reviewer says Stripe has not answered emails and that chat is unavailable. If true, that is frustrating, particularly for a merchant trying to locate thousands of dollars.
But the ledger is more important than the support history.
A recent Payoneer case involving a reportedly missing $2,000 transfer illustrated the same issue. Once money has moved across several financial systems, the useful question becomes which participant currently records the funds and in what state.
Payments infrastructure is fundamentally a chain of accounting entries.
Following those entries can distinguish a customer-service failure from a bank rejection, compliance hold, processor reserve or actual reconciliation problem.
One Review Is Not Evidence of a Stripe-Wide Payout Problem
The October 5 Trustpilot feed contains other complaints involving held payments, account restrictions and refunds, but those reports involve different merchants and circumstances.
They should not be combined into evidence that Stripe is experiencing a systemic payout failure.
Stripe processes payments for millions of businesses, and public review sites naturally concentrate dissatisfied customers more heavily than representative transaction data would.
The Code Plus complaint is interesting because of its specificity: one named UAE company, one $3,850 payment, a stated commercial purpose, a claimed one-year delay and an allegation that neither side received the money.
Those details make the case potentially verifiable.
The Strongest Story Now Depends on Four Pieces of Evidence
Four records could resolve most of the uncertainty.
First, the original Stripe payment or charge ID. Second, the current Dashboard balance and transaction status. Third, the suspension or account-closure notice showing what Stripe told Code Plus would happen to remaining funds. Fourth, the customer’s statement confirming whether the $3,850 charge remains settled.
If those records show an unresolved positive balance for approximately a year, the story becomes much more serious.
If the payment is sitting in reserve, the next question is why the reserve has lasted so much longer than the ordinary periods Stripe describes publicly.
If a payout failed, investigators can focus on the receiving bank and failure code.
If the payment was reversed or refunded, the dispute becomes one of reconciliation rather than withheld merchant funds.
Until those records emerge, the responsible conclusion is narrower than the complaint itself.
A UAE software-company operator says a $3,850 project deposit has been neither paid to his business nor returned to his customer for around 12 months following a Stripe account suspension. That allegation is specific enough to investigate, but the missing Stripe ledger state is what will determine whether this is a prolonged reserve, payout failure, refund issue, dispute liability or something else entirely.
In payment disputes, knowing that money did not arrive is only the beginning. The real story starts when you can establish exactly where the ledger says it went.
Johan Shamshad is a financial markets writer at Dave Finances covering cryptocurrencies, trading platforms, brokers, fintech, financial regulation, and developments across global markets. He previously worked at Gulf News, adding newsroom experience to his coverage of fast-moving financial and digital-asset markets.
His work focuses on identifying market-moving events, company developments, regulatory changes, product launches, and shifts in trading and financial infrastructure.
Johan contributes news and analysis designed to help readers understand not only what happened, but why a development matters and how it may affect the wider financial landscape.