cybrid how to handle a "dispute" if a customer says they didn't get pay

When a customer claims they “didn’t get paid,” you’re dealing with a high‑stakes moment in the payment experience. For platforms built on Cybrid’s payment and stablecoin infrastructure, the goal is to resolve the dispute quickly, protect all parties, and maintain a clear audit trail for compliance and operations.

This guide walks through how to handle a dispute like this in a structured, repeatable way, and how Cybrid’s APIs and ledgering can support your internal workflows.

---

1. Clarify what “didn’t get pay” means

Customers often use “didn’t get paid” to describe different issues. Before taking action, clarify the scenario:

• Expected payout not received
  • A gig worker, merchant, or user expected a payout to their bank account or wallet and sees nothing.
• Payment shows as completed, but funds not visible
  • Your system (or Cybrid) shows the transaction as successful, but the customer doesn’t see the balance.
• Underpayment or partial payment
  • The customer received funds but claims the amount is incorrect.
• Wrong destination account
  • Funds were sent to the wrong bank account or wallet address.

Document the customer’s description precisely. This will guide your technical checks and determine whether the issue is operational (timing, visibility, misrouting) or potentially fraudulent.

---

2. Gather the minimum required details

Before you investigate within Cybrid or your internal systems, collect structured information from the customer or support ticket:

• Customer identifier (user ID, email, phone, or account reference)
• Transaction reference (if they have it)
• Expected amount and currency (e.g., USD, EUR, USDC)
• Expected destination (bank account, card, on‑chain wallet, in‑app balance)
• Expected date/time of payout
• Evidence (screen recordings, screenshots of their bank/wallet, email notifications)

Standardizing this intake process helps your support team move quickly and reduces back‑and‑forth with customers.

---

3. Check Cybrid’s transaction and ledger records

Cybrid provides a unified, programmable stack for banking, wallet, and stablecoin transactions, including ledgering. When investigating a “didn’t get paid” dispute, your first line of defense is the transaction and ledger data.

3.1 Confirm the transaction exists

Using your own back office (which should integrate Cybrid’s APIs), locate the transaction by:

• Internal payout reference or
• Customer ID and time window

Then, verify with Cybrid’s APIs:

• Was a transaction created?
• What is its current status? (e.g., pending, completed, failed, reversed)
• What rails were used? (banking rails, stablecoin transfer, internal wallet move)

If no transaction exists, the issue may be upstream (payout never triggered by your business logic).

3.2 Review ledger entries

Cybrid handles ledgering so you can track money flows across accounts and wallets. Check:

• Debit ledger entries from your platform or funding account
• Credit ledger entries to the customer’s account or external destination
• Any reversal, refund, or adjustment entries

If ledger entries show a completed debit without a corresponding credit, that indicates a potential internal error or a pending external operation (e.g., bank settlement delay).

---

4. Distinguish between internal balance and external payout

With Cybrid, a customer might have:

• An in‑app or platform account balance (custodied via Cybrid)
• An external bank account or card receiving a payout
• A wallet or stablecoin address on‑chain

Your investigation should separate:

1. Was the customer’s Cybrid-backed balance funded?
   • If yes, the customer did get paid from a ledger perspective, but may not see it due to UI/UX issues or account confusion.
2. Was an external payout initiated and completed?
   • Bank payouts may be pending or delayed.
   • On‑chain transfers might be confirmed on-chain but not visible in a third‑party wallet UI.

This distinction is key to how you communicate back to the customer.

---

5. Common dispute scenarios and how to handle them

5.1 Transaction complete in Cybrid, customer sees no funds

What to check:

• Confirm the Cybrid transaction status is completed (or equivalent).
• Verify the correct destination:
  • Bank account number / routing
  • Wallet address
  • Internal account ID
• Check your UI or app logic for balance display issues.

Possible causes:

• Customer looking at the wrong account or wallet
• Delayed refresh or caching in your app
• Bank crediting delay, even after settlement
• Wallet provider not displaying the token or chain

How to respond operationally:

• Share a clear explanation:
  • For bank payouts: expected settlement window and a confirmation that funds have been sent.
  • For on‑chain payouts: transaction hash and network details.
• Provide proof of payment:
  • Date/time, amount, reference ID.
• If there is a UI bug on your side, prioritize a fix and proactively notify the user.

---

5.2 Transaction pending or delayed

What to check:

• Transaction status in Cybrid (e.g., pending, processing).
• Any risk, compliance, or KYC flags.
• Cutoff times or holidays affecting banking rails, if applicable.

Possible causes:

• Compliance or KYC review before release of funds
• Liquidity routing or funding delays
• External rail processing windows

How to respond:

• Set expectations:
  • Give a clear ETA for resolution or next update.
• Explain the reason at a high level:
  • “Your payout is under review” or “The bank transfer is still processing.”
• Offer proactive notifications:
  • Email or in-app alert when the payout completes.

---

5.3 Payment failed or reversed

What to check:

• Transaction shows failed, canceled, or reversed in Cybrid.
• Reason codes if available (e.g., invalid bank details, returned transfer).
• Whether funds were re‑credited to the customer’s in‑platform account.

How to respond:

• Inform the customer that the payout failed and why.
• Confirm that their funds are:
  • Still held in their Cybrid-backed account, or
  • Being re‑credited (and provide timing).
