As Aristotle said, you probably don't need to pull out the heavy artillery here. When I think of heavy artillery, I think of transactions based on EDI or XML events, millions a day. Folks hurl a lot of money at the problem and names like Peoplesoft, Siebel, PaperFree, Foresight (Edisim), etc, start making appearances and many many specialists storm the facility for implementation or upgrades.

At their core, however, we're talking about some pretty simple processes such as adding a contact or initiating a billing event, munging data into a different format, etc. The only thing that makes them scary is the amount of money riding on the transaction sets.

One thing you will find in this sort of business logic is a lot of attention to dealing with events such as cancellations that might occur mid-way through. Rolling back changes can sometimes introduce lots of complexity into a problem which started out as simple.

I'm not sure how transient your "products" and "contacts" are during the data-entry phase -- it sounds as though there's an intrinsic dependency in that you do not want a product without a contact (but it's probably okay to have a contact with no products?) I'd probably introduce a transaction key that will roll back changes if a cancellation is initiated or if the process is never finished after a certain time period (they close their browser mid-way through and never come back). Depending on the type of session, you could have multiple transaction keys -- each key for a single transaction set and the required events composing that transaction set. One of the "transaction" keys could just be a more familiar session key that helps with your lateral browsing across the form space of your application.

Matt