 |
UbercartOne cart to rule them all... |
|
| Donate to Ubercart | Affiliates | ||
Operate in credit card debug mode does not seem to work
Submitted by JaceRider on Thu, 05/22/2008 - 12:46
Hello, I have enabled the "Operate in credit card debug mode." and after numerous test orders I am still unable to process CC# after the order has been placed. It simply stores the last 4 digits no matter what I try. Am I missing something here? (I am using RC5)
If a credit card gets processed during checkout, it doesn't save the data. You'd have to move into debug mode and uncheck the box that tells it to process cards in checkout. This is b/c of the security requirement that sensitive data shouldn't stick around once a card has been run. My clients needs to allow for recurring charges month by month for some products. Until RC5 I had a system that was working. Now, however, since I can no longer access the card data -- there is no way to get this to work. Do you have any recommendations? I have till next Friday to have this thing going and I thought I had this issue solved. Hmm... so you want to keep processing payments during checkout and then hold onto some card data for processing the recurring fees? Is it possible for you to run the recurring fees through your gateway instead of storing the data locally? If not, can you get by with just the card number and expiration date? There would be nothing stopping you from simply hooking into the order submit/save to store your own encrypted version of the CC details and using that information to process the recurring payments. The data is still a part of the order object during checkout. I wish I could run the recurring fees through my clients gateway -- unfortunately they used a "money saving" merchant against my recommendation and so that type of feature is a dream away from never. However, I could indeed hook in and grab the CC information before processing -- just a pain when RC4 did everything as I needed. Up till my upgrade I just had your uc_recurring.module running w/ the generic CC module and a custom merchant plugin and things would work almost perfectly. I would imagine that the new changes to the CC security have done some damage to the Recurring module across the board? Or was the way I was using it never intended? Honestly, I forgot to test the core recurring fee handler, but I'm not sure it should break anything. That module's default handler was caching its own copy of the CC details, but I'm not sure what to do with that. I suppose I can just make sure it's evident that this is a debug handler and update it to not store the "non-storable" data by default. Will give it a little bit of thought today. Quick update... I had to add in one line to cache the CC data stored by the core recurring fee handler. Now it seems to work fine on the Livetest. I still need to tweak a couple other things on this module to make sure it's fully PCI compliant by default, but this should be a huge step for you in the right direction. Grab it from Bazaar. Summary: With the latest code, you should be able to operate as you were before. Look for a couple more changes to come to make it explicit what is and is not stored by the core recurring fee handler. Wow! Thanks so much for your work! I will test it out and report back as soon as I have some time. I really appreciate your help on this! Thanks again. Seriously Ryan -- you are too good at this stuff. Everything now works exactly as it should. Any recommendations on the best way to get the module to create an entirely NEW order (instead of just updating the existing order's comments) when I reoccurring charge is processed? Unfortunately, the distribution center my client is using requires all orders to have a unique order number in order to get shipped. The contributed uc_subscribe.module has this feature -- so I'm sure I can combine the two and come up with the perfect fit for my client -- but I just wondered if you had any suggestions. Once again -- excellent work. You'd have to create your own recurring fee handler to do that. You can copy the stuff out of the core module if you want and modify the function uc_recurring_charge() in your own module (rename it of course) to create the new order instead of just entering the payment on the existing order. Done and done. (I guessed at what your answer might be.
|
|
I do understand your reasoning behind the changes and support the adjustments -- it would just be nice if I could flip a switch and revert to keeping the CCs on the server for a defined period of time.
Joined: 03/17/2008