DEV Community: Ruhani Soft

How to Build an MVP in 2026: A Practical Guide to Scoping, Building, and Learning Fast

Ruhani Soft — Wed, 30 Sep 2026 17:06:38 +0000

Most startups do not fail because they could not build the product. They fail because they built the wrong product, or built too much of it before anyone used it. A minimum viable product (MVP) exists to prevent exactly that.

This guide walks through how to go from an idea to a focused first release: what to include, what to cut, how to build it, and how to learn from it.

What an MVP actually is

An MVP is a usable first version of a product, built around one specific assumption you need to test. Users should be able to complete the central task, and everything else waits.

Two things people get wrong:

"Minimum" does not mean "bad". The scope is small, but the experience of that small scope should still work well.
An MVP is not a demo. A demo shows an idea. An MVP is something real users try in a real context, so you can see what they actually do.

MVP vs prototype vs full product

	Prototype	MVP	Full product
Goal	Explore an idea or interface	Test a core assumption with real users	Serve a proven market at scale
Real users?	Usually feedback sessions	Yes, in a defined context	Yes
Working backend?	Often faked	Yes, for the core flow	Complete
Typical question	"Does this make sense?"	"Will people use and value this?"	"How do we grow and improve it?"

If you are not sure which you need, ask what you most need to learn. If it is "do people understand this?", a prototype may be enough. If it is "will people actually use this?", you need an MVP.

Step 1: Write down your riskiest assumption

Every product idea is a stack of assumptions. Pick the one that would kill the idea if it were false. Examples:

"Clinics will pay to replace paper appointment books."
"Freelancers will switch from spreadsheets to a dedicated invoicing tool."
"Shoppers will reorder from us if reordering takes one tap."

Write it as a single sentence. Your MVP exists to test that sentence, and any feature that does not help test it is a candidate for cutting.

Step 2: Define the user and the one journey

Be specific about who the first user is. "Small businesses" is too broad. "Owners of single-location restaurants who take phone orders" is a real person.

Then map the single journey that delivers value:

How does the user arrive?
What is the one task they came to do?
What is the moment they get value?
What would make them come back?

Everything on that path is in scope. Everything off it is not, at least for now.

Step 3: Prioritize ruthlessly

Take your full feature wishlist and sort it into three buckets:

Must have: the product cannot test the assumption without it
Should have: it improves the experience but the core still works without it
Later: good ideas that belong on the roadmap, not in release one

A quick test for each feature: "If we launched without this, could users still complete the core journey?" If yes, it is not a must have.

Common items that can usually wait:

Advanced admin dashboards and analytics
Multiple user roles and complex permissions
Native apps on every platform (start with one)
Automated emails beyond the essentials
Theme customization and settings pages
Integrations nobody has asked for yet

Step 4: Choose a stack you can move fast in

For an MVP, the best technology is usually the one your team already knows well and that has mature tooling for your problem. A few guidelines:

Prefer boring, proven technology. You want to spend time on the product, not on debugging a new framework.
Buy or reuse before you build. Authentication, payments, email, and file storage are solved problems. Use established libraries and services.
Pick a foundation that can grow. An MVP can become the long-term product if the foundation fits later needs. Think one step ahead, but do not build for ten steps ahead.
Start on one platform. A responsive web app or a single mobile platform is usually enough to learn from.

Step 5: Build in small, demonstrable increments

Long silent build phases are risky. Instead:

Work in short cycles (one or two weeks)
End each cycle with a working demo, not a status report
Review it with the people who know the users
Adjust scope based on what you see

This keeps the project honest. If something turns out harder than expected, you find out early, while there is still room to change the plan.

Good habits that cost little:

Keep a simple written scope document and update it when scope changes
Track decisions ("we cut X because Y") so they do not get relitigated
Deploy early to a real environment, not only to a developer laptop
Add basic error monitoring before launch, so you see failures users do not report

Step 6: Decide what you will measure before you launch

If you do not define success up front, every result looks like a win or a loss depending on your mood. Pick a small number of signals tied to your riskiest assumption:

Activation: what share of new users complete the core task?
Retention: do they come back after a week?
Qualitative feedback: what do they say when you ask, and where do they get stuck?
Willingness to pay: do they pay, or agree to, when asked?

Five conversations with real users will often teach you more than a dashboard with a hundred vanity numbers.

Step 7: Launch small, then learn

Do not wait for a big public launch. Give the MVP to a small group first: early adopters, a pilot customer, a waitlist. Then:

Watch how they actually use it
Talk to them, especially the ones who dropped off
Sort feedback into patterns, not one-off requests
Decide: persevere, pivot, or stop

Treat the result as data, not a verdict on you. A failed assumption found in six weeks is far cheaper than one found after eighteen months.

Common MVP mistakes

Building for everyone. A product for all users fits no one well.
Scope creep disguised as "just one more feature". Each small addition delays learning.
Skipping real users. Friends and family are polite. Target users are honest.
Overengineering. Microservices and multi-region infrastructure are rarely needed for a first release.
Ignoring the post-launch plan. The MVP is the start of the learning loop, not the end of the project.
No single owner for decisions. Someone has to be able to say "that goes in version two."

How long does an MVP take, and what does it cost?

Anyone who quotes a fixed number before understanding your product is guessing. Timing and cost depend on:

The number and complexity of core features
Third-party integrations (payments, maps, messaging, hardware)
Design needs
How quickly feedback and approvals come back
Whether you need web, mobile, or both

