> ## Documentation Index
> Fetch the complete documentation index at: https://docs.daya.co/llms.txt
> Use this file to discover all available pages before exploring further.
# Handling Amount Mismatch
> How Daya handles underpayments and overpayments for temporary NGN funding accounts
# Handling Underpayments and Overpayments
## Overview
When creating a **temporary NGN funding account**, merchants specify an expected deposit amount.
This page explains what happens when a customer sends an amount that **does not match** the expected value.
This behavior applies **only to temporary NGN funding accounts**.
Permanent NGN funding accounts do not enforce a specific amount and process any transfer received.
***
## Underpayments
If a customer sends **less than** the expected amount, the deposit is **automatically refunded** to the sender's bank account.
### Example
* **Expected amount:** ₦50,000
* **Customer sends:** ₦45,000
* **Result:** ₦45,000 is refunded to sender's bank account
The funding account remains **ACTIVE** until expiry, and the customer can attempt the transfer again with the correct amount.
***
## Overpayments
If a customer sends **more than** the expected amount:
1. The **correct amount is processed** normally
2. The **excess amount is refunded** to the sender
### Example
* **Expected amount:** ₦50,000
* **Customer sends:** ₦55,000
* **Result:**
* ₦50,000 is processed and converted to stablecoin
* ₦5,000 is refunded to sender's bank account
***
## Fidelity Bank Exception
**Fidelity Bank behaves differently:**
For transfers originating from Fidelity Bank, any mismatch between the expected and actual amount will cause the transaction to **fail entirely**.
* **Underpayment from Fidelity Bank** → Transaction fails
* **Overpayment from Fidelity Bank** → Transaction fails
No funds are processed. The customer must initiate a new transfer with the **exact expected amount**.
### Why This Happens
This is due to technical constraints specific to Fidelity Bank's transfer processing system.
### Recommendation
When displaying bank details to customers, **always emphasize the exact amount** if there's a possibility they are using Fidelity Bank.
***
## How Refunds Work
Refunds are processed automatically by Daya and typically arrive within:
* **1-2 business days** for most banks
* May take longer depending on the sender's bank
Merchants are **not charged** for refunded amounts.
Refunds are handled transparently. No merchant action is required.
***
## API Behavior
When an amount mismatch occurs:
| Event | Deposit Status | Webhook Event |
| --------------------------- | ------------------------------ | ------------------- |
| Underpayment (non-Fidelity) | Not created | None |
| Overpayment (non-Fidelity) | `SETTLED` (for correct amount) | `deposit.completed` |
| Mismatch (Fidelity) | `FAILED` | `deposit.failed` |
The deposit object reflects only the **processed amount**, not the refunded portion (for overpayments).
***
## Which Banks Are Affected?
This automatic refund behavior applies to transfers from **all Nigerian banks except Fidelity Bank**.
### Common Banks (Automatic Refund)
* Access Bank
* GTBank
* UBA
* Zenith Bank
* First Bank
* Kuda
* Opay
* And all others except Fidelity
### Fidelity Bank (Transaction Fails)
Exact amount match is **required**.
***
## Best Practices
When showing bank details to customers, make the expected amount **highly visible** and emphasize that it must match exactly.
If you know or suspect a customer is using Fidelity Bank, explicitly warn them that the amount must be exact.
Sandbox mirrors production behavior for amount mismatches. Test your flow with under/overpayments to see how your system handles refunds.
Set up webhook listeners for `deposit.failed` events to catch Fidelity Bank mismatches and notify customers to retry.
***
## Related Pages
Learn about temporary NGN funding accounts
Understand deposit lifecycle and statuses
See other merchant-facing limits