ConnectIPS Integration for Bank Payments

By Kokil Thapa | Last reviewed: August 2026

Implementing ConnectIPS integration for bank payments is the most reliable way to accept direct bank transfers from customers across Nepal’s 50+ member banks. Unlike wallet-based gateways that require pre-loaded balances, ConnectIPS pulls funds directly from user bank accounts via mobile banking apps or internet banking, making it essential for high-value transactions like legal service retainers or B2B eCommerce. For developers building on Laravel 12.x with PHP 8.4, this integration demands precise cryptographic signing and state management rather than simple plugin installation. If you are also evaluating other local options, my comparison of Khalti and eSewa Nepal payment integration covers when wallets outperform direct bank rails.

How does the ConnectIPS integration for bank payments flow work?

Understanding the sequence is critical because ConnectIPS is an asynchronous system. You cannot treat it like a credit card charge where the response is immediate. The flow involves three distinct phases: initiation, user authentication at the bank level, and server-to-server confirmation. In my experience deploying this for legal-tech portals where clients pay consultation fees ranging from Rs 5,000 to Rs 50,000 (~USD 37–370), the majority of support tickets arise from misunderstanding the gap between the user seeing "Success" on their phone and your server receiving the confirmed webhook.

The diagram above illustrates why you must never trust the frontend redirect URL alone. Users can close the browser after paying but before returning to your success page, or they might manipulate the return URL parameters. Only the signed webhook received at your backend endpoint confirms that funds have actually moved. On a recent project involving document attestation services, we found that approximately 8% of successful payments never triggered the frontend return flow due to mobile network timeouts, yet all were captured correctly via the webhook listener.

How do you generate valid HMAC signatures for ConnectIPS?

Cryptographic signing is where most ConnectIPS integration for bank payments attempts fail. The API rejects requests with even minor formatting discrepancies in the signature string. ConnectIPS uses HMAC-SHA256, and the message format is strictly defined: typically a concatenation of specific fields in alphabetical order or a prescribed sequence depending on the API version. Always consult the current 2026 merchant documentation, as field ordering has changed between versions.

Common signing mistakes to avoid

• Including null values: If a field is optional and empty, verify whether the spec requires omitting it entirely or including an empty string. Including "" when you should omit breaks the hash.
• Case sensitivity: Field names in the signing string are often case-sensitive. "Amount" and "amount" produce different hashes.
• Encoding issues: Ensure your JSON payload is encoded consistently. Extra whitespace or Unicode normalization differences will invalidate the signature.
• Timezone mismatches: Timestamps must match the expected format exactly. I standardize on UTC ISO 8601 format internally and convert only if the API mandates Nepal Time (NPT).

<?php
// app/Services/ConnectIPSSigner.php

namespace App\Services;

class ConnectIPSSigner
{
    public function sign(array $payload, string $secret): string
    {
        // Fields must be sorted alphabetically per 2026 API spec
        ksort($payload);
        
        // Build signing string: key=value&key=value
        $signingString = http_build_query($payload, '', '&', PHP_QUERY_RFC3986);
        
        // HMAC-SHA256 with raw binary output, then base64 encode
        $signature = hash_hmac('sha256', $signingString, $secret, true);
        
        return base64_encode($signature);
    }
    
    public function verify(array $payload, string $signature, string $secret): bool
    {
        $expected = $this->sign($payload, $secret);
        return hash_equals($expected, $signature);
    }
}

This service class isolates signing logic from your controller. Never embed hashing code directly in route closures or controllers. On production systems, I wrap this in a dedicated package or service provider so the signing algorithm can be unit tested independently against known test vectors provided by ConnectIPS. Testing against live endpoints during development wastes time and risks rate limiting.

What is the correct Laravel architecture for handling ConnectIPS webhooks?

Your webhook endpoint is the single source of truth for payment status. It must be idempotent, fast, and resilient. A common mistake in ConnectIPS integration for bank payments is performing heavy business logic synchronously inside the webhook handler. If updating inventory, sending emails, or generating invoices takes more than 2-3 seconds, ConnectIPS may timeout and retry, causing duplicate processing.

Implementing the webhook controller

The controller should perform only three actions: validate the signature, check for duplicate transaction IDs, and dispatch a queued job. Return a 200 status immediately upon successful validation. If the signature fails, return 401. Do not return 500 errors for business logic failures; log them instead and let the queue retry mechanism handle transient issues.

<?php
// app/Http/Controllers/Webhook/ConnectIPSController.php

namespace App\Http\Controllers\Webhook;

use App\Http\Controllers\Controller;
use App\Jobs\ProcessConnectIPSPayment;
use App\Models\Transaction;
use App\Services\ConnectIPSSigner;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Log;

class ConnectIPSController extends Controller
{
    public function __construct(
        private ConnectIPSSigner $signer
    ) {}