The honest way to get an estimate is to share your goals, your current setup, and the main problem you want to solve, then scope the work from there. Smaller, clearer scope almost always means faster, cheaper, and better learning.

Should you build in-house or hire a partner?

Both work. A rough way to decide:

In-house fits when you already have engineers with capacity and the domain expertise to scope well.
A development partner fits when you need to move without hiring a full team, want an outside view on scope, or need specific skills for a short period.

If you go with a partner, look for one who asks hard questions about scope before quoting, shows working demos regularly, and is comfortable saying "that is not needed yet." Teams that focus on MVP development for startups typically structure the work around exactly this flow: define the essentials, build in reviewed increments, then plan for feedback.

If you are an early-stage team still figuring out how to work with outside developers, resources written for startups and founders are a useful place to start.

And whichever route you choose, ask any partner to explain their process up front. A clear, documented approach to planning and delivery is one of the best signs that a project will stay on scope.

A simple MVP checklist

Before you start building:

[ ] One-sentence riskiest assumption
[ ] One clearly defined first user
[ ] One core journey mapped end to end
[ ] Must-have list that fits in one page
[ ] "Later" list captured so ideas are not lost
[ ] Success signals defined before launch
[ ] A small group of real users lined up to try it

Before you launch:

[ ] Core journey tested end to end on a real environment
[ ] Error monitoring in place
[ ] A way for users to give feedback easily
[ ] A plan for the first two weeks of post-launch review

Final thoughts

An MVP is not about shipping less. It is about learning sooner. Pick one assumption, build the smallest real product that tests it, put it in front of actual users, and let what they do decide what comes next.

What was the hardest feature you had to cut from your first release? Share it in the comments.

Laravel Payment Gateway Integration in 2026: A Production Guide to Webhooks, Idempotency, and Local Gateways

Ruhani Soft — Wed, 30 Sep 2026 17:04:31 +0000

Integrating a payment gateway in Laravel looks easy in the tutorial: redirect the user, get a callback, mark the order as paid. Then production happens. Customers close the tab before the redirect. Webhooks arrive twice, or out of order, or never. A refund comes in while the order is still "pending". Your finance team asks why the ledger and the gateway dashboard disagree.

This guide covers how to build payment integrations that survive all of that. It is based on patterns that hold up across very different gateways, from Stripe and PayPal to mobile financial services like bKash and Nagad.

What you will learn

A gateway-agnostic architecture for Laravel
A payment state machine that prevents illegal transitions
Secure webhook handling with signature verification
Idempotency, so double-delivery never double-charges or double-fulfills
Reconciliation jobs for the webhooks you miss
Testing payment flows without hitting real sandboxes
Notes on local gateways such as bKash, Nagad, and SSLCommerz

1. The mistakes that cost real money

Before the code, here are the failure modes behind most payment incidents:

Trusting the browser redirect. The success URL is not proof of payment. Anyone can visit it.
Fulfilling an order inside the callback request. If it times out halfway, you get a paid order that was never fulfilled.
Not handling duplicate webhooks. Gateways use at-least-once delivery. Duplicates are normal.
Storing money as floats. Use integers in minor units (cents, poisha).
No reconciliation. Webhooks fail. Without a safety net, you will have silent mismatches.
Gateway logic scattered across controllers. Adding the second gateway becomes a rewrite.

Everything below is designed to remove these.

2. Architecture: one interface, many gateways

If you ever expect to support more than one gateway, define a contract first.

<?php

namespace App\Payments\Contracts;

use App\Models\Payment;
use Illuminate\Http\Request;

interface PaymentGateway
{
    public function name(): string;

    /** Create a session/payment on the gateway and return where to send the customer. */
    public function initiate(Payment $payment): InitiatedPayment;

    /** Verify the authenticity of an incoming webhook/IPN. */
    public function verifyWebhook(Request $request): bool;

    /** Extract a unique, stable event id from the webhook (used for idempotency). */
    public function eventId(Request $request): string;

    /** Translate the gateway payload into our internal result. */
    public function parseWebhook(Request $request): WebhookResult;

    /** Ask the gateway for the truth. Used by reconciliation and after redirects. */
    public function fetchStatus(Payment $payment): GatewayStatus;

    public function refund(Payment $payment, int $amountMinor, ?string $reason = null): RefundResult;
}

Keep DTOs small and immutable:

<?php

namespace App\Payments\Contracts;

final class InitiatedPayment
{
    public function __construct(
        public readonly string $gatewayReference,
        public readonly ?string $redirectUrl = null,
        public readonly array $clientPayload = [],
    ) {}
}

final class WebhookResult
{
    public function __construct(
        public readonly string $gatewayReference,
        public readonly \App\Enums\PaymentStatus $status,
        public readonly ?int $amountMinor = null,
        public readonly ?string $currency = null,
        public readonly array $raw = [],
    ) {}
}

Then a manager that resolves drivers, using Laravel's Manager class or a simple map:

<?php

namespace App\Payments;

use App\Payments\Contracts\PaymentGateway;
use InvalidArgumentException;

class GatewayManager
{
    public function __construct(private array $drivers) {}

    public function driver(string $name): PaymentGateway
    {
        $class = $this->drivers[$name]
            ?? throw new InvalidArgumentException("Unknown gateway [$name]");

        return app($class);
    }
}

