Here is a common pattern of code:

// set some temporary state for the following block
try
{
    // do some stuff
}
finally
{
    // un-set the temporary state set above
}

A perfect example is showing the wait cursor during an operation in a Windows Forms application:

this.UseWaitCursor = true;
try
{
    // do some stuff
}
finally
{
    this.UseWaitCursor = false;
}

Every time I write one of these, I think there must be a better way to do this, something more akin to the old CAutoPtr template class in C++/ATL. The CAutoPtr class worked because C++ (regular C++, not the managed version) has deterministic calling of destructors. This is to say, that when an object is freed, its destructor is called immediately. This is in contrast with managed code which is garbage collected.

In managed code (C#, VB.NET, etc.) when the last reference to an object is release, via setting the reference to null or when the reference variable goes out of scope, the object’s memory is not actually released right away, and the destructor is not called either. Instead, the object sits on the heap in the same state it was when that last reference was released until the .NET runtime decides it is running out of memory and needs to garbage collect. In today’s systems with 4 GB of RAM or more, this often does not happen until the application’s process ends.

To compensate for this and allow developers to explicitly force an object’s destructor to be called immediately, the creators of the .NET Framework provided the IDisposable interface. This article is not about IDisposable so I won’t go in to a long explanation about it. Instead, you should know these basic facts about IDisposable:

• IDisposable is an interface that should (must?) be implemented by any class which manages critical, particularly unmanaged, resources.
• IDisposable has one method, Dispose(), which should clean up any critical resources.
• Unlike most interfaces, both C# and Visual Basic.NET have built-in knowledge and support of the IDisposable interface via the using statement (Using in Visual Basic.NET). When an object that implements IDisposable is wrapped in a using statement, its Dispose() method is called immediately when the using statement goes out of scope. Example:

        string text;
        // The StreamReader class implements IDisposable
        using (StreamReader reader =
                    new StreamReader("c:\\tmp\\foo.txt"))
        {
            text = reader.ReadToEnd();
        }
        // At this point, the using statement goes out of
        // scope, which causes the StreamReader's Dispose
        // method to be called, which closes the file's
        // handle.

Based on this, I knew any CAutoPtr like class would need to use the IDisposable interface in order to take advantage of the using statement, but I never took the time to actually figure out the details. That is, until now. As I have become more proficient at LINQ and lambda expressions, it became clear that the combination of IDisposable and lambda expressions was the answer. Interestingly, my AutoCleanup class itself does not leverage lambda expressions itself anywhere, rather it is the ability to use anonymous functions when constructing the AutoCleanup class that makes this so useful.
Here is the complete AutoCleanup class:

using System;

namespace ITDevWorks.Utility
{
    /// <summary>
    /// Guarantees automatic execution of delegate functions
    /// when an instance of this class is constructed and/or
    /// when it is disposed.
    /// </summary>
    /// <remarks>
    /// The <b>AutoCleanup</b> class is used in cases where
    /// you would normally use a try/finally to ensure that
    /// your cleanup code is executed, regardless of
    /// whether an exception was thrown or not.  With the
    /// <b>AutoCleanup</b> class, instead of all of the
    /// try/catch lines which can make code less readable,
    /// you can leverage the <see langword="using"/>
    /// statement, instantiating an instance of this class,
    /// and pass either just the cleanup code or both the
    /// constructor code and cleanup code to execute.
    /// </remarks>
    public class AutoCleanup : IDisposable
    {
        public delegate void ExecuteAction();

        private bool disposed = false;
        private ExecuteAction executeOnDispose;

        /// <summary>
        /// Constructs an <see cref="AutoCleanup"/> object,
        /// immediately executing a delegate function, and
        /// the guaranteeing the execution of a second
        /// deletate function when disposed.
        /// </summary>
        /// <param name="executeOnConstruct">
        /// The delegate function to execute during
        /// construction.
        /// </param>
        /// <param name="executeOnDispose">
        /// The delegate function to execute when disposed.
        /// </param>
        public AutoCleanup(ExecuteAction executeOnConstruct,
                           ExecuteAction executeOnDispose)
        {
            if (null != executeOnConstruct)
            {
                executeOnConstruct();
            }
            this.executeOnDispose = executeOnDispose;
        }

        /// <summary>
        /// Constructs an <see cref="AutoCleanup"/> object,
        /// guaranteeing the execution of a provided delegate
        /// function when disposed.
        /// </summary>
        /// <param name="executeOnDispose">
        /// The delegate function to execute when disposed.
        /// </param>
        public AutoCleanup(ExecuteAction executeOnDispose)
        {
            this.executeOnDispose = executeOnDispose;
        }

        #region IDisposable Members
        /// <summary>
        /// Disposes the <see cref="AutoCleanup"/> object,
        /// executing the delegate function provided in the
        /// constructor.
        /// </summary>
        public void Dispose()
        {
            Dispose(true);
            GC.SuppressFinalize(this);
        }

        //
        // Internal implementation of the Dispose() method.
        // See the MSDN documentation on the IDisposable
        // interface for a detailed explanation of this
        // pattern.
        //
        private void Dispose(bool disposing)
        {
            if (!this.disposed)
            {
                //
                // When disposing is true, release all
                // managed resources.
                //
                if (disposing)
                {
                    if (null != this.executeOnDispose)
                    {
                        this.executeOnDispose();
                    }
                }
                disposed = true;
            }
        }
        #endregion
    }
}

To use this class, you construct a new instance of it inside of a using statement, and pass in two parameter-less, anonymous functions. Note that when an anonymous function has not parameters you must provide the open and close parenthesis with nothing between them where the parameter list would normally go.

private void Form1_Shown(object sender, EventArgs e)
{
    using (new AutoCleanup(() => this.UseWaitCursor = true,
                           () => this.UseWaitCursor = false))
    {
        // do form initialization
    }
}

Furthermore, I was able to use AutoCleanup as a base to create specialized derivations of for common use cases. Below is an example that implements the UseWaitCursor logic.

using System;
using System.Windows.Forms;

namespace ITDevWorks.Utility
{
    /// <summary>
    /// Automatically enables the wait cursor for a Windows
    /// Forms control and disables it when the class is
    /// disposed.
    /// </summary>
    public class AutoWaitCursor : AutoCleanup
    {
        public AutoWaitCursor(Control control)
            : base(() => { control.UseWaitCursor = true;
                           Application.DoEvents(); },
                   () => { control.UseWaitCursor = false; })
        {
            // Do Nothing
        }
    }
}

Like the XML comment shows above, to use this class all you need to do is:

private void Form1_Shown(object sender, EventArgs e)
{
    using (new AutoWaitCursor(this))
    {
        // do form initialization
    }
}

This is far simpler and easier to read than the whole try/finally clumsiness.

I don’t know if any of you have experienced this, but it has been causing me grief for some time, but I finally solved it.

The Background
I have a web page that is part of the admin area of a client’s website.  The page has a GridView with a list of the website’s members.  The GridView is contained inside of an UpdatePanel control. 

The Problem
When you click the “Edit” button for a row, and your browser is some version of Internet Explorer (this does not happen with Firefox), your Page_Load() method is called twice. The first time IsPostBack == false, and none of your ViewState variables are available, so as far as your code is concerned, it looks like a first time page load and any “!IsPostBack” logic you have is executed.  The second call to Page_Load() is the normal one where .IsPostBack is true and your event handlers are called.

Since the ViewState variables are not present, you cannot set any sort of flag indicating the page has already been loaded.  Setting Trace=”true” on the @Page directive in the .aspx file yields nothing because the page is loaded twice so the first one is overwritten by the second.  I even tried setting an onunload handler in the client script to raise a server event (via Page.ClientScript.GetCallbackEventReference), but for some reason the onunload handler was never called, regardless of whether I set it on the window, document or body element.

The Solution
After trying all sorts of ways to reliably identify when a Page_Load() call was bogus, I finally came across this thread in the ASP.NET forums.  Basically, the solution is very simple and easy – you check the Page.Request.RequestType property.  If the RequestType is “GET”, it is the real first time page load.  If it is “POST”, then it is a postback.  So, I created the following property:

protected bool IsFalseFirstPageLoad
{
    get { return (!this.IsPostBack &&
            0 == String.Compare(this.Request.RequestType, "POST", true)); }
}

Then, at the top of my Page_Load() method, I have the following code:

if (this.IsFalseFirstPageLoad)
{
    return;
}

As simple as that. Problem solved.

When I was at Microsoft I worked on two different teams that were part of the larger Developer Division – Visual Studio Tools for Office (VSTO) and Visual Studio Team System (VSTS).  While neither of these was the core VS team, we were close enough to get occasional wisdom from them.  One such piece of wisdom dealt with cases when Visual Studio slows down dramatically, especially when debugging.  The solution was simple, just exit VS altogether, navigate to the folder where your .sln file is located and delete the .suo file there.  I don’t recall exactly why this works, but apparently the information in this aut0-generated file can get into a state where it causes VS to work way too hard to resolve otherwise simple problems.  Note that when you re-open the project in Visual Studio, all of your breakpoints, open files and similar session state information will be lost, but hopefully your slowness problems will be resolved.

If this does not solve your Visual Studio performance woes, here are a couple of other links which may be useful:

• Microsoft KB 920805:  Describes a slow response time in Visual Basic 2005 projects and a link to a hotfix to install.
• Visual Studio 2008 PAINFULLY SLOW!!: A thread on social.msdn.microsoft.com about performance issues in VS.  The primary answer in this thread has to do with changing an option in Internet Explorer which causes VS to check on the internet for certificate revocations by third-party control/library providers.

Hope this helps someone.

I recently answered a question on the Authorize.net forum. The questioner wanted to know which API to use for a single, one-time transaction. Below is my answer. You may find it helpful in determining which Authorize.net API to use for your purposes.

• Use AIM to make a single payment in real-time while the customer is using your application/website and has their credit card in-hand, and (if your application is a website) your site has an SSL certificate installed such that all senstive credit card information is entered via a from over an https:// connection.
• Use SIM if the above is true but you do not have an SSL certificate installed (and do not plan to install one).
• Use CIM if you want to support storing the customer’s credit card (or bank account, if you support it) information so the customer does not have to re-enter it if they return to your site *or* you have a recurring billing situation where either the amount or frequency of billing fluctuates.In either case, you will need the SSL certificate / https:// connection for when the customer enters their payment information.

The other common factor which causes people to choose AIM over SIM is they want to maintain the branding of their site when the customer pays. When you use SIM, the customer is sent to a form hosted by Authorize.net to enter their payment information. You can customize the header and footer somewhat, and change the background color and a couple other things, but you cannot do anything like add links back to your site or add your normal menus, etc.

This is just a quick summary of the key differences between and uses for the different Authorize.net APIs. I plan to write an Authorize.net 101 post one of these days, which provides a high-level overview of their primary payment gateway APIs.  In the meantime, if you need more information, you should refer to Authorize.net’s own documentation, or check out their developer community forums.

I am an independent software development consultant. By independent, I mean I generally work directly with my clients, rather than going through a contract agency or other firm. When I have more work than I can take on myself, I sometimes hire subcontractors to help out.

To help get new subs up to speed on projects and my development environment, I created documents addressing various things they need to know. For instance, one document explains how to connect to my Subversion server, while another one lists various required or otherwise useful tools. There is, however, another less obvious problem – actually a myriad of small problems – with taking on a new developer.

When I review a subcontractor’s check-in or observe some aspect of their work, I frequently encounter things that are not done “right.” I put “right” in quotes because I fully recognize that some, perhaps most, of these issues are just preferences. Some are actually best practices, but  many simply reflect the way I like things done. So I finally put together a set of guidelines to inform subcontractors of how to do things “my way.”

Do’s and Don’ts

As I started to write my guidelines, I had to figure out how to present them in an easy-to-read list, using consistent language. I settled upon making each item a Do or Don’t. This format works because some things are behaviors I want the subcontractors to adopt and others are practices that I want them to stop.

Before anyone comments telling me why my way is wrong, let me re-iterate that these are my preferences, and not a list of absolutes I expect everyone to follow. The only reason I post this in the first place is in to offer some advice for anyone wanting to get another perspective on these areas. Also if you find my preferences fairly similar to your own ideas, you can use this as a starting point for writing a document for your own employees or subcontractors. Lastly, this is as good a place as any to keep this list and I can just refer my subs to it.

The list has two main sections (at least for now).  These are Source Code Control and Coding Standards.  I may add more in the future but all of my issues so far were able fit in to these two categories. I should also note that I predominantly work in .NET, so some of the coding standards are specific to that environment.

Source Code Control

• DO make sure the checked-in source will always build.  Before checking in you should always synch to the latest source and perform a clean build to make sure nothing is broken.[Note: There are some rare exceptions to this rule. For example, certain kinds of changes, like file moves/renames and other restructuring tasks, require a series of check-ins to complete.  In these cases you inform everyone else beforehand what change is taking place and when.  Then, when you make the changes, include clear comments indicating that a given check-in is part of a multi-phase check-in.  Also, if for this or any other reason, you are knowingly checking in a set of changes which will break the build, add something like "!!! Broken Build !!!" to the first line of your check-in comment so it is clear to any reviewing the change logs not to sync with this revision.]
• DO add comments to every single check-in. Try to make the first line summarize the check-in as that is the only line which shows in the Show log dialog, but add more details as well.
• DO review all changes before check-in.  Every time I check-in changes, I bring up the Commit… dialog, review the list of files to make sure I am not checking in anything I don’t want to, nor missing anything I need to add.  Next, I systematically double-click on each and every file that I touched to make sure the changes include only the changes that should be checked in.  Using this process I frequently encounter small sections of code that I added for testing or debug purposes that should not be checked in.  I occasionally see outright problems that would break the build if did check it in.
• DO check for new files to add to the repository.  This is one of the most common mistakes made when checking in changes, forgetting to add important new files that you added to the project.  Everything will still build fine on your machine but you will break everyone else that syncs to your changes.
• DON’T check-in built binary files.  I have seen way too many projects that have all of the .dll, .exe, and .pdb files for a project checked in to source code control.  I have even seen projects with all of the files in the obj folders checked-in.  These files are all built every single time you build the solution on your machine and should not be stored in source code control.  Period.
• DON’T check-in machine/user-local configuration files.  In particular, don’t ever check-in any .suo or .user files.  Similarly, don’t check in *.Publish.xml, *.FileList.txt or *.FileListAbsolute.txt files.
• DON’T check anything in to the project or solution folder(s) not required to build and run the solution.  Don’t check-in any files used to create graphics (.psd, .pdn, .fla, etc.), any log files, temp files, or anything else that is not required to build the solution.  There should be a separate folder outside of the solution’s folder tree for checking in graphics sources, design documents and other project collateral, but these should not be in the actual solution folder hierarchy.

Coding Standards

• DON’T check-in code with build warnings.  Don’t ever check-in build warnings you have created.  The problem with build warnings is they sometimes are actually problems you need to deal with, and if you have a bunch of build warnings already, then you don’t notice when new ones are introduced.  If you are working on a project with legacy code that produces many build warnings, then know how many are reported when you check-out/update, and keep track of that number so you can prevent adding more.  If you can, clean some up some legacy warnings with each check-in so over time the number is reduced to zero.
• DON’T use exceptions for normal code flow.  Having exceptions thrown during normal operation of the code creates “false positives” when you are trying to debug real exceptions.  Very annoying.  Exceptions are also expensive, so it is generally a bad practice to rely on them.  It is important to catch exceptions in many cases to handle possible failure conditions (like making web service calls, doing file i/o, and such), but for things like converting strings to numeric or other values, there is always a non-exception producing way. 
• DO use String.IsNullOrEmpty() rather than stringVal == “”.  There are some very rare cases where you need to check if a string is null separate from if it has any data in it, but in the vast majority of cases you can use String.IsNullOrEmpty(), even if you already know it is not null. 
• DO use String.Empty instead of “”.  My code pretty much does not use “” anywhere.  It is always String.Empty.  If the value of String.Empty ever changes (unlikely, but possible), then all of my code will consistently change with it.
• DON’T use string concatenation, instead always use String.Format().  It pays to be consistent, String.Format() supports fairly rich formatting capabilities. It is way easier to re-arrange the contents of text using String.Format() than mucking with concatenated strings, and if there is ever any chance of code being globalized/localized, you will need to switch all string concatenation to String.Format() anyway.
• IDisposable (despite being last on the list, this is very important!)
  • DO understand IDisposable and be aware of when it is used.  There are many classes in the .NET framework which implement IDisposable and therefore must be disposed.  The #1 best way for doing this is with the “using” (in C#) or “Using” (in VB.Net) statement.  If you can at all avoid it, don’t hang on to disposable objects, instantiate them with “using”, make use of them, and then let them be disposed when the “using” statement falls out of scope.  The next best way to ensure disposal is via try/finally.  If you have to hold on to a disposable object as a member variable, the next bullet point applies.The most common place that IDisposable requirements are abused is in ADO.NET objects.  Many of the data access objects implement IDisposable and therefore invoke the two rules above.   Read an MSDN article titled Implementing a Dispose Method for some explanation of IDisposable.  There is also an MSDN Magazine article, Digging into IDisposable.
  • DO know the IDisposable interface implementation pattern and requirements.  If you encapsulate (have as a member variable) any object which implements IDisposable, then your class needs to also implement IDisposable, and any code calling your class must dispose your object which will, in turn, dispose the object it is holding on to.
  • DO use the using statement to ensure an object is disposed.  Both C# and VB.NET support the using statement for ensuring IDisposable.Dispose is called.  Always prefer using to try/catch if at all possible.  

[Update: 2009-11-10 @ 2:30 PM PST: It seems that as soon as I put this out Michelle C. from Authorize.net officially announced this feature on the Developer Community Forums. It also notes that this is phase one of a two-phase rollout, so there is more functionality to come.]

Those folks over at Authorize.net are so humble.  Whenever they come out with something new, they don’t make a big splash and boast to the world what a great thing they have done.  Instead they just put it out there and let us discover the fruits of their labor on our own. 

For example, when the Customer Information Manager (CIM) service was first released, there was no method to discover all of the customer profiles you created on the service.  The only way to retrieve a customer profile was to use the customerProfileId field assigned when you created the profile.  This was a major problem in the API since, if you were to lose the customerProfileId, you could not retrieve the profile record for that id. Yet if you tried to recreate it, you might get a “Duplicate profile” error. Then, in January of this year (2009), they silently released an update to the CIM service that not only included the new getCustomerProfileIdsRequest method, but also modified the “duplicate profile” error response XML to include the id of the duplicate it found.  I never saw any announcement of this anywhere.  I only found it because I regularly download the CIM XML Implementation Guide to see if the documentation has been updated.

CIM User Interface

Now they have done it again (those wascally wabbits!), only this time they released something much bigger.  One of the biggest problems CIM has faced? When merchants call up Authorize.net to sign up for CIM, they discover they cannot do anything with it until they hire a programmer and pay hundreds, perhaps thousands, of dollars to integrate CIM with their website or application.  This is clearly a show-stopper for many potential customers. 

Like me, anyone that has used CIM much at all has likely been expecting Authorize.net to build a user interface over CIM, much like they have for their Automated Recurring Billing  (ARB) service.  I actually recently had this confirmed by inside sources at Authorize.net. But didn’t know when it would come out, and I expected them to make a big splash out of it.

Just a Little Hint

Instead, as I was reading the Authorize.net developer community forums yesterday, I came across this post where one of the forum moderators casually said:

“[…]which you can now do by clicking Customer Information Manager from within the Merchant Interface. From the main CIM page, you can click Add Profile and enter the customer’s payment and shipping information.”

I did a double-take.  Did she just casually mention that there is major new functionality added to the merchant interface for Authorize.net accounts with CIM enabled?  I read it again.  Yes, indeed she did. So I immediately logged in to my Test account (since my live account has no need for CIM) and, lo and behold, there it was (note that, being my test account, the data in the image does not reflect what a live account would look like, with real IDs and emails).

(click image for full-sized picture)

I find the implementation as I expected it to be.  It allows you to perform pretty much all of the actions that the CIM API supports, except, interestingly enough, actually submit a payment transaction request.  That seems like a pretty major hole that will be a common request heard over at Authorize.net.  Otherwise, it looks pretty good on a first glance.

Congrats Are In Order

But I am still befuddled by their silence on this release.  I can kind of understand (although I don’t necessarily agree with) not announcing the addition of the getCustomerProfileIdsRequest method, but this is pretty major, and there isn’t even a blurb in the “Announcements” section when you log in to your live Authorize.net account.  The most recent addition there is from 10/13/09 titled, “Fraudulent Sites and Phishing Scams”.  Not a peep about the brand spanking new CIM user interface pages.

Still, many will be happy to discover this new feature.  In fact, until they add the ability to submit transactions, it is possible that those who stand to gain the most benefit are the developers themselves because we finally have a way of verifying what information is in CIM without having to write a bunch of code to do it.  I know I certainly will.

Most of all, though, I want to congragulate Authorize.net on this release, and also thank them for listening to their customers and responding, thus making our lives easier.

I am a total neat freak when it comes to code (my desk, though, is another matter). Whenever I find myself writing the same or very similar code within an application, I immediately want to factor out to a common, shared method. When something is repeated many times (say, 10-15 or more), my desire is to move the differences into some statically intialized data that can be used to provide the parameters necessary to drive the factored out code. In the case of a .NET application you can use the generic Dictionary<TKey, TValue> as a lookup table. The problem is that, unlike List<T>, generic Dictionary has no constructor which allows you to initialize it with data. Necessity being the mother of invention, I created the InitializeableDictionary<TKey, TValue> class.

I am actually a little surprised this is not part of the standard Dictionary class. They would just need to add a few constructors like with List, but, alas, this is not so. However, I understand there are all kinds of reasons for why features do or do not make it in to a product (heck, I used to work on the Visual Studio team as part of Team System, so I ought to understand). So I created InitializableDictionary a couple years ago to fill this gap and have ended up copying it over to just about every .NET project I have worked on since then. So, I thought I would share it here for anyone that could benefit from it. It is very simple. It just adds a constructor that takes in an array of KeyValuePair. The code is here:

The constructor with the IEqualityComparer<> is for cases when I need a dictionary with a case insensitive key. Note that you only need to use the InitializableDictionary constructor, there is no need to make your actual object of that class. Here is some example code that uses it (note that it does get a little wordy, but once you get the first line out of the way, up to the open curly brace, then the data lines are not so bad):

Of course, this example just uses a simple string to string mapping, but in a real application the key or the value could be of just about any type.

I hope you find this useful. If you do, let me know by posting a comment below.

Thanks,
Dave

Authorize.net is one of the service providers that allows you to process payments by taking credit card and/or electronic check payments on your website. Integrating with Authorize.net requires testing, first. So, when you create an account with Authorize.net, it is placed in Test Mode, and you must manually put the account in Live Mode before you can actually charge customers.

This is fairly straightforward to understand and do, but the terms “test ” and “live” actually can be used in three different contexts when dealing with Authorize.net, and this often makes it difficult to communicate with clients. Having explained this enough times, I thought I would write up a permanent explanation so I can point people here instead of going through it, myself, every time.  I also hope that anyone needing to understand these differences will find this explanation helpful.

Summary

There are three meanings for the terms “Test” and “Live” when discussing Authorize.net accounts and transactions. These are:

• Server Level: Test vs. Live => Authorize.net has their normal Live Servers (presumably more than one) and a Test Server. You can request a Test Account (which is an account on the Test Server) for free and they do not require a merchant account.
• Account Level: Test vs. Live => You can set your whole account in Test Mode and any transactions submitted will be validated but not processed (thus they will not be added to the Unsettled Transactions list or leave any other trace in your account).
• Transaction Level: Test vs. Live => Each payment transaction submitted can indicate that it is a Test Transaction. If your account is in Test Mode, this has no effect since all transactions will be treated as test transactions. If your account is in Live Mode, then this treats the transaction request the same as if your whole account was in Test Mode.

Detailed Explanation

Here is a more detailed explanation of these terms, along with a chart showing all combinations.

Server Level: Authorize.net’s normal accounts run on their Live server(s). However, they also have a complete, exact copy of their live system on a different server which does everything the live servers do except communicate with the back-end merchant accounts to actually transfer funds. Anyone integrating with Authorize.net can request an account on this Test server for free and submit all the transactions they want and no money will ever be charged against any accounts nor will any emails be sent. An account on the Test Server is referred to as a Test Account.

Account Level: To confuse things, you can also have your Live Authorize.net account in Test Mode. This is an option you can set in the account settings section of your account on Authorize.net. All new Live accounts are automatically placed in Test Mode and must be put in to Live Mode before they can be used to perform real transactions. When a Live Account is in Test Mode, it basically only performs the first level of processing to verify that the transaction submitted was well formed.

Also, Test Mode supports a feature where if you submit transactions with special credit card numbers, then the dollar amount of the transaction is returned as the Response Reason Code for the transaction. Therefore, if you submit a payment request for $1.00, it gives you a Success response. If the amount is for $2.00, you get a failed transaction with the Reason Code being 2 (“This transaction has been declined” – you can look up Response Reason Codes here).

However, transactions submitted while an account is in Test Mode never write anything to your transaction history, so there is no evidence of your tests if you log in to your account at Authorize.net (which is not true for Test Accounts, since the Test Server acts like a real live server and does all of the processing internal to Authorize.net and writes the transactions to the history for your Test Account). Note that, for what it’s worth, you can also place your Test Account (on the Test Server) in Test Mode or Live Mode, since it has the same features as a normal Live Account.

Transaction Level: Lastly, you can submit a transaction to a Live Account in Live Mode, but set a value in the data submitted with the transaction which says to submit just this one transaction in Test Mode, and it will behave as if you are submitting a transaction to an account in Test Mode.

Therefore, you can submit:

• If either the account is in Test Mode or the transaction is marked as a Test Transaction, then only basic validation of the request is performed.
• If the account is in Live Mode and the transaction is not marked as a Test Transaction, then…
  • If submitting against the Test Server it acts like a normal transaction but no money changes hands
  • If submitting agains the Live Server then, assuming everything is okay, money will change hands.

I hope this helps those of you who are trying to integrate with Authorize.net and implement payment processing on your website. Let me know if you have any questions!

I was working on a project for a client recently that involved Authorize.net CIM integration. The client is a member organization and they bill all of their members once-per-year on the same day.  With approximately 4,000 members, this means they needed to make sure that credit cards and bank accounts had not expired, been closed, or anything else which would prevent successful billing since the previous billing cycle the year before.  To accomplish this, they planned to use the validateCustomerPaymentProfileRequest feature of the CIM service.  They asked me how the validation worked and if it would actually charge anything against the cards. I had pondered this question in the past, but I had never actually done the legwork to figure it out. Now I had a client paying me for it, so I used what for me has been the quickest method of getting to Authorize.net support, the Live Chat feature available from the link at the top of the page when you log in to your Authorize.net account.  What follows is the transcript of that chat:

Yowza! So it is going to cost my client roughly $400 just to validate that the payment profiles they have are valid. This was a bit of a surprise to me.  In the end, the client just submitted the payments and dealt with the rejections afterwards since it was cheaper than paying the 10-cents for all of the valid payment profiles (which was, of course, the vast majority of them).

So if you find yourself batch validating a large number of payment profiles on Authorize.net’s CIM service, you should know that you pay a per-transaction charge for each PaymentProfile validated via the validateCustomerPaymentProfileRequest method or if the validationMode element is set to liveMode for createCustomerProfileRequest or createCustomerPaymentProfileRequest.