Archive for September, 2009

Magento’s Order Management Workflow: Comprehensive but Unrealistic #2

September 29th, 2009

Yes, I finished the goEmerchant payment plugin for Magento and figured out how to use and modify Magento’s Order Management Workflow. It did require a lot of reverse engineering and a bit of tweaking of the button labels to improve the admin’s understanding on what each operation actually does.

Magento's Order Management Workflow is like a plumbing job, maybe not so bad.

Pre-Authorize transaction on Checkout:
So, the first thing we want to do is pre-authorize transactions when a user places an online order and checks out from Magento. That is relatively easy and mostly built in. Nothing needed to change from a workflow point of view. The only thing we had to realize is that there are two values that stay with the payment which is associated with the Order and we can use for the goEmerchant reference_number. Those are: ‘cc_trans_id’ and ‘last_trans_id’ – I chose to use ‘cc_trans_id’ just because it made more sense.

Cenceling & Voiding an Order:
In Magento you can only void invoices. However, if you create an invoice you in effect will triger the captur() method of the payment. Now, goEmerchant allows you to void only unsettled transactions – so we had to handle the voiding before we create an invoice. Luckily Magento has the cancel() method that is called when an order is canceled. So, we wired the void operation to the cancel() method and relabeled the button from ‘Cancel’ to ‘Cancel & Void’ – to explain what it actually does. We also turned off voiding, since there is not much sense in voiding an already created/settled invoice.

Settling a Transaction (Capture Funds):
goEmerchant needs the eCommerce application to send a ‘settle’ request when the order was processed, shipped, and invoiced. This request than places the transaction in the settled queue and will be processed usually at 2am. This was relatively easy and no modifications to the workflow needed here. All we needed to do is perform the ‘settle’ request in the capture() method of the payment. Note: since our module still allows Authorization & Capture setups, we had to handle the special cases here. But overall no problem.

Refund or Creditmemos:
Magento has this option to create new credit memos, these serve as what we call it as refunds. Luckily, here Magento’s Order Management Workflow works finde and allows you to process a credit memo and ‘Refund Online’. It is actualy labeled ‘Refund’ and the other option is to ‘Refund Offline’. So, in our plugin we are simply wiring the refund request in the refund() method of the payment. Note: Magento also allows a refund of the entire order which is not triggering anything. So, we will need to be cautious to explain to our merchants that they will need to refund already created invoices.

Magento’s Order Workflow is definitely rich in features and allows great level of flexibility for the merchants. However, some of it would not make sense and seems like overly complex for something that should be configurable but simple. We were able to get our plugin working the way we needed it to by a combination of using the existing functionality and relabeling some buttons. We will also need to caution our merchants from certain actions or make the decision to remove these options altogether.

If you are interested in our goEmerchant payment module for Magento, email us at or call at (888) 897-7775.

Magento ,

Magento’s Order Management Workflow: Comprehensive but Unrealistic

September 25th, 2009

Here I am, knee deep finalizing a Magento goEmerchant payment module. When done, the module will integrate a Magento store with the goEmerchant XML API which will allow seamless pre-authorizations, captures (on invoicing), refunds, and voids.  All will be handled by the Magento admin panel at the order management pages. Well, I have just discovered how Magento handles things and it is slightly different then what we need it to be. In fact, it is different than what any payment gateway will require. Let me explain:


Assuming that the Magento is configured to Authorize only on checkout, once an order is processed, the payment info will be sent to the gateway and a Credit Card pre-authorization will occur. Resulting in a reference_number which is stored somewhere in the database. In the back-end, an admin will then review all the open orders, or orders under the ‘processing’ status and will create invoices accordingly. When the invoice is created there is an option to Capture the funds at that point. Great! this is almost what needs to happen, but workable. In essence, pre-authorized transactions need to be ‘Settled’ not ‘Captured’ according to goEmerchant’s logic. Not a problem.

What is problematic and will require serious re-plumbing of the Magento logic is the fact that only captured invoices can be voided. Well, this defeats the purpose because that is why we pre-authenticate. In short, according to Magento, a pre-authenticated order can issue an invoice which will then capture the funds and only then one can void the captured, pre-authorized transaction. This is a problem in the logic! What needs to happen, according to goEmerchant, is the ability to void a pre-authorized order without the need to issue an invoice and capture the funds.

I’ll keep you posted on this… to be continued.


Quick Way to Update Fail2ban jail.conf file

September 3rd, 2009
Comments Off

There are plenty of settings in that file, especially if you are running CentOS 5.3 with latest patches and fail2ban from atomic repository. Here is a short list of steps that I follow when setting up new servers:

1. Setup sendmail to start on boot. Make sure it can send emails correctly (Reverse DNS records, hostname config, etc).

2. Make sure that fail2ban starts on boot (I use ntsysv for that).

3. Edit the jail.conf file, type vi /etc/fail2ban/jail.conf

4. Change the time for increased security:

bantime = 86400
findtime = 3600

5. After you save and exit, change all the destination emails to go to root which will then be forwarded to you:

sed -i 's/' /etc/fail2ban/jail.conf

6. Add a forward for all emails to root to your email:

echo "" > ~/.forward

7. Restart fail2ban:

service fail2ban restart

Web Application Hosting ,