CyberCash Communication via Cyberlib

Folks, OK, now I really think I've hit a problem. Really. I swear. :) I'm using Timothy Whitfield's <timothy@ametro.net> Cyberlib as the middleman between a purchasing form and CyberCash. We're providing an accurate merchant ID and merchant key, and are using the standard payment URL of http://cr.cybercash.com/cgi-bin/ with the authtype of mauthcapture and a session key. So we pass all of this, along with the total ("usd 50.000", for example) and the test credit card number ("4111111111111111") to Cyberlib. Cyberlib succesfully chops up this URL and array, runs PHP's cybercash_encr() on the key, the session key and the payload, the name/value pairs containing the credit card data. The encoded data is run through cybercash_base64_encode, the socket is succesfully opened, the data is provided to CyberCash, and CyberCash gives a reply. So we cybercash_base64_decode() the resulting data, and then run cybercash_decr(). That's where things go wrong. The data that comes out of this function is still encrypted. Or, more likely, incorrectly decrypted. We're providing the same, accurate, merchant key and session key. The base 64 message looks...well...base 64ed. But $dec_msg["errcode"] is set, and we get "Response non-decodable." Searching the mailing list archives turns up very little information on this topic. I'd be surprised if Timothy's script were in error here, as I assume that it's been thoroughly used and tested. Is there some encryption settings to be done on CyberCash's side? We've compared everything regarding our setup on amps.cybercash.com to our setup (merchant key and merchant ID, notably), and everything matches. Any suggestions? Thanks, folks. Best, Waldo Waldo L. Jaquith < waldo@munkandphyber.com > < 804/979.2980 > // Munk & Phyber, Inc. // 110B Second Street NE // Charlottesville, VA 22902