How to validate Money in Laravel5 request class
Stefan Bogdanescu
Founder & Senior Architect · 2026-06-29
# How to Validate Money in a Laravel Request Class: Handling Currency with Precision
As a senior developer working with Laravel, you often deal with forms where monetary values are submitted. While basic validation checks like `'required'` and `'string'` are essential, validating currency—which requires mathematical precision and specific formatting—demands a more robust approach. Simply checking if a field is not empty is insufficient when dealing with financial data.
This guide will walk you through the best practices for validating monetary amounts within a Laravel Form Request class, ensuring that only valid numeric values representing currency are accepted by your application.
## The Pitfall of Simple Validation for Money
When you use simple validation rules like `required` or `numeric`, you ensure the input is a number. However, this doesn't prevent issues like:
1. **Non-standard formats:** Accepting inputs that look like text but are numeric (e.g., "one hundred dollars").
2. **Precision Errors:** Handling decimal places correctly, which is critical for currency calculations.
3. **Negative Values:** Ensuring the amount is positive, as a payment should generally be a positive value.
For financial data, we need validation that enforces both the *type* and the *sensibility* of the number.
## Implementing Robust Monetary Validation
The most effective way to handle this in Laravel is by leveraging custom validation rules or careful application of built-in rules combined with explicit checks within your request class. Since Laravel 5 (and modern versions), Form Requests are the perfect place to enforce these business logic rules before they hit your controllers.
### Step 1: Using Built-in Rules for Numeric Input
For a starting point, you should always use the `numeric` rule. This ensures that the input consists only of digits, decimal points, and an optional negative sign.
In your `PaymentRequest`, you would update your `rules()` method to enforce this:
```php
public function rules()
{
return [
'invoiceid' => 'required|string',
'recieved_amount' => 'required|numeric', // Ensures it is a valid number
'ref_no' => 'required|string',
'date' => 'required|date',
'comment' => 'required|string',
];
}
```
While `numeric` handles the type check, it doesn't handle the business logic (like ensuring the amount is positive).
### Step 2: Enforcing Business Logic with Custom Rules (Best Practice)
For true monetary validation, you need to add constraints that reflect financial reality. Since Laravel doesn't ship with a built-in `money` rule, we implement this logic directly in the request class or by creating a custom rule. For simplicity and control, adding explicit checks in the `rules()` method is often practical:
```php
public function rules()
{
return [
'invoiceid' => 'required|string',
'recieved_amount' => [
'required',
'numeric',
'min:0.01' // Ensures the amount is greater than zero (or at least a minimum increment)
],
'ref_no' => 'required|string',
'date' => 'required|date',
'comment' => 'required|string',
];
}
```
The addition of `min:0.01` is crucial here. It prevents zero or negative amounts from being processed, ensuring that the transaction amount is a valid positive figure. This level of detail in validation aligns perfectly with the principles of clean, maintainable code championed by frameworks like Laravel. For deeper dives into structuring your application logic, understanding how Eloquent models interact with these validated inputs is key, as discussed on sites like https://laravelcompany.com.
## Conclusion
Validating money effectively in a Laravel request class involves moving beyond simple string checks. By combining the built-in `numeric` rule with custom constraints like `min` and potentially using custom validation rules, you establish a strong gatekeeping mechanism for your financial data. Always treat monetary values as precise numbers that must adhere to specific business logic. This approach ensures data integrity, prevents erroneous calculations, and results in a more reliable application.