1 $Id: notes_for_module_writers,v 1.1 2004-09-03 23:10:51 ivan Exp $
3 Information on creating a new processor backend to go with
4 Business::OnlinePayment.
6 create a subclass of Business::OnlinePayment called
7 Business::OnlinePayment::(processor name). You should override at least
8 the following functions (look at Business::OnlinePayment::AuthorizeNet as
11 set_defaults: set default information for server/port/path (if your processor
12 is not web based you probably dont need to override these).
14 submit: This is the only function you _MUST_ override, the superclass function
15 merely dies(), so if you dont override this, your module doesnt do
16 anything. Some of the things that submit should do:
18 * Turn the data into a format usable by the online processor,
19 some convenience functions (remap_fields and get_fields), are
20 provided by the superclass to make this a little easier.
22 * Check and make sure that all the required fields have been
23 filled in (the superclass provides the function required_fields()
24 which can do this for you).
26 * IMPORTANT: If the superclass function test_transaction() returns
27 true, the transaction must be submitted to the processor in test
28 mode. If your processor is unable to easily provide a test mode,
29 your module should die() if test_transaction() returns true,
30 this prevents accidental charges for people who thought they were
31 submitting test transactions.
33 * If your processor provides an option of whether or not you want
34 address verification, your module should check to see if the
35 require_avs() function returns true, and turn on AVS checking if
38 * Submit the transaction to the processor and collect a response.
40 * Do the following with the response:
41 * call server_response() with a copy of the entire unprocessed
42 response, to be stored in case the user needs it in the future.
43 * call is_success() with either a true or false value, indicating
44 if the transaction was successful or not.
45 * call result_code() with the servers result code (this is
46 generally one field from the response indicating that it was
47 successful or a failure, most processors provide many possible
48 result codes to differentiate different types of success and
50 * If the transaction was successful, call authorization() with
51 the authorization code the processor provided.
52 * If the transaction was not successful, call error_message()
53 with either the processor provided error message, or some
54 error message to indicate why it failed.