The PSP says the payment succeeded, the CRM says it is pending, the client has a screenshot, a transaction ID, and a growing suspicion that someone has misplaced their money.
Naturally, the witch hunt begins.
The client blames the broker, support points toward the payment provider, finance summons the technical team, and the CRM remains at the center of the crime scene, displaying the least helpful word in payments: pending.
Everyone has evidence and everyone has a suspect.
Before making an arrest, the brokerage needs to reconstruct what happened after the PSP approved the transaction. Did the status update reach the CRM? Was it rejected during verification? Did it arrive carrying a transaction reference nobody recognized?
Let us examine the suspects.
First, How Can Two Systems Show Different Statuses?
A successful payment at the PSP and a successful update inside the CRM are separate events.
Once the PSP processes a payment, it usually sends the result to the connected system through a webhook or callback. In plain English, this is an automated message telling the CRM:
“Transaction 47582 succeeded. You may update your records.”
In a nutshell, webhooks are notifications that allow connected systems to respond to events such as successful payments.
If anything happens to that message, the PSP may close its case while the CRM keeps waiting.
That brings us to our first suspect.
Suspect #1: The Webhook That Never Arrived
Last seen: Leaving the PSP with a successful payment update.
Current whereabouts: Unknown.
The PSP may have processed the payment correctly and attempted to notify the CRM. However, the webhook could have:
-
Been sent to an incorrect endpoint
-
Timed out during delivery
-
Reached an unavailable server
-
Received an unsuccessful HTTP response
-
Entered the PSP’s retry cycle
These delivery failures are common enough for major PSPs to provide dedicated webhook logs and troubleshooting tools. While the webhook works its way through the retry system, the CRM continues displaying the last status it knows: pending.
Suspect #2: The Webhook Turned Away at the Door
Alibi: “I reached the CRM.”
Security report: “We could not verify that.”
Payment notifications cannot stroll into a CRM without identification. The receiving system must confirm that the message genuinely came from the PSP.
That usually involves a signature, secret key, or authentication credentials. If the credentials are incorrect or outdated, the CRM may reject the update.
Some webhook signature failure causes, include:
-
An incorrect endpoint secret
-
A changed request body
-
A missing or invalid signature
-
Differences between test and live webhook secrets
Even changes in formatting, whitespace, or encoding can interfere with signature verification.
In this case, security did its job, but unfortunately the payment status remains waiting in the lobby.
Suspect #3: The Transaction with an Identity Problem
Evidence recovered: One successful payment.
Problem: Nobody knows which pending CRM record it belongs to.
For the CRM to update a transaction, it needs to match the PSP’s notification with the correct client, account, amount, and payment request.
The message may arrive carrying:
-
An incorrect or missing transaction reference
-
The wrong client or trading account ID
-
A different currency
-
An unexpected amount
-
A duplicate reference
-
Test-environment details sent to a live system
The PSP reference and CRM reference deserve particular attention. If those identifiers do not connect, the CRM may receive a perfectly valid payment update without knowing where to file it.
The witness has arrived while its name is missing from the guest list.
Suspect #4: The Status Translator
PSP statement: “Approved.”
CRM translation: “Could you be more specific?”
Payment providers do not all describe their transaction lifecycles in the same way. Depending on the provider and payment method, statuses may include:
-
Authorized
-
Approved
-
Processing
-
Captured
-
Completed
-
Settled
-
Successful
Those words cannot always be treated as interchangeable.
For example, PayPal distinguishes between PAYMENT.CAPTURE.PENDING and PAYMENT.CAPTURE.COMPLETED, while Stripe considers a succeeded Payment Intent complete.The CRM integration must translate each provider’s status correctly. A changed API response, newly introduced status, or incorrect mapping can leave one system celebrating while the other is still reviewing the paperwork.
Suspect #5: Duplicate Webhooks, The Repeat Offender
Number of appearances: Two.
Number of payments: Possibly one.
PSPs may resend webhook events when they do not receive the expected acknowledgment. The same notification can therefore arrive more than once.
It’s advisable that integrations handle duplicate webhook events and recommended to track previously processed events to prevent the same transaction from being handled repeatedly.
Duplicate or conflicting updates may trigger additional checks inside the payment workflow - they also make hasty manual approval risky.
If support approves a pending deposit and the delayed webhook arrives ten minutes later, the same payment could knock twice. That is how one irritated client turns into one very irritated finance team.
Suspect #6: The Broker’s Own Rules
PSP verdict: Cleared.
Internal Affairs: Still reviewing.
A successful PSP update does not always trigger immediate account crediting. The transaction may still need to pass through the broker’s configured payment workflow.
Depending on the setup, the CRM may be checking:
-
Transaction limits
-
Manual approval requirements
-
Currency conversion
-
Client or account conditions
-
Compliance and risk rules
-
Internal crediting settings
FXBO CRM allows brokers to configure provider-related settings, transaction limits, fees, conversion rates, and approval processes around deposits and withdrawals.
Sometimes the pending status is doing exactly what the broker configured it to do. The investigation simply took an unexpected turn toward headquarters.
How to Investigate Payment Status Without Arresting the Wrong System
Before blaming the PSP, CRM, integration, or client, collect the complete case file:
-
PSP transaction ID
-
CRM transaction ID
-
Exact PSP status
-
Client and trading account
-
Amount and currency
-
Time of payment
-
Webhook delivery status
-
PSP response
-
CRM callback logs
-
Internal approval status
-
Account-crediting status
Then trace the payment in order:
Payment request → PSP result → webhook delivery → CRM verification → transaction matching → internal rules → account crediting
The point where the trail stops usually reveals which team needs to take over.
Payment Case Closed?
Payment pending in CRM mysteries are almost always solved by following the status trail.
FXBO CRM connects brokers with 400+ payment providers and gives teams a centralized view of payment activity, including the transaction type, status, PSP, account, date, and amount.
Payment issues will still find creative ways to generate support tickets. Better visibility gives support, finance, and technical teams a shared case file before the witch hunt begins.
Want a clearer view of what is happening between your PSPs, CRM, and client accounts? Request a free FXBO CRM demo and put your payment investigations on firmer evidence.