// config/payments.php
return [
    'drivers' => [
        'stripe'     => \App\Payments\Gateways\StripeGateway::class,
        'sslcommerz' => \App\Payments\Gateways\SslCommerzGateway::class,
        'bkash'      => \App\Payments\Gateways\BkashGateway::class,
    ],
];

// AppServiceProvider::register()
$this->app->singleton(GatewayManager::class, fn () => new GatewayManager(config('payments.drivers')));

Your controllers now only know about GatewayManager and PaymentGateway. Adding the next gateway means writing one class and one config line.

3. Data model

Two tables matter most: payments and webhook_events.

Schema::create('payments', function (Blueprint $table) {
    $table->id();
    $table->foreignId('order_id')->constrained()->cascadeOnDelete();
    $table->string('gateway');
    $table->string('gateway_reference')->nullable()->index();
    $table->unsignedBigInteger('amount_minor');   // 1050 = 10.50
    $table->unsignedBigInteger('refunded_minor')->default(0);
    $table->char('currency', 3);
    $table->string('status')->default('pending')->index();
    $table->json('meta')->nullable();
    $table->timestamp('paid_at')->nullable();
    $table->timestamps();

    $table->unique(['gateway', 'gateway_reference']);
});

Schema::create('webhook_events', function (Blueprint $table) {
    $table->id();
    $table->string('gateway');
    $table->string('event_id');
    $table->json('payload');
    $table->timestamp('processed_at')->nullable();
    $table->text('error')->nullable();
    $table->timestamps();

    $table->unique(['gateway', 'event_id']);   // the idempotency guard
});

The unique index on webhook_events is what makes duplicate delivery harmless. Do not rely on an if (exists) check alone, because two requests can race past it.

4. A payment state machine

Use a backed enum and explicitly define which transitions are legal.

<?php

namespace App\Enums;

enum PaymentStatus: string
{
    case Pending = 'pending';
    case Processing = 'processing';
    case Paid = 'paid';
    case Failed = 'failed';
    case Refunded = 'refunded';
    case PartiallyRefunded = 'partially_refunded';

    /** @return array<self> */
    public function allowedNext(): array
    {
        return match ($this) {
            self::Pending => [self::Processing, self::Paid, self::Failed],
            self::Processing => [self::Paid, self::Failed],
            self::Paid => [self::PartiallyRefunded, self::Refunded],
            self::PartiallyRefunded => [self::PartiallyRefunded, self::Refunded],
            self::Failed, self::Refunded => [],
        };
    }

    public function canTransitionTo(self $next): bool
    {
        return in_array($next, $this->allowedNext(), true);
    }
}

On the model, centralize transitions so nothing mutates status directly:

public function transitionTo(PaymentStatus $next): bool
{
    if ($this->status === $next) {
        return false; // already there, treat as a no-op
    }

    if (! $this->status->canTransitionTo($next)) {
        Log::warning('Illegal payment transition', [
            'payment' => $this->id, 'from' => $this->status, 'to' => $next,
        ]);
        return false;
    }

    $this->status = $next;
    if ($next === PaymentStatus::Paid) {
        $this->paid_at = now();
    }
    $this->save();

    return true;
}

This matters because webhooks arrive out of order. A late pending event must never overwrite paid.

5. Starting a payment

Create the local record first, then talk to the gateway. If the gateway call fails, you still have a record to inspect.

<?php

namespace App\Actions;

use App\Models\Order;
use App\Models\Payment;
use App\Payments\GatewayManager;

class StartPayment
{
    public function __construct(private GatewayManager $gateways) {}

    public function __invoke(Order $order, string $gateway): array
    {
        $payment = Payment::create([
            'order_id'     => $order->id,
            'gateway'      => $gateway,
            'amount_minor' => $order->total_minor,
            'currency'     => $order->currency,
        ]);

        $initiated = $this->gateways->driver($gateway)->initiate($payment);

        $payment->update(['gateway_reference' => $initiated->gatewayReference]);

        return [
            'payment_id' => $payment->id,
            'redirect'   => $initiated->redirectUrl,
            'payload'    => $initiated->clientPayload,
        ];
    }
}

Always pass your own payment->id (or a UUID) to the gateway as a merchant reference where supported. It makes debugging and reconciliation far easier.

6. Webhooks done right

The webhook endpoint should do four things and nothing else: verify, deduplicate, persist, dispatch. Heavy work goes to a queue.

Route

Route::post('/webhooks/payments/{gateway}', PaymentWebhookController::class)
    ->withoutMiddleware([\App\Http\Middleware\VerifyCsrfToken::class])
    ->name('webhooks.payments');

(In Laravel 11 and newer, exclude the path through validateCsrfTokens(except: [...]) in bootstrap/app.php.)

Controller

<?php

namespace App\Http\Controllers;

use App\Jobs\ProcessPaymentWebhook;
use App\Payments\GatewayManager;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\DB;

class PaymentWebhookController
{
    public function __construct(private GatewayManager $gateways) {}

