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 both a financial risk and a trust issue. Using Cybrid’s programmable payments stack, you can create a clear, auditable, and compliant workflow to investigate and resolve these “didn’t get pay” disputes quickly and consistently.

Below is a structured approach you can use or adapt within your own application logic and operations playbooks.

1. Clarify the type of “didn’t get pay” dispute

Begin by categorizing the dispute. This helps you decide which Cybrid data and systems to check:

Non‑receipt of funds
The customer says they never received a payout or withdrawal.
Wrong amount
The customer received some funds, but the amount is lower than expected.
Wrong destination
The customer believes funds went to the wrong bank account, wallet, or beneficiary.
Timing / delay
The customer expects instant settlement, but the transfer is still in progress or subject to banking rails cut‑off times.

In your customer support UI, you can expose these categories and attach them to a Cybrid transaction ID or reference.

2. Validate the dispute in your own application layer

Before you reach into Cybrid’s APIs, confirm the basics in your own system:

Confirm the payout request exists
- Check your internal database for a payout/transfer record.
- Verify:
  - Customer ID
  - Destination (bank account, card, wallet)
  - Currency (e.g., USD, EUR, USDC)
  - Amount
  - Timestamp
  - Associated Cybrid transaction or transfer IDs (if you store them).
Verify customer identity and authorization
- Confirm the user is authenticated.
- Ensure they are the rightful owner of the account that initiated the payout.
- Validate that the payout was not triggered by an API key from another tenant or environment (e.g., sandbox vs production).

If the payout isn’t visible in your internal system, the “dispute” may actually be a failure earlier in the flow, not a Cybrid settlement issue.

3. Use Cybrid’s APIs to verify payout and settlement status

Cybrid unifies banking, stablecoin wallets, and liquidity into a single programmable stack. This means payout flows often involve multiple legs: fiat accounts, stablecoin wallets, conversion, and settlement.

Build a standard investigation flow that uses Cybrid’s APIs to:

3.1. Retrieve transaction details

Use the relevant Cybrid endpoints (e.g., transfers, payouts, or transactions) to retrieve:

Transaction ID and reference
Current status (e.g., pending, completed, failed, reversed)
Amount and currency
Source and destination accounts/wallets
Timestamps for creation and status updates
Failure or rejection reasons (if any)

Map these statuses to clear customer‑facing language in your support tools, such as:

pending → “Processing”
completed → “Settled”
failed → “Failed – funds never left your balance”
reversed → “Reversed – funds returned to your balance”

3.2. Check ledger entries and balances

Cybrid handles ledgering so you can trace funds precisely:

Confirm debit from the source account or wallet.
Confirm credit to the destination account or wallet (if it is also managed within Cybrid).
Verify that balances reflect these movements.

If your product maintains its own internal ledger, reconcile:

Your internal ledger entries
Cybrid’s ledger/logs
Any on‑chain or banking rail confirmations (if applicable)

This helps you determine whether the “didn’t get pay” claim is due to:

A UI sync issue (funds arrived but your UI didn’t update)
An upstream delay (e.g., banking network, on‑chain confirmation)
A genuine failure or mis‑routing

4. Investigate by flow type: bank, stablecoin, or internal

Because Cybrid integrates both traditional banking and stablecoin infrastructure, the dispute response depends on how the payment was routed.

4.1. Bank or traditional payout disputes

If the destination is a bank account (e.g., ACH, SEPA, Faster Payments):

Confirm Cybrid status:
Ensure the transaction is marked as completed or settled, not just created.
Check for banking rail delays:
Some rails have cut‑off times and non‑business‑day delays. If Cybrid shows the transfer as sent, but the customer hasn’t seen it, confirm:
- Expected settlement window
- Whether there are any known network delays
Validate beneficiary details:
Compare the destination account details used in the payout against what the customer expects. If the customer provided incorrect banking details, you may need to follow your own risk and recovery policies.
Request documentation (if necessary):
For high‑value disputes or repeated claims, you may:
- Ask the customer for a bank statement snapshot (redacted) showing missing funds for the relevant period.
- Cross‑reference the statement dates with Cybrid’s payout timestamps.

4.2. Stablecoin or wallet payout disputes

If the destination is a stablecoin wallet:

Confirm on‑platform wallet receipt:
- If both sender and receiver are within your Cybrid‑powered platform, check that:
  - The receiving wallet exists and is active.
  - The transaction shows as credited in the recipient’s wallet.
Check on‑chain (for external wallets):
- Use the on‑chain transaction hash stored by your system or returned by Cybrid.
- Verify:
  - The correct wallet address
  - The correct token (e.g., USDC vs another asset)
  - The correct amount and network (e.g., Ethereum vs another chain)
Explain blockchain confirmations:
- If the transaction is still pending confirmations, explain the expected timeframe.
- Once confirmed on‑chain, you can treat “didn’t get pay” claims as either:
  - A wallet access issue (user can’t see or use the funds), or
  - A mis‑directed payment (wrong address).