    public function handle(Request $request)
    {
        $payload = $request->all();
        $signature = $request->header('X-ConnectIPS-Signature');
        $secret = config('services.connectips.webhook_secret');

        if (!$this->signer->verify($payload, $signature, $secret)) {
            Log::warning('ConnectIPS webhook signature mismatch', [
                'transaction_id' => $payload['transactionId'] ?? 'unknown'
            ]);
            abort(401, 'Invalid signature');
        }

        $txnId = $payload['transactionId'];
        
        // Idempotency check: skip if already processed
        if (Transaction::where('gateway_txn_id', $txnId)->exists()) {
            return response()->json(['status' => 'already_processed']);
        }

        ProcessConnectIPSPayment::dispatch($payload);

        return response()->json(['status' => 'accepted'], 200);
    }
}

This pattern ensures your endpoint responds within milliseconds, satisfying ConnectIPS timeout requirements. The actual order update, invoice generation, and notification dispatch happen in the ProcessConnectIPSPayment job. For projects requiring detailed audit trails, such as law firm client portals, store the raw webhook payload in a separate payment_webhooks table before dispatching the job. This provides forensic evidence if disputes arise later. Developers working on broader API design should review Laravel API best practices for additional patterns relevant to webhook security and versioning.

How does ConnectIPS compare to eSewa and Khalti for Nepali merchants?

Choosing between payment methods depends on transaction value, user demographics, and settlement timing. While eSewa and Khalti dominate low-value consumer transactions, ConnectIPS excels in scenarios requiring direct bank-to-bank transfers without intermediary wallet balances. For a comprehensive breakdown of wallet integrations, see my guide on Laravel payment integrations covering multiple providers.

In practice, many Nepali eCommerce sites offer both. For a flower delivery service like Petals Nepal, customers prefer eSewa for Rs 2,000 bouquets but switch to ConnectIPS for Rs 25,000 wedding decoration packages. Offering only one limits your addressable market. The technical overhead of supporting multiple gateways is justified by the conversion lift in mixed-value catalogs.

What security measures prevent fraud in ConnectIPS transactions?

Security in ConnectIPS integration for bank payments extends beyond signature validation. You must defend against replay attacks, amount tampering, and race conditions. Relying solely on the gateway's security assumes no man-in-the-middle exists between ConnectIPS and your server, which is unsafe on shared hosting environments.

Always verify that the amount in the webhook matches the original order total stored in your database. Attackers who intercept or manipulate the init request could attempt to confirm a lower amount. Your webhook handler must fetch the original pending transaction by reference ID and compare amounts before accepting. Additionally, enforce a timestamp window. Reject callbacks older than 15 minutes unless you have explicit documentation stating ConnectIPS supports delayed notifications beyond that threshold. Stale callbacks often indicate replay attacks using previously captured valid payloads.

For environment security, never store ConnectIPS secrets in your repository. Use Laravel's environment variables loaded via .env or a secrets manager like AWS Secrets Manager if deploying on EC2. In my Deployer 7 workflows for sister sites like notarykathmandu.com and translationnepal.com, secrets are injected during deployment from encrypted vaults, ensuring they never touch disk in plaintext on shared infrastructure. Rotate webhook secrets quarterly and maintain dual-secret support during rotation windows to prevent downtime.

ConnectIPS Integration Implementation Checklist

Successful ConnectIPS integration for bank payments requires disciplined execution across configuration, coding, and testing. Before going live, verify every item below. Skipping any single step has caused production incidents on projects I've consulted on.

1. Obtain Production Credentials Separately: Test and production keys differ. Never use test keys in production, even temporarily.
2. Configure HTTPS Everywhere: ConnectIPS rejects non-TLS endpoints. Ensure Let's Encrypt certificates auto-renew via Certbot.
3. Implement Signature Service: Isolate HMAC logic in a testable class with unit tests against official test vectors.
4. Create Idempotent Webhook Handler: Store gateway transaction IDs uniquely. Use database constraints to prevent duplicates at the storage layer.
5. Queue Business Logic: Dispatch jobs for fulfillment. Keep webhook response time under 3 seconds.
6. Validate Amounts Server-Side: Never trust the amount in the callback without cross-referencing your internal order record.
7. Log Everything: Store raw request/response bodies for debugging. Redact sensitive PII but retain transaction metadata.
8. Test Failure Modes: Simulate invalid signatures, duplicate callbacks, amount mismatches, and network timeouts. Verify graceful handling.
9. Monitor Settlement Reports: Reconcile daily ConnectIPS settlement files against your database. Discrepancies reveal silent failures.
10. Document for Handover: Write runbooks explaining how to investigate stuck payments. Future maintainers need this context.

Following this checklist reduces post-launch firefighting significantly. Most issues stem from assuming the happy path works identically in production as in sandbox environments. Real-world networks drop packets, users abandon flows mid-transaction, and bank maintenance windows cause unexpected delays. Building resilience into your integration from day one pays dividends during peak seasons like Dashain when transaction volumes spike and support capacity shrinks.

Next Steps for Secure Payment Deployment

Building a compliant ConnectIPS integration for bank payments demands attention to cryptographic detail and defensive programming. Start with the signing service and webhook validator before touching any UI code. Test extensively with simulated failures, not just successful payments. When you're ready to implement this in a production Laravel application or need an audit of an existing integration, reach out through my contact page to discuss your specific requirements. Whether you're building a legal-tech portal, eCommerce platform, or SaaS billing system, getting the payment foundation right prevents costly rewrites and revenue leakage down the line.