Validations

Lead does not queue instant payments. Instead, synchronous validation failures result in no creation of an instant_payment object and an HTTP error response, and asynchronous validation failures result in a .rejected webhook and a populated rejection hash with additional details. The table below contains a list of validations that Lead performs. We run validations synchronously and asynchronously.

Lead Validation	Best Practice	Direction
`parameters_invalid`	Ensure all request parameters are provided and adhere to Lead’s rules.	Outgoing
`non_sufficient_funds`	Check if there are sufficient funds before requesting an outgoing payment.	Outgoing
`account_number_incorrect`	Check if the sender’s account is active before attempting to send an outgoing payment.	Outgoing
`limit_exceeded`	Request outgoing daily and 30-day payment limits that are consistent with the payment demand you expect. As your business grows, request that Lead increases your limits.	Outgoing
`routing_number_format_incorrect`	Check if the creditor’s routing number is accurate before submitting an instant payment.	Outgoing
`restricted_by_account_number_controls`	Use account number controls to constraint payment activity within known bounds. Ensure valid payments are not blocked by these restrictions.	Outgoing and incoming
`participant_not_on_network`	Call the `/check_availability` endpoint to verify that a creditor is enabled for instant payments before creating an outgoing instant payment.	Outgoing
`participant_signed_off`	This may occur if a counterparty is offline during maintenance or downtime. There is nothing you can do to avoid this error.	Outgoing
`creditor_name_mismatch`	Ensure your customers and the parties they transact with are aware that creditor names must be accurate.	Incoming

Banking Infrastructure

Lending & Receivables

Payment Rails

Customers & Accounts

Network Settlement