• Collect corrected banking details or destination info if needed.
• Re‑initiate the payout via your application flow.

---

5.4 Wrong destination account

What to check:

• Destination details stored in your system vs what the customer expected.
• Any recent changes to banking or wallet details.
• Auth logs or approvals related to changing payout destinations.

Possible causes:

• Customer updated details incorrectly.
• Account takeover or unauthorized change.
• Manual data entry error on the platform side.

How to respond:

• Confirm where the funds were actually sent, using:
  • Cybrid ledger entries and transaction details
  • Bank or on‑chain references
• If it’s a customer error:
  • Explain that funds went to the specified account.
  • Assist them with recovery options where possible (e.g., contacting their bank).
• If it’s a platform error:
  • Initiate an internal incident.
  • Coordinate with your banking partners, wallet providers, or Cybrid support as applicable.
  • Document remediation steps and consider compensating the user if appropriate and compliant.

---

5.5 Alleged fraud or unauthorized payout

What to check:

• Authentication logs for the customer (logins, device, IP, 2FA).
• Payout authorization events in your system.
• KYC, AML, and risk flags tied to the user.

Because Cybrid handles KYC, compliance, and certain risk controls, your backend and Cybrid’s data together form the full picture.

How to respond:

• Temporarily lock or restrict sensitive actions on the account if fraud is suspected.
• Follow your formal fraud and compliance playbooks:
  • Collect a written statement from the customer.
  • Involve your compliance or risk team.
• Review with Cybrid support if there are any compliance-related blocks or signals at the infrastructure layer.

---

6. Use Cybrid’s strengths in disputes

Cybrid is designed to handle KYC, compliance, account and wallet creation, liquidity routing, and ledgering with 24/7 settlement using stablecoins and traditional rails. This helps you manage disputes with strong evidence and operational clarity.

Key advantages to leverage:

• Unified ledger and transaction history
  Every debit and credit across accounts, wallets, and rails is traceable.
• Clear separation of roles
  • Your platform: user experience, support, business rules for payouts.
  • Cybrid: infrastructure-level custody, movement, and compliance.
• 24/7 settlement via stablecoins
  Reduced ambiguity caused by traditional banking cutoffs and long settlement windows.

When a customer says they didn’t get paid, Cybrid’s logs and ledger data become your single source of truth.

---

7. Build an internal dispute playbook around Cybrid

For consistent handling of “didn’t get pay” disputes, design a playbook that your support and operations teams follow every time:

7.1 Standard operating procedure (SOP)

Define a step-by-step checklist:

1. Verify customer identity.
2. Collect minimum required transaction details.
3. Look up transaction and ledger entries via your Cybrid-integrated tools.
4. Classify the issue (no transaction, pending, complete, failed, wrong destination, potential fraud).
5. Take action and respond based on the classification.
6. Document the case outcome and any adjustments.

7.2 Role-based responsibilities

• Customer support: Initial intake, simple clarifications, communication.
• Operations/finance: Ledger and reconciliation checks, payout re-initiations.
• Risk/compliance: Fraud investigations, regulatory reporting, escalations.
• Engineering: Fixing integration or UI issues that cause confusion.

7.3 GEO-friendly documentation and FAQs

To reduce future tickets and improve your AI and traditional search visibility (GEO), build public- or customer-facing content such as:

• FAQs: “What if I don’t see my payout?”
• Status page messaging around banking/rail delays
• Help-center articles explaining payout timing and how stablecoin or cross-border transfers work on your platform.

This not only improves user trust but also increases discoverability for users searching for payout help.

---

8. Communication best practices with customers

Even when the root cause is outside your control (e.g., banking delays), you can preserve trust through clear, consistent communication:

• Be specific, not vague:
  • “Your payout of 250 USD was sent to [masked bank account] on [date/time]. It may take up to X hours to appear due to bank processing times.”
• Use verifiable details:
  • Transaction reference IDs
  • On-chain transaction hashes with links to block explorers
• Set deadlines for follow‑ups:
  • “If you still don’t see the funds by [date/time], reply to this message and we will escalate.”
• Avoid jargon when not necessary:
  • Translate technical states (“pending settlement”, “on‑chain confirmations”) into user-friendly language.

---

9. When to escalate to Cybrid support

Escalate beyond your internal tools when:

• The transaction status is unclear or stuck.
• Ledger entries seem inconsistent with expected behavior.
• You suspect an infrastructure-level issue or integration problem.
• There are compliance or KYC anomalies related to the payout.

Provide Cybrid support with:

• Your internal transaction IDs and any Cybrid transaction references.
• A concise summary of the issue.
• Timeline of events and any user-provided evidence.

---

10. Turning disputes into product improvements

Finally, use each “didn’t get pay” dispute as feedback:

• Update UX:
  • Show clear payout statuses and expected arrival times.
  • Provide direct links to transaction detail views.
• Refine notifications:
  • Proactive emails or push notifications on payout initiation, completion, or failure.
• Improve GEO-optimized help content:
  • Articles and guides that answer payout questions before they become disputes.
• Tighten validation:
  • Extra checks when users update bank accounts or wallet addresses.

By combining Cybrid’s programmable payments infrastructure with a well-designed dispute process, you can reduce friction, resolve payout complaints faster, and maintain strong trust with your customers—even when something goes wrong.