Underpayments

Crypto payments are push payments: the buyer types (or scans) an amount and sends it. Occasionally they send too little — a wallet rounds down, a fee is deducted en route, or they fat-finger a digit. Qint’s underpayment handling keeps small shortfalls from blocking a sale, credits you exactly what arrived, and leaves anything larger to a human decision.

​

Accepted underpayment — small shortfalls settle

Each merchant sets an Accepted underpayment under Dashboard → Settings → Payouts: the largest shortfall, as a share of the payment, that Qint settles without asking you. The default is 1 %; you can choose anything from 0 % to 2 % (0 % means every shortfall goes to review). Only Owner and Admin users can change it, and the setting shows who set the current value. A payment short by no more than your accepted underpayment counts as paid in full — the order or invoice is Paid, and you are not asked to decide. In detail, it:

• settles normally (status: "settled") and is flagged underpaid;
• is credited for the amount actually received, not the full invoice — the received share of the invoiced amount, less Qint’s fee on that received amount;
• shows “Underpaid by x %” and Paid in the transaction detail, and the receipt shows the amount actually paid. A linked invoice is marked Paid.

​

Larger shortfalls — the underpaid flag

When the shortfall is larger than your accepted underpayment, the payment is not settled. It is flagged underpaid, with two important properties:

• It’s a flag, not a status. The intent’s status doesn’t change on detection — a pending payment stays pending.
• The payment stays payable while its 15-minute window is open. The buyer can top up by sending the remaining amount to the same deposit address; if enough arrives in time, the payment proceeds to settle normally.

You learn about the flag immediately: the payment.status webhook is re-emitted with underpaid: true, expectedCryptoAmount and receivedCryptoAmount, and the checkout page shows the buyer what’s still owed.

​

Expired underpaid — the review queue

If the window closes while the payment is still short beyond your accepted underpayment, the intent expires and enters the review queue in the dashboard. The merchant’s Owner and Admin users are notified by email that a payment came up short. For each queued payment you see the fiat amount, the asset, the expected and received crypto amounts, and the linked invoice or payment link. It is then either accepted or declined: Each payment is resolved exactly once — a second attempt is rejected. Accepting less money than the accepted underpayment allows is a commercial call, which is why it’s never automatic.

​

Overpayments

An overpaid payment (more crypto than quoted) settles normally and is credited exactly like any other payment — on the invoiced amount less Qint’s fee; the excess is not added to your balance. Your integration sees an ordinary settled event: there is no overpayment field on the payment intent and no webhook for it. Instead, the payment also appears in the dashboard’s review queue with the reason overpaid. It is informational — the payment is already paid. Refund the excess to the buyer off-platform, then Acknowledge the item (Owner, Admin or Finance role); it can be resolved once. The CSV export of your payments marks these payments in its overpaid column.

​

What your integration should do

1. Credit and reconcile on what was received. On a settled event with underpaid: true, receivedAmount is the fiat amount actually paid and underpaidBps the shortfall in basis points — use them for your books instead of amount. See the event fields.
2. Handle the flag on open payments. On underpaid: true for a non-terminal payment, hold fulfilment (the WooCommerce plugin puts the order on hold).
3. Trust settled, however it arrives. An accepted review item emits the same settled webhook as a normal payment — one code path fulfils both.
4. Treat expired + underpaid as “pending a human decision”, not as a hard failure, until the review is resolved.