Posted on April 07, 2006
I have received a number of emails asking about how we did the integration with CyberSource credit card processing system. I have decided to post our extension here so that google can index it. We switched to CyberSource about a year and a half ago and this extension has been proved to be very stable for all this time. It uses CyberSource SCMP API SDK for C language which you can download here.
Note that this API is now considered to be a legacy one, but it still works perfectly. I'm not sure about the future though.
Follow this steps:
- Download SDK from the CyberSource and install it. By default it will be placed at /opt/CyberSource/SDK and this is where ruby extension assumes it resides. Otherwise you have to modify extconf.rb file.
- You need to generate merchant keys and certificate as explained here.
Download ruby extension and use standard steps to install it:
$ ruby extconf.rb
$ make
$ make install.
Test it! SCMP API is a name-value pairs API. Basically, you submit some set of name-value pairs and the server responds with another set of name-value pairs. For details consult documentation which comes with SDK. Below is a simple test program:
#!/usr/bin/env ruby
require 'rics'
req = ICSMessage.new
req['ics_applications'] = 'ics_auth'
req['server_host'] = 'ics2test.ic3.com'
req['server_port'] = '80'
req['merchant_id'] = 'v1111111'
req['grand_total_amount'] = '100.55'
req['merchant_ref_number'] = '1'
req['bill_address1'] = 'Miami Beach'
req['bill_city'] = 'Miami'
req['bill_country'] = 'US'
req['bill_state'] = 'FL'
req['bill_zip'] = '33160'
req['currency'] = 'USD'
req['customer_cc_expmo'] = '12'
req['customer_cc_expyr'] = '2005'
req['customer_cc_number'] = '4111111111111111'
req['customer_firstname'] = 'John'
req['customer_lastname'] = 'Doe'
req['customer_email'] = 'john@example.com'
resp = req.send
resp.each do |k,v|
puts "#{k} = #{v}"
end
Enjoy.
Filed under: Ruby |
6 comments
Posted on April 06, 2006
I would like to praise Vincent ISAMBART and Clifford Escobar CAOILE for translating this book to english written by Ruby wizard Minero AOKI. I've been reading several chapters that are already translated and it is a wonderful source of information about the internal structure of Ruby interpreter.
Filed under: Ruby |
0 comments
Posted on April 06, 2006
I've been running Apache 1.3.x with mod_fastcgi for almost a year and a half and it's been a very stable combination. I could restart apache with
apachectl graceful
and fcgi manager would send USR1 signal to all fastcgi children.
This mechanism is completely broken with Apache2. When I restart apache, for some reason it sends the signal only to one of its fastcgi children, the rest remain in memory doing nothing. Unfortunately, it seems that mod_fastcgi is not being actively maintained now.
Welcome mod_fcgid!. According to the mod_fcgid website:
mod_fcgid has a new process management strategy, which concentrates on reducing the number of fastcgi server, and kick out the corrupt fastcgi server as soon as possible.
The default parameters are pretty much aggressive in terms that fcgid would kill children that were idle for more than 5 minutes and it would always kill those that lived more that 1 hour. This is not exactly what I want for my long running Rails dispachers. I've been tweaking configuration options until I came up with:
AddHandler fcgid-script .fcgi
SocketPath /var/lib/apache2/fcgid/sock
IPCCommTimeout 120
IPCConnectTimeout 10
MaxProcessCount 40
ProcessLifeTime 86400
IdleTimeout 1800
DefaultMaxClassProcessCount 8
DefaultInitEnv RAILS_ENV production
Now I can freely use apache2ctl graceful to restart my application without worrying that there might be some processes left wasting memory. Also this gives me ability to use Capistrano to automate my deployment process. Check it out, it rocks!
Filed under: Rails |
0 comments