Bank Alfalah payment gateway work usually starts with a plugin download. For RFGI, a retail group running multi-warehouse logistics across Pakistan, the download was the problem: no ready-made plugin could take a card payment, prove it was genuine, and hand the paid order to the right Frisbo warehouse hub on its own. So we built the gateway from scratch.
TL;DR
- RFGI needed direct card payments through Bank Alfalah for a retail operation spread across several warehouses in Pakistan.
- No ready-made WooCommerce plugin covered 3D Secure 2.0 checks, order reconciliation, and automatic dispatch to Frisbo hubs.
- We wrote a custom Bank Alfalah gateway plugin in PHP 8.1, with HMAC-SHA256 signature checks and IPN callbacks.
- Paid orders now move to the nearest Frisbo hub on their own, with no manual steps in between.
The problem: card payments that stopped at checkout
RFGI runs retail logistics from more than one warehouse. A customer pays on the store, and the order has to reach the warehouse that can ship it fastest. That chain broke at the payment step. The store could take an order, but card settlement through Bank Alfalah needed a direct connection, and the order then had to travel to fulfilment by hand. This is the kind of build our web development team takes on when the existing site is the bottleneck: the front door and the plumbing behind it, rebuilt together.
The gaps were specific. The plugins on the shelf did not validate 3D Secure 2.0, so card checks fell short of what the bank required. They had no reconciliation webhooks, so paid orders and settled payments had to be matched by a person. And they had no dispatch routing, so someone had to decide which Frisbo hub got each order. Every paid order carried manual work, and manual work is where paid orders get lost.
Why the ready-made plugins could not do the job
The shelf options each missed a different piece. One handled cards but not 3D Secure 2.0. Another logged payments but never told the store which ones had settled. None of them spoke to the Frisbo fulfilment endpoints, so dispatch stayed a manual job. Stitching three plugins together would have left three places where the chain could break, and a payment chain that breaks in the middle leaves money taken and no order shipped.
The bank's own gateway page lists a WooCommerce plugin among its integration options, and for a standard store that plugin is enough. RFGI's store was not standard: payment, settlement proof, and warehouse dispatch had to happen as one flow, not three separate jobs. That is why the decision was to build the gateway as a custom plugin instead of adapting a general one. See the Alfa Payment Gateway page for what the bank offers out of the box.
The build: a gateway plugin written from scratch
The plugin is a WooCommerce payment gateway in PHP 8.1. It takes the card payment through Bank Alfalah IPG, runs the 3D Secure 2.0 validation the bank requires, and signs every request with HMAC-SHA256 so the bank and the store can each prove the message came from the other side untampered.
Settlement proof comes through IPN callbacks. When the bank confirms a payment, the callback lands on the store, the order status updates, and the payment is reconciled against the order without anyone opening a spreadsheet. A payment that cannot be matched to an order stops there, in the open, instead of slipping through as a paid order nobody ships.
The tech stack is short on purpose: PHP 8.1, the WooCommerce REST API, Bank Alfalah IPG, cURL, HMAC-SHA256, and webhooks. Each piece earns its place by doing one job in the flow, and there is nothing in the list that the flow does not need.
The automation: paid orders routed to the nearest hub
Payment was half the job. The other half was what happened after the payment cleared. Background cron jobs pick up each completed transaction and sync it straight to the Frisbo warehouse fulfilment endpoints. The routing picks the nearest hub, and the order moves from paid to dispatched without a person touching it.
That last point matters most on a busy day. When orders spike, a manual dispatch queue grows faster than the team clearing it. The automated route does not. An order placed, paid, and routed in one pass is an order that cannot sit in a queue waiting for someone to notice it.
Frisbo runs the fulfilment network the orders route into: warehouse storage, pick and pack, and delivery through one dashboard that syncs with the store. The gateway plugin is the piece that connects the store's checkout to that network. The same automation discipline sits behind the Ecovers rebuild, where every quote request flows into a CRM and gets an instant first response instead of waiting in an inbox.
What changed: settlement issues gone, dispatch automatic
The result reads plainly on the project record. Card settlement issues stopped. Checkout connects straight into warehouse fulfilment. Paid orders route to the nearest hub without failed transactions in between. No numbers were published for this build, so the outcome is stated as it stands: a payment flow that used to need manual matching and manual dispatch now runs on its own.
Rehan Farooq, Technology Lead at RFGI, put it this way: "The custom Bank Alfalah integration solved our card settlement issues and connected our e-commerce checkout straight into warehouse fulfillment without failed transactions."
That sentence carries the whole build. Settlement solved. Checkout connected to fulfilment. No failed transactions between the two. For a retail operation spread across warehouses, that is the difference between a store that takes money and a store that ships orders.
How the build ran: four steps, in order
The project followed the method we use on every build. Discovery and architecture first: the payment flow was mapped from the customer's card to the warehouse shelf before any code was written. Design and prototyping next: the checkout and dispatch flow laid out as one path, not two systems bolted together.
Engineering and build followed: the plugin written in PHP 8.1, tested against the bank's sandbox, then against live transactions. Deployment and scaling last: the gateway went live with the cron sync running behind it and the fulfilment endpoints taking routed orders. The same four steps shaped the DCC Developers CRM build, where sales and billing systems replaced manual tracking across a developer's portfolio.
Still matching payments to orders by hand?
If your checkout takes the money and your warehouse finds out later, the gap between the two is where orders get lost. We build the connection that closes it.
See how we build custom WooCommerce systems
Frequently asked questions
What did BuzzinTech build for RFGI and Frisbo?
A custom WooCommerce payment gateway plugin for Bank Alfalah IPG, written in PHP 8.1, plus the automation behind it. The plugin handles card payments with 3D Secure 2.0 validation and HMAC-SHA256 signatures, reconciles each payment through IPN callbacks, and hands the paid order to Frisbo's warehouse fulfilment endpoints. Background cron jobs route each order to the nearest hub without manual steps.
Why could an off-the-shelf plugin not do the job?
The ready-made plugins each missed a piece the project needed. None of them validated 3D Secure 2.0, none reconciled settled payments against orders through webhooks, and none routed dispatch to Frisbo hubs. A standard store can run on the bank's own WooCommerce plugin. This store needed payment, settlement proof, and warehouse dispatch as one flow, and that meant a custom build.
What is 3D Secure 2.0, and why did the bank require it?
3D Secure 2.0 is the card authentication step that checks the cardholder is who they claim to be before the payment clears. It runs inside the checkout, usually with a bank prompt or a silent risk check, and it cuts fraudulent card use. Bank Alfalah requires it for direct card processing through its gateway, so any plugin taking cards through the bank has to run the validation properly.
How does an order reach the right warehouse?
After the bank confirms a payment, a background cron job syncs the completed transaction to Frisbo's fulfilment endpoints. The routing picks the nearest hub for that order, and the order moves from paid to dispatched on its own. Nobody decides per order, and nobody retypes the order into a second system. The handoff from checkout to warehouse is automatic.
What does HMAC-SHA256 do in the gateway?
HMAC-SHA256 signs every message between the store and the bank so each side can prove the message came from the other and was not changed on the way. If a callback arrives with a bad signature, the store does not trust it. That check is what makes the reconciliation reliable: a payment is only marked settled when the bank's own signed message says so.
Can this gateway pattern work with other banks or fulfilment providers?
The pattern carries over wherever the pieces exist: a bank that exposes a payment gateway with callbacks, and a fulfilment side that exposes endpoints for incoming orders. The plugin itself is specific to Bank Alfalah IPG and Frisbo, because each bank and each provider has its own message format and its own checks. A new pairing means a new build, using the same shape.
How long does a custom payment gateway build take?
Timelines depend on scope, and we do not publish per-project durations. What we do publish is the method: discovery and architecture, design and prototyping, engineering and build, then deployment and scaling, with senior engineers on the project and a direct line to the people doing the work, and no account managers in between.
More from Buzzin Tech Hub
- Real estate developer CRM: one view of every unit sold: how a custom CRM gave DCC Developers one view of every unit, payment, and pending instalment.
- Zapier vs n8n vs Make: the billing unit decides cost: the billing unit, not the app count, decides what automation really costs.
- Browse the full archive at https://buzzintechhub.com/blog.php.