Skip to main content
A verification establishes a trusted fingerprint. A check asks a later question: do the details you hold now still match that fingerprint? Use checks before payment, after payee details change, or on a scheduled review for higher-risk records.

​
When to run a check

Before payment

Compare the details about to be paid against the successful verification you stored earlier.

After a detail change

If your CRM, ERP, or payee portal updates bank details, check the new values before accepting them for payment.

Periodic review

Recheck long-lived or high-value payees on a cadence that matches your risk policy.

​
How checks relate to verifications

Checks are always attached to a verification. They do not replace onboarding verification, and they do not create a new identity flow for the contact. If the details have legitimately changed, create another verification and use the same attribution_id to keep the history connected.

​
Result handling

Treat the check result as a payment-control signal: For exact result fields and endpoint behavior, see Check a verification.

​
What to store

Store enough state to explain why a payment was allowed or held:
  • the verification ID checked against
  • your own payee or vendor ID
  • the check ID
  • the check result
  • the timestamp
  • the details version from your own system, if you have one
This keeps your audit trail tied to both systems: ezyshield’s verification record and your internal payment decision.