Home » Forums » Ubercart » Development

Cybersource SOAP implementation

Submitted by radScientist on Wed, 01/09/2008 - 16:06
radScientist
Posts: 25
 Joined: 11/20/2007
Bug Finder

I'm not quite sure how to go about adding it to core, but I currently have a SOAP file similar to the HOP.php file where the user will need to define their constants for accessing the API.

I added about four lines into the cybersource module to call the functions in my SOAP file if the API method was set to SOAP instead of simple order or HOP.

I implemented a custom solution to handle submitting subscriptions via the SOAP api, so I'm trying to decide how to allow a user to customize each line item before it gets passed on to the api - this would allow them to define custom fields, and handle subscription charges for items. It needs to be simiilar to a theme function, but not quite as difficult to implement as a hook function.

Anyways I wanted to get some thoughts from people if they have run into a need for this.
permalink #1 Wed, 01/09/2008 - 16:10
Ryan

Posts: 5617
 Joined: 08/07/2007
AdministratorHead Code Monkey - I eat bugs.

Glad to hear you're working this out. I'm not sure I understand your needs enough to offer any sort of advice, though. Can you shed a little more light? Puzzled

permalink #2 Thu, 01/10/2008 - 18:19
radScientist
Posts: 25
 Joined: 11/20/2007
Bug Finder

Hi Ryan -

After re-reading my original post, I realize now that I make absolutely no sense Smiling.

I have 2 questions to sort out:

1. What is the best way to allow user definition of API related keys? I could follow the convention of the way the HOP method works by including an HOP file alongside the module, and including a SOAP file also which defines a SOAP class to handle the submission, and all the constants for the users API access. Although this breaks a good practice of not needing to modify a modules files for your implementation, I'm not sure how I feel about storing all the api passwords and info in the database.

2. I am currently implementing my own subscription routines by looking at each product for a "subscription" attribute, and if one exists I am passing along subscription fields to the SOAP api for cybersource to process. I can see that other developers might need to customize what gets submitted to Cybersource in their implementations on a per product level, as there are also a few user defined fields that cybersource has too. So I am wondering what the best way is to implement something like a hook function on the order processing to format the API request per item. Something like "hook_ubercart_order_gateway_item." Although it seems dangerous to implement a hook at a position right before payment processing Smiling. Another option would be just to provide a handler in the SOAP api file for a default formatting. But I would like to avoid committing in files for the user to edit that will also be maintained by the ubercart team over time.

I hope that is a good summary of the issues I saw - thanks for your help Ryan.

permalink #3 Wed, 01/16/2008 - 17:33
Ryan

Posts: 5617
 Joined: 08/07/2007
AdministratorHead Code Monkey - I eat bugs.

1. I'd go with what feels right. Sticking out tongue CyberSource are the ones who implemented the HOP.php deal, and they seem pretty intense about security. I don't have a real problem w/ the information being pulled from the DB, because if someone gets in there you're probably going to have more trouble than a few fake transactions on your CyberSource account. You could always compromise and make a form available (maybe just to user 1) that will generate the file for them so they don't have to do any manual editing. I'll probably take this approach for encrypting CC numbers in the DB.

2. For core consideration, any subscription stuff will need to go through the uc_recurring module that I still have in the works. Now that my plate is cleaning off a little bit, I'll probably get to finishing up the first version soon. In the meantime, I'd just do what works for you (that tends to motivate folks best anyways Eye-wink). Using the attributes system probably isn't best, though, and the recurring module I've got going will solve that by using a product feature instead. More details to follow when I put it up.

permalink #4 Wed, 01/16/2008 - 18:30
radScientist
Posts: 25
 Joined: 11/20/2007
Bug Finder

Thanks Ryan for the tips,

I was considering having the cybersource module define "subscription attributes" somehow, so that the API keys can line up and it would all be encapsulated. But that definitely doesn't seem right, as you would be tying a product to a gateway -

So I will wait to commit that until you have a uc_recurring module to hook into, that is a great way to go.

Thanks for all the help.

And if anyone out there needs SOAP code now, just private message me and I'll hook you up.

permalink #5 Fri, 05/23/2008 - 08:13
Holgate
Posts: 1
 Joined: 05/23/2008

radScientist wrote:
Anyways I wanted to get some thoughts from people if they have run into a need for this.

Not to be curt, but yes.