    public function __invoke(Request $request, string $gateway)
    {
        $driver = $this->gateways->driver($gateway);

        if (! $driver->verifyWebhook($request)) {
            return response('Invalid signature', 400);
        }

        $inserted = DB::table('webhook_events')->insertOrIgnore([
            'gateway'    => $gateway,
            'event_id'   => $driver->eventId($request),
            'payload'    => $request->getContent(),
            'created_at' => now(),
            'updated_at' => now(),
        ]);

        // Duplicate delivery: acknowledge and stop.
        if ($inserted === 0) {
            return response()->noContent();
        }

        $eventDbId = DB::table('webhook_events')
            ->where('gateway', $gateway)
            ->where('event_id', $driver->eventId($request))
            ->value('id');

        ProcessPaymentWebhook::dispatch($eventDbId);

        return response()->noContent();
    }
}

Return a 2xx quickly. Most gateways retry on anything else, which creates the duplicates you just protected against.

Signature verification

Every serious gateway signs its webhooks, usually with HMAC. The pattern, using a Stripe-style scheme as an example:

public function verifyWebhook(Request $request): bool
{
    $header = $request->header('Stripe-Signature', '');
    parse_str(str_replace(',', '&', $header), $parts);

    $timestamp = $parts['t'] ?? null;
    $signature = $parts['v1'] ?? null;

    if (! $timestamp || ! $signature) {
        return false;
    }

    // Reject old requests to limit replay attacks.
    if (abs(time() - (int) $timestamp) > 300) {
        return false;
    }

    $expected = hash_hmac(
        'sha256',
        $timestamp.'.'.$request->getContent(), // RAW body, not re-encoded JSON
        config('services.stripe.webhook_secret')
    );

    return hash_equals($expected, $signature);
}

Three details people get wrong:

Use the raw body ($request->getContent()), never json_encode($request->all()).
Compare with hash_equals() to avoid timing attacks.
Check a timestamp tolerance where the scheme supports it.

For gateways that do not sign webhooks at all (some regional ones only send an IPN with a transaction ID), treat the webhook as a hint, then call the gateway's verification API server-to-server before changing any state. More on that in section 9.

The processing job

<?php

namespace App\Jobs;

use App\Enums\PaymentStatus;
use App\Models\Payment;
use App\Payments\GatewayManager;
use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Bus\Dispatchable;
use Illuminate\Queue\InteractsWithQueue;
use Illuminate\Support\Facades\DB;

class ProcessPaymentWebhook implements ShouldQueue
{
    use Dispatchable, InteractsWithQueue, Queueable;

    public int $tries = 5;
    public array $backoff = [10, 60, 300, 900];

    public function __construct(public int $eventId) {}

    public function handle(GatewayManager $gateways): void
    {
        $event = DB::table('webhook_events')->find($this->eventId);

        if (! $event || $event->processed_at) {
            return;
        }

        $request = \Illuminate\Http\Request::create('/', 'POST', [], [], [], [], $event->payload);
        $result = $gateways->driver($event->gateway)->parseWebhook($request);

        DB::transaction(function () use ($event, $result) {
            $payment = Payment::where('gateway', $event->gateway)
                ->where('gateway_reference', $result->gatewayReference)
                ->lockForUpdate()
                ->first();

            if (! $payment) {
                // Webhook beat our own DB write. Let the queue retry later.
                $this->release(30);
                return;
            }

            if ($result->amountMinor !== null && $result->amountMinor !== $payment->amount_minor) {
                report(new \RuntimeException("Amount mismatch on payment {$payment->id}"));
                return;
            }

            if ($payment->transitionTo($result->status) && $result->status === PaymentStatus::Paid) {
                \App\Events\PaymentSucceeded::dispatch($payment);
            }

            DB::table('webhook_events')
                ->where('id', $event->id)
                ->update(['processed_at' => now()]);
        });
    }
}

Key points:

lockForUpdate() inside a transaction stops two workers from processing the same payment at once.
The amount check defends against tampering and mismatched currency handling.
Fulfillment hangs off a PaymentSucceeded event, so the webhook job stays focused on payment state.

7. Idempotency beyond webhooks

Webhooks are one place duplicates appear. Others:

User double-clicks "Pay". Disable the button client-side, and server-side reuse an existing pending payment for the same order instead of creating a new one.
API retries to the gateway. Stripe and several others support an Idempotency-Key header. Use your payment ID as the key.
Fulfillment. Make PaymentSucceeded listeners idempotent. For example, issue a license key only if the order does not already have one.

Http::withHeaders(['Idempotency-Key' => "payment-{$payment->id}"])
    ->post($endpoint, $body);

A good rule: any operation that has a side effect in the outside world (email, license, shipment) should be safe to run twice.

8. Reconciliation: your safety net

Even with perfect code, webhooks get lost: your server was down, a firewall blocked the gateway, the queue backed up. Run a scheduled job that asks the gateway for the truth about stale payments.

// routes/console.php (Laravel 11+) or Console\Kernel::schedule()
Schedule::command('payments:reconcile')->everyFiveMinutes();

<?php

namespace App\Console\Commands;

use App\Models\Payment;
use App\Payments\GatewayManager;
use Illuminate\Console\Command;

class ReconcilePayments extends Command
{
    protected $signature = 'payments:reconcile';
    protected $description = 'Sync stale pending payments with their gateway';

    public function handle(GatewayManager $gateways): int
    {
        Payment::query()
            ->whereIn('status', ['pending', 'processing'])
            ->where('created_at', '<', now()->subMinutes(10))
            ->where('created_at', '>', now()->subDays(2))
            ->whereNotNull('gateway_reference')
            ->chunkById(100, function ($payments) use ($gateways) {
                foreach ($payments as $payment) {
                    try {
                        $status = $gateways->driver($payment->gateway)->fetchStatus($payment);
                        $payment->transitionTo($status->status);
                    } catch (\Throwable $e) {
                        report($e);
                    }
                }
            });

        return self::SUCCESS;
    }
}

