What Payclave checks before an invoice becomes paid.

Browser state belongs to the customer environment. It can close early, report stale data, receive a forged callback, or show a submitted transaction that later fails. A payment-orchestration system can also report route progress before the merchant settlement is final.

Payclave records those signals, but it does not use them as the sole reason to mark an invoice paid. The payment moves to validating while independent verification checks the settlement evidence.

Verification starts with the expected invoice and the transaction associated with the payment attempt. Payclave checks the transaction hash, destination chain, settlement token contract, merchant-controlled recipient wallet, amount received, invoice timing policy, and confirmation state.

The settlement destination remains Polygon USDC or USDT for the current merchant configuration even when a supported customer route starts with another token or network. Routed payment records can retain both source and settlement transaction facts without treating the source transfer as the merchant receipt.

• The transaction exists on the expected chain and has the required confirmation state.
• The token transfer uses the expected USDC or USDT contract on Polygon.
• The transfer credits the settlement wallet snapshot attached to the invoice.
• The received amount satisfies the invoice and platform-fee rules for that route.
• The payment timing is evaluated against the invoice expiry policy.
• The transaction has not already been assigned to another payment.

An exact verified customer credit can complete the invoice. A verified amount below the remaining total becomes underpaid and can be followed by a new exact-remainder checkout. An amount above the expected total becomes overpaid or, for an approved exact-output route with a permitted buffer, can still satisfy the invoice while preserving the amount facts.

The merchant sees the payment record and exception instead of a false binary answer. That matters because fulfillment, customer support, and accounting often need different responses to a short payment, a duplicate, and a late settlement.

A submitted transaction is not automatically confirmed. Payclave can retry verification while a transaction is pending and records the eventual confirmed or failed outcome. Confirmation requirements belong to the verifier and chain configuration rather than the customer browser.

If evidence arrives late or out of order, confirmed server evidence takes precedence over an earlier browser-derived abandoned state. Payclave still preserves the timing facts needed to decide whether the invoice was paid on time or requires review.

Use a verified invoice.paid webhook or a confirmed secret-key API read as the trigger for fulfillment. Verify the webhook signature and process its event ID once. Keep the settlement transaction hash for reconciliation, not as the only proof that the correct order was paid.

Payclave provides payment evidence and status records. The merchant still controls the settlement wallet, fulfillment policy, refund decisions, and recovery of its own wallet credentials.