Allow reference set transaction type as default

Good questions.

I only added reference set because that's the specific use case I'm dealing with, and it makes sense at checkout time in some cases. I thought about the others, but five of them don't seem to make sense in the context of being triggered by the customer at checkout time: UC_CREDIT_PRIOR_AUTH_CAPTURE, UC_CREDIT_REFERENCE_REMOVE, UC_CREDIT_REFERENCE_CREDIT, UC_CREDIT_CREDIT, UC_CREDIT_VOID. The sixth, UC_CREDIT_REFERENCE_TXN, is an iffy case - ideally, if a customer has a card on file with you, you could let them choose to use it at checkout time. But I don't think that the current system works that way - it appears that references are order-specific rather than customer-specific. Rearchitecting that would be a bigger issue than a one-line patch.

To the other question, uc_credit has the uc_credit_log_reference() function to store the reference, and uc_credit.admin.inc has the admin interface to list, charge, delete existing references. The gateway module has to handle actually creating or processing them, but uc_credit is not unaware of references. I'm not sure that it should contain additional functionality, I just think that it shouldn't prevent people from using the gateway module's functionality when it makes sense (and that in this case, it makes sense to use it during checkout).

This only affects the options available for the default setting. I believe that default setting is always used (if not overridden by custom coding). So if you select 'Set a reference only', that's what it will always do unless you add custom code. I think you would need to create some custom code to, for instance, determine what type of transaction to do based upon the products in the cart (ex: if the cart only has products of type A, set a reference, if it's only this type, then authorize only, otherwise auth and capture).

And yes, a reference transaction means "don't charge the card, just give me a reference number that I can use to try to charge it any amount at any time later, without having to store the card number". The reference numbers are specific to your gateway account, so that if your data gets compromised, someone else can't use the reference number the way they could a card number. So it doesn't do any actual capturing, nor does it batch them or anything. You'll need some other code (or manual process) to do that.

In my case, we had custom code that was called by the recurring module to charge varying amounts depending on discounts, upgrades, etc. at the recurring interval. This patch doesn't do any of that, it just allows an admin setting so that we could avoid having to further override (or rather hack) the core functionality to avoid that first charge but still keep info (the reference) about the CC for the custom code to use later. There is a module for $0.00 orders that ignores the CC entirely, but that wouldn't work for us because then we wouldn't have the reference for future charges.