Also build an admin view that lists payments stuck in pending for more than an hour. Support teams will thank you.

9. Working with local and regional gateways

Stripe-quality documentation is the exception, not the rule. Many regional gateways have inconsistent sandboxes, unusual auth flows, or webhooks that are only partially signed. The architecture above still works, but expect these differences.

Token-based, multi-step flows. Mobile wallets like bKash typically follow a sequence: obtain an auth token, create a payment, redirect the customer to approve it, then execute the payment after the callback. The execute step is what actually captures the money, so your callback handler must call it and then verify the final status. Tokens expire, so cache them with a TTL slightly below their lifetime and refresh on failure.

Encrypted payload signing. Some gateways, Nagad being a well-known example, require you to encrypt and sign request payloads with RSA keys. Keep keys in secure storage, never in the repo, and write the crypto in one small, well-tested class so the rest of the driver stays readable.

Redirect plus server validation. Gateways like SSLCommerz redirect the customer back with a transaction identifier, and also send an IPN. The safe approach is to ignore what the redirect claims and call the gateway's validation endpoint with the transaction ID, then compare the amount and currency in the validation response against your own record.

public function fetchStatus(Payment $payment): GatewayStatus
{
    $response = Http::retry(3, 200)
        ->timeout(15)
        ->get(config('services.sslcommerz.validation_url'), [
            'val_id'     => $payment->meta['val_id'] ?? null,
            'store_id'   => config('services.sslcommerz.store_id'),
            'store_passwd' => config('services.sslcommerz.store_password'),
            'format'     => 'json',
        ])->throw()->json();

    $valid = in_array($response['status'] ?? '', ['VALID', 'VALIDATED'], true);
    $amountOk = (int) round(((float) ($response['amount'] ?? 0)) * 100) === $payment->amount_minor;

    return new GatewayStatus(
        $valid && $amountOk ? PaymentStatus::Paid : PaymentStatus::Failed
    );
}

General rules for any gateway with weak webhooks:

Treat inbound notifications as triggers, not as truth.
Always verify server-to-server before marking a payment paid.
Validate amount, currency, and your own merchant reference.
Log the full request and response for every gateway call (with secrets masked). You will need this during disputes.
Put timeouts and retries on every outbound HTTP call: Http::timeout(15)->retry(3, 200).

If you are building for emerging markets and do not want to write each integration from scratch, it can be worth reusing battle-tested code. Studios such as Ruhanisoft, which maintain a library covering dozens of regional and international gateways, exist precisely because the per-gateway quirks are where most of the project time goes.

10. Testing without hitting real sandboxes

Sandboxes are slow, flaky, and sometimes down. Fake the HTTP layer and test your own logic.

use Illuminate\Support\Facades\Http;
use Illuminate\Support\Facades\Queue;

it('marks a payment as paid once, even if the webhook is delivered twice', function () {
    Queue::fake();

    $payment = Payment::factory()->create([
        'gateway' => 'stripe',
        'gateway_reference' => 'pi_123',
        'amount_minor' => 5000,
        'status' => 'pending',
    ]);

    $payload = json_encode(['id' => 'evt_1', 'reference' => 'pi_123', 'status' => 'succeeded']);
    $headers = signedStripeHeaders($payload); // helper that builds a valid Stripe-Signature

    $this->call('POST', '/webhooks/payments/stripe', [], [], [], $headers, $payload)->assertNoContent();
    $this->call('POST', '/webhooks/payments/stripe', [], [], [], $headers, $payload)->assertNoContent();

    Queue::assertPushed(ProcessPaymentWebhook::class, 1);
});

it('rejects a webhook with a bad signature', function () {
    $this->postJson('/webhooks/payments/stripe', ['id' => 'evt_2'], ['Stripe-Signature' => 't=1,v1=bad'])
        ->assertStatus(400);
});

it('never moves a paid payment back to pending', function () {
    $payment = Payment::factory()->create(['status' => 'paid']);

    expect($payment->transitionTo(PaymentStatus::Pending))->toBeFalse()
        ->and($payment->fresh()->status)->toBe(PaymentStatus::Paid);
});

Also fake outbound gateway calls:

Http::fake([
    'api.gateway.test/*' => Http::response(['status' => 'VALID', 'amount' => '50.00'], 200),
]);

The tests worth writing first:

Duplicate webhook delivery
Invalid signature
Out-of-order events
Amount mismatch
Gateway timeout during initiate
Reconciliation picks up a missed webhook

11. Security checklist

Webhook secrets and API keys live in .env or a secrets manager, never in Git
Webhook route excluded from CSRF, but protected by signature verification
Raw-body HMAC with hash_equals
Amounts stored as integers, verified against your own record
Card data never touches your server if you can use hosted fields or redirects (stay out of PCI scope)
Webhook endpoint rate limited and allowlisted by IP where the gateway publishes ranges
Sensitive fields masked in logs
Refund and admin actions behind policies and audit logging

12. Going live checklist

Sandbox and live credentials separated per environment
Webhook URL registered in the live dashboard, not just sandbox
Queue workers supervised (Horizon or Supervisor) and restarting on deploy
Reconciliation scheduled and the scheduler actually running
Alerts on: webhook failures, payments stuck in pending, amount mismatches
A runbook for "customer paid but order not fulfilled"
One real low-value transaction tested end to end, including a refund

