FileMaker is arguably the easiest database to use on the planet. Anybody, regardless of their programming or database experience can pick FileMaker up and build a database. This has always been FileMaker's greatest strength. People who use FileMaker typically do not want to move away from FileMaker because of the usability features that are inherent in the application. The fact that it's a cross platform solution that runs on both Mac and Windows is an added bonus. Of course, every database platform has its advantages and disadvantages. Typically the trade off for ease of use is power. As an application grows more powerful, it also becomes more complicated. FileMaker has maintained it's ease of use for the last 20 years! But, to maintain that ease of use, it has sacrificed the power that some of FileMaker's competitors have. It is the standard trade off - most database vendors choose power over ease of use. FileMaker distinguishes itself by choosing ease of use

70% is the percentage of all payment processing decisions that are made by a merchants technology advisers. That is a statistic that I heard at ETA this past summer. I always knew that the technology staff/vendor played a key role in determining who a merchant processes with, but I never realized just how large that role was until hearing that number. When you think about it further, it makes sense. When a retailer purchases a point of sale system, who will they ask about merchant accounts? The point of sale vendor or integrator. When an online merchant setups a shopping cart, or builds an e-commerce enabled website, who will they ask about payment gateways and merchant accounts? The web developer. When a company must process payments from within their enterprise system, who will they ask? The software vendor or developer. Most technology people don't understand the impact of this fact. When the vendor, developer or integrator refers their clients to a payment processing partner, t

I frequently see the question posed in various forums and community sites on how to maintain PCI Compliance within a software application. For example - "If my customer processes credit cards out of the system I built for them, how do I have to store the credit cards to be compliant? Do they need to be encrypted, double encrypted - double encrypted with an encrypted key, etc" Let's face it - it's a scary world out there when you hand your credit card information over to a complete stranger. With all of the SQL Injection Attacks, Cross Site Scripting Attacks, Root Kits, Viruses, Trojans, Spyware, etc - it seems like there are many opportunities for a hacker to compromise a system. Additionally, we hear horror stories about identity theft every day, with systems being compromised left and right and massive amounts of personal data being stolen. Add to that the hefty fines levied by Visa and Mastercard should a breach occur and card numbers get compromised - fines heavy

It always amazes me when I see a merchant who uses a enterprise wide database system to manage all of the processes for their business, but then goes to a swipe terminal to manually punch in credit card numbers when a new order comes in via fax or phone. I was at a customer's office the other day and they had this exact scenario. They were using a 4th Dimension database system (commonly referred to as 4D) and did not even realize that processing payments directly out of their system was possible. We brought up this possibility, and needless to say, they were ecstatic! The problem is that most developers don't know that this can be done or, if they do, they do not know how to accomplish it. In the 4D world, there are few companies out there with the knowledge needed to integrate the custom developed system with a payment processing system. NELiX TransaX has made this easy! We have the sample code in 4D / 4th Dimension available for anybody to see. The sample integrates with the

At NELiX TransaX, we regularly encounter scenarios where computer programmers have trouble servicing clients in the area of payment processing. This can happen for a variety of reasons, but it presents two big problems for developers: 1. Integrating payment processing is problematic 2. Developers don't make any residuals income after the project is done. NELiX TransaX can correct both of these issues. Check out this recent case study as it may relate directly to you. Developer profile: Expertise in all major programming languages and database types Creates custom applications, both web and LAN based Maintains/Modifies existing softwares Referred clients to PayPal, Authorize.net, etc. for payment processing Project: Developing online purchasing system. Client uses QuickBooks for accounting. Project Problems: 1. Gateway integration – limited options, bad documentation, and processor doesn’t understand programming 2. Security – client couldn’t operate without storing card holder data,