CiviCRM Community Forums (archive)

Authorize.net AIM provides several Credit Card Transaction Types:

• Authorization and Capture         
• Authorization Only               
• Prior Authorization and Capture   
• Capture Only                     
• Credit                           
• Unlinked Credit                   
• Void                             
• Visa Verification Transactions   

CiviCRM presently (AFAIAA) supports only "Authorization and Capture." We are interested to add support for "Authorization Only," "Prior Authorization and Capture," "Credit" and also "Void."

This will allow sites to be configured so that transactions are not processed--they are simply captured and authorized. Site admins will then have to manually process payments. This feature will be useful in a situation where membership or event registration is dependent on application review. Contacts can apply for the membership or event, including their CC details and then site admins can review and choose whether or not accept the application and process the payment.

This will preclude the need for either CC processing being a second step required of the user after application approval or the need for site admins to have to refund CC fees for denied applications. Giving refunds, however, is also sometimes necessary, so we will add that as well.

The overview of the changes required is:

• On the Payment Processor Edit page we need a switch to mark this PP as "hold" as opposed to "process now." The perceived usage will be that site admins can create multiple PPs of Auth.net AIM and mark each differently. Then for 'restricted' items they can use the "hold" one and for open items they can use the "process now" one.
• On the Edit Contribution page we need three button or links to allow the user to Process the payment, Void the payment or Refund the payment.
• A new method for the PP itself, to send an API call to auth.net with one of our three new transaction types. 
• A method to process the "process" etc. buttons and call method above. 

There are details not yet clarified, but this is the basic approach. I wanted to post this here before proceeding too far to see if there is any feedback. I will be coding this in CiviCRM 3.1.4 core for Drupal, but without any Drupal-specific code of course.