Wrapping up

Reliable payments in Laravel come down to a few habits: never trust the redirect, verify every webhook, make every step idempotent, model payment status as a state machine, and reconcile against the gateway on a schedule. Get those right once behind a clean gateway interface and each new provider becomes a small, predictable piece of work instead of a risky rewrite.

If you would rather hand off the integration work, agencies and founders often bring in a specialist Laravel payment gateway integration team for the tricky regional gateways, then keep the rest of the product in-house. Whichever route you pick, use the checklists above to hold the result to a high standard.

And if you are starting a new Laravel product from scratch, a solid base saves weeks. Browse some ready-made Laravel scripts and starter kits to see what a production-oriented foundation looks like.

What is the strangest gateway behavior you have run into? Share it in the comments.

How to Choose the Right Offshore Laravel Development Company in 2026

Ruhani Soft — Wed, 30 Sep 2026 17:01:43 +0000

Laravel is still one of the most productive PHP frameworks for building SaaS products, marketplaces, and internal tools. That is why so many agencies and startups outsource Laravel work to offshore teams. The catch is that the gap between a great offshore partner and a bad one is enormous, and you usually find out only after the budget is burned.

Here is a practical checklist for picking the right one.

1. Look at the code, not the pitch deck

Ask for a real code sample or a short paid trial task. Then check:

Structure: Are controllers thin? Is business logic in services, actions, or jobs?
Eloquent usage: Do they avoid N+1 queries (with(), eager loading)?
Validation: Form Requests instead of validation scattered across controllers?
Security basics: Mass assignment protection, policies/gates, CSRF, and no raw queries with user input.

// Red flag: N+1 query
foreach (Order::all() as $order) {
    echo $order->customer->name;
}

// Better
foreach (Order::with('customer')->get() as $order) {
    echo $order->customer->name;
}

If a team cannot explain why the second version matters, keep looking.

2. Check that they know the Laravel ecosystem

A serious Laravel team should be comfortable with:

Queues, Horizon, and scheduled jobs
Sanctum/Passport for API auth
Livewire, Inertia, or a Vue/React frontend
Pest or PHPUnit testing
Redis caching and database indexing
Deployment with Forge, Envoyer, Docker, or plain CI/CD

Ask which of these they used in their last three projects. Specific answers beat generic ones.

3. Payment integrations are a great stress test

Payment gateways expose weak engineering quickly. Webhooks, idempotency, refunds, and failed-payment states are where sloppy code breaks. If your product sells in emerging markets, local gateway experience matters even more.

For example, Ruhanisoft, a Laravel/PHP studio, maintains a large library of gateway integrations, including Bangladesh mobile financial services like bKash and Nagad as well as SSLCommerz. Teams that have shipped this kind of integration repeatedly tend to handle webhook verification and reconciliation correctly from the start.

Questions worth asking any vendor:

How do you verify webhook signatures?
How do you prevent double-processing the same payment?
How do you test against sandbox environments?

4. Communication beats hourly rate

Cheap rates get expensive when requirements get lost in translation. Evaluate:

Time zone overlap: At least 3 to 4 shared working hours is ideal.
Written English: Read their emails and docs, not just their sales calls.
Process: Do they use Jira, Linear, or GitHub Projects? Do they do weekly demos?
Proactivity: Do they challenge unclear requirements or just say yes to everything?

A team that asks good questions in week one saves you weeks later.

5. Clarify ownership and IP up front

Put these in the contract:

Full source code ownership transfers to you
Access to the Git repo from day one, under your organization
Documentation and a handover process
NDA and confidentiality terms

Never accept a setup where the vendor holds the only copy of the repo or the production credentials.

6. Start small with a pilot

Instead of committing to a 6-month build, run a 2 to 4 week pilot: one feature, one module, or one bug-fix sprint. Judge them on:

Code quality
Delivery against the estimate
Communication
How they handle feedback

7. Understand the pricing model

Model	Best for	Risk
Fixed price	Well-defined MVPs	Scope disputes
Hourly / T&M	Evolving products	Budget creep
Dedicated developer	Long-term overflow work	Needs your management

Agencies often prefer a white-label or dedicated-developer arrangement, where the offshore team works behind your brand. If you go this route, make sure the vendor is comfortable with NDAs and with working inside your tools and repos.

8. Red flags to walk away from

No willingness to share code samples or references
Guaranteed unrealistic timelines
No mention of testing or code review
Vague answers about who will actually work on your project
Pressure to pay everything upfront

Final thoughts

The best offshore Laravel partner is not the cheapest or the biggest. It is the one that writes maintainable code, communicates clearly, and treats your product like their own. Use a pilot, verify their technical depth, and lock down ownership before you scale.

If you are comparing options, studios like Ruhanisoft's Laravel development team are a good example of the kind of focused, PHP/Laravel-first shop worth shortlisting. Just run the same checklist on everyone, including them.

What has your experience been with offshore Laravel teams? Share your lessons in the comments.

Why We Chose Laravel to Build Products That Last

Ruhani Soft — Sun, 12 Jul 2026 05:34:25 +0000

Software is easier to build than ever.

With AI generating code in seconds and countless frameworks available, shipping an application has become faster than anyone imagined. But building software that remains maintainable, secure, and scalable after months or years is still a different challenge.

