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