Set how PD Crypto Pay handles differences between the quote and the amount that arrives. Review these choices before taking payments so staff can distinguish automatic acceptance from a case that needs review.

Set the payment window

1. Open PD Modules → PD Crypto Pay → Settings.
2. Set Payment window (minutes) for the period during which the quote’s crypto amount is locked.
3. Review Keep watching an expired quote (hours) separately.
4. Save and explain the expiry/review behaviour to your support team.

Extending observation after expiry does not extend the original rate lock. A payment first seen inside the window can be credited after its required confirmations; one first arriving later is held for review under the late-payment flow.

Choose the short-payment tolerance

Accept slightly short payments (%) decides how much of a shortfall you are willing to accept as paid in full. 0 permits no shortfall; a larger allowed percentage accepts a larger shortfall. Overpayments are handled separately under the excess-payment policy. Lowering it makes acceptance stricter.

The tolerance is your decision to absorb that difference. A customer may arrive short after a sending service deducts a fee, but increasing tolerance also changes which amounts you accept automatically. Review the net amount received rather than treating the sender’s submitted amount as the amount you received.

The separate Markup on the crypto amount (%) changes the quoted amount. It is not the same as tolerance, and neither setting guarantees that every fee or later rate movement is covered.

Decide what happens to excess

Under When a customer overpays, choose Add the extra to their account credit or Hold for my manual review. Review how this fits your refund process: money already credited to the account should not also be refunded as though it remained unallocated surplus.

Check the result with test payments

Use a controlled test-network rehearsal to check the configured policy, invoice credit and timeline. Review an underpayment and an excess-payment case separately. Do not change a live payment’s settings simply to make an unexplained accounting difference disappear.

With One address for everything, an unusual amount can need manual attribution when several invoices might own it. A dedicated receiving address per payment reduces that matching ambiguity. Use the payment timeline to investigate the specific receipt before settling or crediting it manually.

See the PD Crypto Pay guide for Blesta for related tasks, or explore the module.