At Ruhani Soft, we focus on Laravel because it helps us solve that challenge consistently.

Laravel is more than a PHP framework

Laravel isn't just about elegant syntax.

It's an ecosystem that allows teams to build production-ready applications with features like:

Authentication and authorization
Queues and background jobs
Caching
Scheduled tasks
API development
Testing
Database migrations
Strong security practices

Instead of reinventing these building blocks for every project, we can spend more time solving real business problems.

Our philosophy

We believe software should be:

Easy to maintain
Fast to iterate
Secure by default
Well documented
Built with long-term growth in mind

Whether it's a SaaS platform, internal business software, fintech solution, or custom web application, these principles remain the same.

AI changes development, but not engineering

AI has dramatically increased developer productivity.

It can generate code, explain unfamiliar APIs, create tests, and speed up repetitive tasks.

But successful products still require thoughtful architecture, clean code, good UX, security, and careful technical decisions.

We see AI as a powerful development partner—not a replacement for engineering.

What we're building

At Ruhani Soft, we're sharing our journey as we build:

Laravel applications
SaaS products
Business automation tools
Developer resources
Open-source contributions

We'll also publish lessons learned from real projects, performance optimization tips, deployment strategies, and practical Laravel techniques.

If you're building with Laravel or planning your next product, we'd love to connect and exchange ideas.

How Offshore PHP Development Helps Startups Build MVPs Faster

Ruhani Soft — Sun, 12 Jul 2026 05:33:48 +0000

Startups usually do not have unlimited time, budget, or development capacity.

A product idea needs to be tested quickly. The first version does not need every feature, but it does need to be stable, usable, and clear enough for real users.

This is where offshore PHP and Laravel development can be useful for startups building MVPs.

Why MVP speed matters

An MVP helps a startup test an idea before spending too much time and money on a full product.

The goal is simple:

Build the core features
Launch quickly
Get user feedback
Improve based on real usage
Avoid building unnecessary features too early

When development is slow, the startup loses time. When development is rushed without structure, the product becomes difficult to maintain.

A good MVP needs both speed and clean execution.

Why Laravel works well for startup MVPs

Laravel is a practical framework for building MVPs because it gives developers a strong foundation out of the box.

It supports many common product requirements, including:

User authentication
Admin dashboards
Database management
API development
Payment integration
Email notifications
File uploads
Role based access
Background jobs
Security features

This helps developers build faster without creating everything from scratch.

Where offshore development helps

Hiring a full in-house team can be expensive for an early stage startup. It can also take time to find, interview, onboard, and manage developers.

Offshore development gives startups access to technical support without building a full internal team immediately.

It can help with:

MVP planning
Feature development
Laravel backend development
Admin panel creation
API integration
Payment gateway setup
Bug fixing
Product improvements after launch
Long term maintenance

For startups, this means the idea can move from concept to product faster.

What startups should avoid

Offshore development works best when the project has clear direction.

Startups should avoid:

Adding too many features to the first version
Building without a clear user problem
Ignoring security and code quality
Choosing only based on the lowest price
Skipping documentation
Delaying feedback until the product is complete

A small, focused MVP is usually better than a large unfinished product.

How RuhaniSoft supports startup MVPs

RuhaniSoft helps startups and growing businesses build PHP and Laravel web applications, SaaS platforms, admin panels, and custom business software.

For MVP projects, RuhaniSoft focuses on clean development, practical feature planning, scalable structure, and reliable delivery.

The goal is to help startups launch a working product faster while keeping the codebase ready for future improvements.

A better way to build the first version

The first version of a product should be simple, focused, and useful.

Laravel gives startups a reliable technical base, while offshore development support helps reduce delivery pressure.

For startups that need to launch a PHP or Laravel based MVP, working with an offshore development partner can be a practical way to move faster without losing control of quality.

Learn more about RuhaniSoft here: https://ruhanisoft.com/

Why Growing Businesses Choose Laravel for Custom Web Applications

Ruhani Soft — Thu, 09 Jul 2026 03:57:12 +0000

When a business starts growing, basic websites and simple tools are often not enough anymore.

Teams need custom dashboards, customer portals, reporting systems, SaaS platforms, payment workflows, and internal tools that match the way their business actually works.

This is one reason Laravel is still a strong choice for custom web application development.

Laravel is built for practical business software

Laravel gives developers a clean structure for building secure and maintainable applications.

For business projects, this matters because the software usually needs to grow over time. A small project today can become a larger platform later with more users, more features, more integrations, and more data.

Laravel works well for:

Admin panels
SaaS applications
CRM systems
Booking platforms
Finance dashboards
Customer portals
Inventory systems
Reporting tools
API based applications
Internal business tools

Why businesses prefer custom web apps

Off the shelf software can be useful, but it does not always fit every workflow.

A custom web application allows a business to build around its own process instead of forcing the team to adjust to a generic tool.

Custom software can help businesses:

Save time on repeated tasks
Improve team coordination
Reduce manual data entry
Track business activity in one place
Connect different tools through APIs
Create better customer experiences
Build features that competitors do not have

Why PHP and Laravel are still relevant

PHP remains widely used for web development, and Laravel has made PHP development much cleaner and more productive.

Laravel includes useful features for routing, authentication, database handling, queues, notifications, API development, validation, caching, and security.

This makes it easier to build reliable applications without starting every feature from zero.