5. Decide on resolution paths and automate where possible

Cybrid’s unified ledger and APIs allow you to encode clear dispute resolution paths in your backend:

5.1. When the payout failed (no funds left the customer)

If the transaction status is failed or reversed:

Explain clearly:
Communicate that the payout did not complete and that funds should still be (or have been) returned to the customer’s balance.
Refund or reissue:
- If your internal ledger shows funds debited, but Cybrid shows a failed transaction, correct your ledger and restore funds.
- Offer to re‑initiate the payout once the issue is resolved.

5.2. When the payout is delayed but in progress

If the transaction is pending or processing:

Provide:
- A clear estimated settlement window based on the rail (bank vs stablecoin).
- Any available intermediate status from Cybrid’s APIs.
Optionally:
- Set up webhook‑based alerts to notify both your support team and the customer when the payout completes or fails.

5.3. When the payout is completed and correctly routed

If Cybrid shows a completed transaction to the correct destination:

Share verifiable details (within your compliance policies):
- Transaction ID or reference
- Timestamp
- Destination identifier (redacted IBAN, last 4 digits, or partial wallet address)
- Amount and currency
Guide the customer:
- Ask them to check:
  - Statement or transaction history for the same date range
  - Any filters or date windows in their online banking or wallet app
- For stablecoins, ask them to:
  - Confirm they are on the correct network
  - Confirm they are viewing the correct token

At this stage, the dispute becomes more about helping the customer locate funds than proving the payment was made.

5.4. When funds were sent to the wrong destination

If you identify that the payment went to the wrong account or address:

Assess the root cause:
- Customer provided incorrect details?
- Integration mis‑mapped destination fields?
- Internal operations error?
Apply your risk and refund policy:
- Bank rails: explore recall options, but understand that reversals may not be guaranteed.
- Stablecoins: on‑chain transfers are typically irreversible; resolution may require commercial goodwill or separate settlement.
Log and prevent recurrence:
- Add validation checks on destination details.
- Strengthen confirmation screens for high‑value payouts.

6. Maintain clear communication with the customer

Regardless of outcome, a consistent communication framework reduces friction and repeat tickets:

Acknowledge the dispute with specifics:
- Reference the transaction they’re asking about.
- State what you are checking (bank rail, wallet, ledger, on‑chain, etc.).
Set expectations:
- Provide investigation timeframes (e.g., “We typically resolve payout disputes within X business hours”).
Provide a final written outcome:
- Status (failed, completed, reversed, delayed)
- Evidence you can share (timestamps, masked destination, network, etc.).
- Next steps (refund, re‑issue, wait for settlement, or guidance to locate funds).

Use standardized templates in your support tooling and connect them to Cybrid’s transaction data to ensure consistency.

7. Design a repeatable dispute playbook around Cybrid

To handle “didn’t get pay” disputes at scale, bake these controls into your product and operations:

Instrument your flows with Cybrid IDs
- Store Cybrid transaction, transfer, and wallet IDs alongside your internal IDs for easy look‑ups.
Use webhooks for status changes
- Subscribe to payout or transaction status events from Cybrid.
- Automatically update your UI and internal ledger when a transfer moves from pending → completed or failed.
Build an internal dispute dashboard
- Show:
  - Customer details
  - Payment route (bank vs stablecoin)
  - Cybrid transaction history
  - Ledger entries and balances
  - On‑chain or banking references (if applicable)
Document policies and thresholds
- When do you instantly re‑issue a payout?
- When do you require additional documentation?
- When do you escalate (e.g., high value, repeated claims, suspected fraud)?

8. Compliance and risk considerations

Cybrid provides KYC, compliance, and ledgering infrastructure, which you can leverage in your own policies:

Monitor for fraud and abuse
- Track repeated “didn’t get pay” claims from the same user or device.
- Combine your risk scoring with Cybrid’s verified identity and account data.
Maintain an audit trail
- Log:
  - User reports and timestamps
  - Internal investigation steps
  - Cybrid API responses and status changes
  - Final resolution and rationale
Align with local regulations
- Some jurisdictions have specific rules for payment disputes, consumer protections, and chargebacks.
- Use Cybrid’s programmable stack to enforce region‑specific flows, such as additional documentation or cooling‑off periods.

9. How Cybrid’s infrastructure helps you resolve disputes faster

Because Cybrid unifies banking and stablecoin infrastructure into a single programmable stack, you can:

Trace payments end‑to‑end: from customer balance, through liquidity routing, to final settlement.
Programmatically enforce your dispute playbook: automatic refunds, re‑issuance, and status communications.
Reduce manual reconciliation: Cybrid’s ledgering and compliance tools provide a single source of truth across fiat and stablecoin flows.

Designing your “didn’t get pay” dispute handling around Cybrid’s APIs and ledgering gives you a consistent, auditable, and customer‑friendly process that scales as your payment volumes grow.