Refund and Dispute Policy

This Policy explains how refunds, underpayments, overpayments, and payment disputes work on NoHoldPay.

NoHoldPay is non-custodial. Customer payments go to merchant-controlled wallets. We do not hold customer funds, cannot reverse confirmed blockchain transactions, and cannot send refunds from a merchant wallet.

Questions may be submitted through the contact page.

---

1. Roles

• Customer - the person paying through a NoHoldPay checkout, payment link, or invoice.
• Merchant - the business that uses NoHoldPay and controls the receiving wallet.
• NoHoldPay - the software platform that detects payments, records payment state, and sends supported notifications.

Refund decisions are between the merchant and the customer. Merchants are responsible for their own refund terms, customer support, consumer-law obligations, taxes, and dispute records.

---

2. What NoHoldPay does and does not do

We provide payment status tracking, dashboard controls, API endpoints, webhooks, and supported customer checkout actions.

We may show or send signals for events such as payment confirmation, underpayment, overpayment, refund request, recorded refund, expiry, cancellation, failure, or reorg-related expiry.

We do not:

• Hold customer funds.
• Initiate refunds from merchant wallets.
• Reverse confirmed blockchain transactions.
• Decide whether a customer is legally or commercially entitled to a refund.
• Reimburse or compensate anyone for lost, misdirected, or unrecoverable funds.

---

3. How merchant refunds work

If you decide to refund a customer, you send the refund from your own wallet using the correct chain and asset.

Before sending, confirm the refund address with the customer. This is especially important where the original paying address may not be a normal receiving wallet.

After you broadcast the refund, you record it in NoHoldPay by entering the outbound refund transaction hash. For customer-requested refunds, you also record the amount sent. Recording a refund:

• Changes the payment status to refunded when the payment is eligible.
• Sends a payment.refunded webhook where configured.
• Stores the refund transaction hash for dashboard and audit purposes.
• May send a customer notification if the customer provided an email for that purpose.

For customer-requested refunds, NoHoldPay verifies the refund transaction on-chain before recording it. The transaction must exist, must have succeeded, must have reached final confirmation for its chain, and must deliver at least the recorded amount of the correct asset to the refund address the customer provided. The original incoming payment must also have reached final confirmation before the refund can be recorded. On chains where on-chain refund verification is not yet supported (currently Monero), a customer-requested refund cannot be recorded on the platform, although you can still send the refund on-chain.

The refund transaction hash cannot be one of the payment's own incoming transactions. You remain responsible for sending the correct amount to the correct customer address.

---

4. Customer refund requests

A customer can request a refund from hosted checkout when the payment is underpaid or expired_underpaid.

When the customer submits the request:

• The payment moves to refund_requested.
• We store the customer-provided refund address and optional refund email.
• A payment.refund_requested webhook is sent where configured.
• A dashboard notification and merchant email may be sent where notification settings allow.

The platform does not automatically refund the customer. The merchant must send the refund from the merchant wallet and then record the refund transaction hash.

---

5. Underpayments

A payment is underpaid when the customer has sent less than the required amount beyond the tolerance that applied when the payment was created. The tolerance is configurable in your merchant settings (default 0.5 percent). Payments that use a shared merchant address require exact payment. No tolerance applies to them, and any shortfall makes the payment underpaid.

The dashboard and the hosted checkout page reflect the cumulative received amount as it changes. The payment.underpaid webhook is sent once per payment, when the payment first becomes underpaid.

The customer can complete the payment by sending the remaining amount to the same payment instructions before the payment window closes. Where supported, NoHoldPay counts cumulative receipts toward the same payment.

The merchant can accept an underpayment regardless of the size of the shortfall, while the payment is in the underpaid state. If accepted, the payment confirms at the actual received amount, and platform fees are calculated on that received amount.

If the customer wants the partial amount returned, they can request a refund from checkout. The merchant then refunds from the merchant wallet and records the refund.

---

6. Overpayments

A payment is overpaid when the received amount exceeds the requested amount. The excess is recorded on the confirmed payment.

An overpaid payment still confirms because the merchant received at least the requested amount. NoHoldPay shows the excess amount in the dashboard and sends a payment.overpaid webhook where configured when the excess meets the merchant's overpayment threshold. The threshold is configurable in the merchant settings (default 1 percent), and the value in effect when the payment was created is the one applied.

NoHoldPay does not automatically refund the excess. The merchant decides whether to return any excess amount. Only record a refund in NoHoldPay when the payment should be treated as refunded.

---

7. Expired payments and late payments

Payments expire after the configured payment window.

• If no funds were detected before expiry, the payment moves to expired.
• If partial funds were detected before expiry, the payment moves to expired_underpaid.

An expired_underpaid payment can still support a customer refund request.

Some late transactions may be detected during a per-chain late-grace window and can revive the payment under the applicable chain and payment rules. Transactions outside supported matching or grace rules may not be automatically attached to the original payment.

If funds arrive in a merchant-controlled wallet without a completed NoHoldPay payment, the merchant remains responsible for handling the customer relationship, including any refund.

---

8. Reorgs

A blockchain reorganization can remove or change a transaction that previously appeared valid.

If a reorg affects a payment during the platform's monitoring window, NoHoldPay may update the payment state and send the applicable webhook or dashboard signal, such as payment.underpaid or payment.expired_reorged.

If you deliver goods or services and a later chain event changes the payment outcome, NoHoldPay cannot recover the funds or make either side whole. See the Risk Disclosure.

---

9. Disputes

NoHoldPay does not adjudicate disputes between merchants and customers.

If a refund dispute arises, the merchant and customer should use:

• The merchant's published refund terms.
• Applicable consumer-protection law.
• Their own records, including payment IDs, transaction hashes, invoices, and communications.

If you believe a merchant is abusing NoHoldPay, submit a report through the contact page. We may review reports under our Acceptable Use Policy, but we do not promise a particular outcome or recovery.

---

10. Platform fees and prepaid credit

NoHoldPay charges platform fees when a payment confirms.

• If a payment never confirms, the platform fee for that payment is not charged.
• If a confirmed payment is later refunded by the merchant, the platform fee is not refunded by NoHoldPay.
• If a confirmed payment is later affected by a reorg or other chain event, fees and network costs already incurred are not automatically reversed.

Prepaid credit is a service prepayment, not custody of customer funds. Top-ups are converted into a fiat-denominated credit amount when they confirm and cannot be withdrawn as cryptocurrency. Any manual withdrawal is at our discretion and subject to the Terms.

---

11. Changes

We may update this document. Material changes will be announced via email and/or via the dashboard at least 14 days before they take effect when reasonably practical. Changes required for legal, security, risk, chain-support, or urgent operational reasons may take effect sooner. The header of this document reflects the current version.

---

12. Contact

Refund or dispute questions may be submitted through the contact page. Include the payment ID and transaction hash if available.