When a business should consider Laravel development

A business should consider Laravel when it needs a web application that is more than a simple website.

Some common signs include:

The team is using spreadsheets for complex operations
Customers need a portal or dashboard
The business needs custom reporting
Existing tools do not fit the workflow
Manual work is slowing the team down
Multiple systems need to be connected
A SaaS product or MVP needs to be launched
The company wants full control over features and data

How RuhaniSoft supports Laravel projects

RuhaniSoft provides PHP and Laravel development services for businesses, startups, and agencies that need custom web software.

The team works on scalable web applications, SaaS platforms, admin panels, API integrations, and long term software maintenance.

For growing businesses, RuhaniSoft can help turn manual workflows into structured web applications that are easier to manage and improve over time.

Building software that can grow

The best custom applications are not only built for today. They are built with future changes in mind.

A Laravel application can start as a small MVP, then grow into a full business platform with more modules, users, permissions, integrations, and automation.

That makes Laravel a practical choice for businesses that want reliable software without overcomplicating the first version.

Learn more about Laravel and PHP development services here: https://ruhanisoft.com/

How Agencies Can Deliver Laravel Projects Faster With Offshore PHP Development

Ruhani Soft — Thu, 09 Jul 2026 03:55:37 +0000

Agencies often handle multiple client projects at the same time. Some projects need new features, some need bug fixes, and some need full Laravel application development from planning to launch.

When the internal team is already busy, delivery can slow down. This is where offshore PHP and Laravel development support can help.

Why Laravel agencies need flexible development support

Laravel is a strong framework for building business software, SaaS platforms, dashboards, admin panels, API systems, and custom web applications.

But agency work is not always predictable.

One month may have light work. The next month may bring multiple client deadlines at once. Hiring full time developers for every demand is not always practical.

Offshore Laravel development helps agencies add skilled development capacity without increasing permanent team costs.

Common situations where offshore support helps

Agencies usually need extra support when they have:

Too many active Laravel projects
Urgent bug fixes or feature updates
Client requests that need fast turnaround
White label development requirements
SaaS or dashboard projects that need backend expertise
API integrations and payment gateway work
Long term maintenance tasks

A reliable offshore development partner can help keep projects moving while the agency focuses on client communication, sales, and strategy.

What good offshore Laravel support should include

Not every offshore team is useful for agency work. The right partner should understand clean code, deadlines, communication, and client expectations.

Important things to look for:

Strong PHP and Laravel experience
Clean and maintainable code
Secure development practices
Clear communication
Flexible project capacity
Ability to work with existing codebases
Support for APIs, dashboards, SaaS features, and admin panels
Long term maintenance availability

How RuhaniSoft helps agencies

RuhaniSoft helps agencies and growing businesses build scalable PHP and Laravel web applications.

The team focuses on offshore development support for:

Laravel application development
PHP web application development
SaaS platforms
Admin panels
Custom business software
API development
Bug fixing and maintenance
White label agency support

For agencies, this means extra technical capacity without the need to hire a full internal team for every project.

Why this model works for agencies

Offshore development works best when the agency already has client demand but needs more delivery power.

Instead of rejecting projects or delaying deadlines, agencies can use a trusted development partner to handle technical execution.

This helps agencies:

Deliver projects faster
Reduce workload pressure
Accept more client work
Keep costs more controlled
Maintain long term client relationships
Scale development capacity when needed

Final thoughts

Laravel agencies need more than just developers. They need reliable technical partners who can understand deadlines, write clean code, and support long term project growth.

If your agency needs PHP or Laravel development support, RuhaniSoft can help with offshore development services for scalable web applications.

Learn more here: https://ruhanisoft.com/

How We Build Production Ready Laravel Applications That Scale

Ruhani Soft — Tue, 07 Jul 2026 19:24:40 +0000

When building a Laravel application, writing code is only the beginning.

A production ready application needs to be secure, maintainable, performant, and easy to extend as the business grows. These are the principles we follow when building software at Ruhanisoft.

1. Start With a Clean Architecture

A well-structured codebase is easier to maintain than one filled with shortcuts.

We organize business logic into dedicated services, keep controllers lightweight, and build reusable components wherever possible.

A clean architecture makes new features faster to develop and reduces technical debt.

2. Optimize Performance From Day One

Performance should not be an afterthought.

We focus on:

Efficient database queries
Proper indexing
Queue jobs for heavy tasks
Caching where it provides real value
Asset optimization
Responsive user interfaces

Fast applications create a better user experience and reduce infrastructure costs.

3. Build With Security in Mind

Every application should include strong security practices from the start.

This includes authentication, authorization, input validation, CSRF protection, secure file uploads, and regular dependency updates.

Security is a feature, not an optional add-on.

4. Make Software Easy to Customize

Businesses rarely use software exactly as it ships.

Flexible settings, modular components, reusable UI elements, and clear documentation make customization significantly easier.

5. Think Beyond Version 1

The first release is only the beginning.

A scalable application should support future integrations, new modules, payment gateways, localization, and business growth without requiring a complete rewrite.

Our Approach

At Ruhanisoft, we build Laravel applications with long-term maintainability in mind.

Our goal is simple:

Build software that developers enjoy working on and businesses can confidently grow with.

If you are interested in our products or want to learn more about our development approach, visit https://ruhanisoft.com.

What practices do you consider essential for a production ready Laravel application?